Manage users from multiple sites

[Jake Ward]

We are looking at migration options to bring an acquired company's Confluence Server into the cloud. One option we are considering is keeping it as a separate site under our company's management.

We are Company A and have Site 1. We have acquired Company B.

Company A has Atlassian Access so we have an organisation which contains Site 1. 

If we were to migrate Company B and create Site 2, would it be possible to have Organisation A as the parent and sites 1 and 2 in the same org? If we do this, is it possible to manage all user access from Organisation A? What would the experience be like for users with access to both sites?

We are on Confluence Standard.

I hope that isn't too confusing, thanks

[Kieren _SmolSoftware_]

Wow, I'm are hilariously qualified to answer this question! :D

Summary: Contact Atlassian Support to help guide you with this. This page gives a good over of having multiple sites under one organisation https://support.atlassian.com/organization-administration/docs/how-many-instances-of-a-product-does-my-organization-need/

Long version:

I can give you a general overview of the difference experiences and pros and cons to managing multiple sites in an single org vs merging the sites into one site vs keeping each site in separate Orgs, but honestly the experience really depends on a few more details:

1. Does each company currently have an Identity Provider (IdP)?
2. Will you keep both IdPs separate or merge them?
3. Which IdPs do you have?
4. How many users and groups do you have in each site today?
5. Are there any overlap in group names between each site?
6. Are both sites on the new admin.atlassian.com directory experience? Or are they using the old one? See this article https://community.atlassian.com/t5/Atlassian-Access-articles/User-management-for-cloud-admins-just-got-easier/ba-p/1576592
7. This one would be hard to answer on these forums, but generally how you use groups within your IdP(s), in admin.atlassian.com and in each of your Atlassian products (e.g. product/project/space permissions) will have an impact on how you migrate and your end state. I guess the question is, how are groups used within your products between each site?
8. Following on from 6; are you expecting to keep your group/security settings as is between each site? Or are you looking to standardise group/security settings in one of the sites?
9. Are the users from Company A and Company B expected to collaborate together in Jira or Confluence? If they're not expected to collaborate together, are they allowed to even see people between each company? (some acquisitions are arranged so NO staff from Company A are ever allowed to know who is working at Company B).
10. How much data exists in the confluence server product? How big will the migration be?
11. There's more questions, but my fingers are getting tired.

---

Scenario 1 - You merge the sites

Pros

1. Single set of site and product settings to manage, easier for your admins
2. All users can collaborate together (project and space security settings withstanding...) I think this is a pro! But you may not.
3. Only pay for one product and get a cheaper overall cost if you're pushing up the billing tiers
4. You can keep multiple IdPs if you want for each company Domain, or merge them into one IdP.
5. This would be the least amount of maintenance in confluence long term, if you were intending to standardise confluence global/space security settings.

Cons

1. Depending on the age of each site, you're going to have a lot of different spaces, and security settings being merged into one product... That could be hard to manage in the future.
2. You'll need to clean up your confluence sever product, generally I'd expect you to hit more problems when migrating into an exiting site, rather than into a fresh/clean site. Read up on your migration options here https://support.atlassian.com/migration/docs/what-is-confluence-cloud-migration-assistant/

---

Scenario 2 - You keep the sites separate, but under the same organisation

Pros

1. Your migration will generally be easier.
2. The settings for each product will be easier to manage, bbbuuuuuttttt, see Con 1
3. Depending on how big your current cloud and server confluence instances are, you might be better with separate sites to not go over your data limit.
4. You have the option to move spaces between each site in the future, if you want to consolidate later on. https://support.atlassian.com/migration/docs/prepare-sites-for-a-cloud-to-cloud-migration/
5. You can keep multiple IdPs if you want for each company Domain, or merge them into one IdP. But, all the users from both sites will exist in a single organisation user directory. An org admin will see and manage users from both Company A and Company B. This could be a pro or con for you... More info on merging IdPs https://community.atlassian.com/t5/Enterprise-articles/Critical-Limitations-to-Centralizing-in-a-Single-Identity/ba-p/1714858

Cons

1. If you need to make common setting changes between both site A confluence and site B confluence, you'll have to make them twice
2. Your users can't see each other or collaborate together, unless you grant them access across sites (you might see this an a pro though)
3. You might pay more for your products, as you have two bills and are on lower billing tiers for both (unless you're on an Enterprise plan).
4. You'll need to clean up your confluence sever product

---

Scenario 3 - You keep the sites AND orgs separate (generally not advised)

Pros

1. Your migration will be even easier, as you can wipe the ENTIRE org before moving your data from server.
2. Your users will have 0 overlap or ability to see each other. You have separate admins for each Org. Really this is the only true benefit of keeping the orgs separate, if Company A and Company B needed to function independently.

Cons

1. You'll need to clean up your confluence sever product
2. If you need to make common setting changes between both site A confluence and site B confluence, you'll have to make them twice
3. If you need to make common setting changes between Org A and Org B, you'll have to make them twice
4. You might pay more for your products, as you have two bills and are on lower billing tiers for both.
5. You must have separate IdPs if you want both Orgs to connect to an IdP. You can share domain claims between the orgs, but it's complex and (currently) you need to manually claim the users as they are created.
6. Generally more maintenance...

You made it to the end!? Nice job, have a break and rest your weary eyes...

If you're interested in chatting in more detail, you can contact me via my website smolsoftware.com

-Kieren

Co-Founder @ Smol Software | Ex-Atlassian

[Dave Rosenlund _Trundl_]

Wow! Looks like you just got a gold-star answer, @Jake Ward. 

Kudos to you, @Kieren _SmolSoftware_! 

-dave

[Jake Ward]

Hi Kieren, thanks so much for the detailed response! I think based on this I'm still leaning towards scenario two. There are no security concerns around allowing users to collaborate and see each other - they will be on the same IdP, but I'm happy for access to each site to be managed independently. 

The main reasoning for considering this approach is that both sites are quite well established and we are expecting to get a fair amount of overlap in groups and spaces and are probably not yet in a position to merge these. In both sites we use groups created in atlassian admin, so no concerns currently about bringing over from IdP. Longer term I think we'd consider some cloud to cloud space migration as we get a better understanding of how we will fully integrate in time. 

We're talking fairly small numbers of users. I've done some rough calculations on price from merging vs. keeping separate and it doesn't seem to be too dramatic...

I've tried to keep detail a bit vague for the forum, but thanks again for your help here!

[Kieren _SmolSoftware_]

I’m glad it was helpful!

we are expecting to get a fair amount of overlap in groups

This could bite you if you’ve not done enough analysis on what those overlapping groups give access to.

e.g. if you have a confluence-admins group in cloud and on server, when you migrate to cloud (if you’re on the new admin experience) those two groups will merge together. If user A was in the cloud group, and users X and Y were in the server group, all 3 users will be in the merged cloud group. So user A will suddenly have confluence admin to the newly migrated confluence product and X/Y will have access to the established cloud product.

The way to avoid this (if you’re on the new admin experience) is to rename the cloud groups that will clash before migrating the server groups. https://community.atlassian.com/t5/Atlassian-Access-articles/Org-admins-can-now-rename-groups-in-cloud/ba-p/2276321

 One more thing, you could have troubles if you’re using the default product access groups and using an IdP, since you can’t sync users into default groups. My team is building an app to help with this, essentially we're solving ACCESS-604. It's about to be released in a free closed beta (around January 2024). If you're interested, contact us via our website smolsoftware.com to be a part of the beta.

[Gary Pasquale]

Just some additional info regarding Scenario 1 and 2.

The ability to connect multiple IdPs to a single Cloud Org is only available to customers on the Cloud Enterprise tier.

As the original question relates to a customer on the Standard tier, multiple IdPs under a single Org would not be possible without upgrading.

[Kieren _SmolSoftware_]

FYI @Jake Ward , the Admin Automation app is publicly available now. It will allow you sync users from one group to another which could help with your IdP setup and getting users into Default Product Access groups.

Hope the migration worked out for you!

-Kieren
Co-Founder @ Smol Software | Ex-Atlassian