How do you merge different companies into one? Marriages in Cloud

[#1]

Mergers and acquisitions happen. These "marriages" offer challenges that on-premise Atlassian products didn't, due to the nature of Atlassian IDs.

What happens when you merge two different user populations into a single Cloud tenant?

In Cloud, how do you combine two organizations that may have duplicate names, or organizations that need to share an identity (say, of a parent company) but also need to retain their original identity for branding purposes.

I know there are folks wishing for a way to merge Atlassian accounts (ID-240) or associate multiple emails with a single account (like Bitbucket allows us to do; ID-6403).

[Luis Machado]

Ok, I think this topic warrants a deeper discussion but I'm going to attempt to at least hit the high points.

What happens when you merge two different user populations into a single Cloud tenant?

When you migrate multiple populations into cloud, how those users are treated is somewhat dependent on what your cloud presence looks like and the circumstances surrounding the user data but there are two main potential scenarios:

• You're using Atlassian Access and are claiming the email domains being leveraged by your population
  • In this case, you get the ability to manage the collective user base in one place via the Org administration menu. You can apply authentication policies to them, enforce MFA, and have the ability to deactivate or delete accounts.
• You're not using Atlassian Access and all users are leveraging the Atlassian site for managing their own accounts
  • It's the wild west, every individual has control over their own account, password resets, MFA, Information, etc. and you simply manage the cloud sites and grant access to whoever needs it.

how do you combine two organizations that may have duplicate names, or organizations that need to share an identity (say, of a parent company) but also need to retain their original identity for branding purposes.

I think this would depend on what you consider 'branding purposes', is this for customer-facing interaction? like a service desk? or more of internal branding, as a way to keep work related to each company identified and separate? There are two possible options in my head related to this:

• You can combine multiple Atlassian sites under a single Org account. Atlassian will let you move sites from orgs you own to consolidate them under a single org.
  • This would let you maintain independent instances of Jira/Confluence while bringing the management of those instances into a centralized location.
  • Everyone gets to 'brand' their site as they see fit, and there are no collisions across the various groups.
  • The potential downside to this is you're paying for individual licensing on each site, if you have users that need access to both then you're paying double for each user. This can potentially be mitigated by upgrading to enterprise licensing, but also comes at a higher cost so you'd have to weigh out the options
  • Also, this has the potential to promote a more siloed company and may just move any visibility issues you have across the company into the cloud setting.
  • If the issues it tied to customer-facing branding and having customers or clients share your system, this might be the way to go.
• You merge the instances into a single site. This approach is a bit trickier, and there are 2 ways you could handle it
  • Upfront discovery - take the time to look across the individual instances you have, figure out how folks are using the systems, and come up with a solution that gives teams the ability to work in their own way, but also allows you to capture metrics that report up for visibility. Once that's in place, build out the model in a cloud site and import data using the existing configurations.
  • Lift and shift, and fix it later - Migrate all the instances into a single cloud site as is. Spend time post-migration identifying duplicates and remedying the configurations.
  • If you're looking to just identify internally which teams are which this could be a potential approach.

Within all of that, there is some potential nuance to consider, but I think that covers the options at a high level. In any case, I would recommend working with a Solutions Partner if you're looking to merge/migrate to cloud in almost any setting, as it's usually not a small amount of work to get it done right. Working for Praecipio Consulting my opinion is biased of course, but we help companies do this sort of thing all the time. Hope this helps shed some light, happy to discuss it further!

[Brent Thayer]

I totally agree with the above info from Luis. We have gone through this process over and over again since our Jira instance is Cloud premium and we are in a company with many segments and is constantly making acquisitions.  Just to add on the the points mentioned above:

Typically when we go through an acquisition the company does not have a separate Jira instance so its probably a bit easier for us. But the first step is to create a separate user policy that is not connected to AD and is not a billable policy. That means to start, we first verify the domain and add the users to the new policy. Once the network team is able to provision the new domain accounts vs their old accounts (example @oldcompany.com -> @newcompany.com) we are able to update the user details to the new domain verses having a duplicate account get created. At that point we can also move these users over to the linked authentication policy and have them managed through the Identity Provider.  As for the customer facing piece, the old domain is still an alias on the account. So the users are able to communicate with external entities though email just fine but we are unfortunately unable to do much with the email address that comes from the Jira tool based on segment of the company. 

That is more or less what has worked for us. We learned some of these steps the hard way due to the UPN on the AD was not the email so user accounts were not being identified properly. Atlassian engineers were able to assist our team with getting that rectified though (so i recommend you do that). I am certainly not a SME in this area but just wanted to share my experience. 

[Dave Liao]

@Luis Machado - I appreciate the chime in!

I'm also biased and would work with Praecipio in a heartbeat, don't worry. 😉 @Larry Brock {Praecipio Consulting} FYI 🙌

[Andrea Robbins]

Mine is about ID-240:

I had a massive duplicate account problem in our instance:

we had two verified domains (one was a legacy one and the other was a new one), and before I took on the role as Jira admin, the previous "admins" just reinvited everyone with the new email domain not knowing about changing the domain in their account since they were managed accounts.

However, by the time I got there, most users had half of their Atlassian products under one domain/account and the other half (some overlapped) on the other domain/account. If I tried to change the emails, it said I couldn't because an account with that email already existed. 

I had to reach out to these individuals to see which accounts they were using, what data needed to be migrated to the other account and then add a special character in the email that I wanted to not use, deactivate it, then change the email domain (incorrect one) that I wanted to use to the correct email domain. 

Some tips I got from Atlassian support:

- I bulk assigned tickets from the old account to the new account (before deactivating the old account)

- for those who had Trello in both accounts/domains, they gave me this link to bulk transfer all boards to the new account: https://trello.com/support/transfer-boards (support article here: https://support.atlassian.com/trello/docs/how-to-transfer-boards-to-a-new-account/)

-for Confluence, our confluence permissions is more by groups, so I just ensured the groups were the same

- for Bitbucket, we have a central instance for all users, so I just had to ensure they were part of the same Bitbucket groups

However, this got even more complicated because we also had portal accounts, so some users had duplicate portal accounts once this was fixed. So we had to go through and migrate them to Atlassian accounts. I had to reassign assets as well (bulk import new Atlassian IDs) since we have Insight. 

Needless to say, we have everyone on one account now! Hope this was helpful!