nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Comments

Kieren _SmolSoftware_

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

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 .
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

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

migration

confluence-cloud

atlassian-guard

cloud-migration