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:
- Does each company currently have an Identity Provider (IdP)?
- Will you keep both IdPs separate or merge them?
- Which IdPs do you have?
- How many users and groups do you have in each site today?
- Are there any overlap in group names between each site?
- 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
- 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?
- 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?
- 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).
- How much data exists in the confluence server product? How big will the migration be?
- There's more questions, but my fingers are getting tired.
Scenario 1 - You merge the sites
Pros
- Single set of site and product settings to manage, easier for your admins
- All users can collaborate together (project and space security settings withstanding...) I think this is a pro! But you may not.
- Only pay for one product and get a cheaper overall cost if you're pushing up the billing tiers
- You can keep multiple IdPs if you want for each company Domain, or merge them into one IdP.
- This would be the least amount of maintenance in confluence long term, if you were intending to standardise confluence global/space security settings.
Cons
- 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.
- 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
- Your migration will generally be easier.
- The settings for each product will be easier to manage, bbbuuuuuttttt, see Con 1
- 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.
- 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/
- 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
- If you need to make common setting changes between both site A confluence and site B confluence, you'll have to make them twice
- 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)
- 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).
- You'll need to clean up your confluence sever product
Scenario 3 - You keep the sites AND orgs separate (generally not advised)
Pros
- Your migration will be even easier, as you can wipe the ENTIRE org before moving your data from server.
- 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
- You'll need to clean up your confluence sever product
- If you need to make common setting changes between both site A confluence and site B confluence, you'll have to make them twice
- If you need to make common setting changes between Org A and Org B, you'll have to make them twice
- You might pay more for your products, as you have two bills and are on lower billing tiers for both.
- 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.
- 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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.