Cloud to Cloud Migration - User migration

[Katherine Lord]

We have a cloud to cloud migration due to acquisition:

• site.companyA.atlassian.net
• site.companyB.atlassian.net

Users emails are *@companyA.com and *@companyB.com

We now have some *@companyB.com emails (user) in site.companyA.atlassian.net and these users are unique (ie the user does not have a *@companyA.com email address) or duplicate as they have both *@companyA.com and *@companyB.com accounts now unfortunately.

Both domains are enabled on both sites.

Question - should I go ahead and

1. Remove the duplicate accounts under @companyB.com and move any of they data to their @companyA.com user thus preserving user data
2. Then update all the user accounts on site.companyA.atlassian.net to only use their new emails and thus retire the @companyA.com on both and remove the domain.  Therefore forcing everyone to use their new emails for @companyB.com
3. How do I handle inactive, deactivated user account on site.companyA.atlassian.net -  do we update their emails to a *@companyB.com email?

[Gerusa Lobo]

Hello @Katherine Lord

My suggestion are based on how many domains you want have in your destination site.

If will you use both domain in same destination site, you can ask for Atlassian to update all owner date in jira and confluence from an account A to B for the users with duplicated account, and deactivate the old one, for they have only one active account in use.

If you want use only one domain in a destination site, you could replace de email domain in users in origem site (A), before the migration.

You could use this article for that:

https://community.atlassian.com/forums/Trust-Security-articles/Tips-about-IdP-Change-with-update-of-the-account-email-domain/ba-p/2924876

I hope help you,

Gerusa. 

[Dr_ Ankita Mehta-OpsHub_ Inc]

Hi @Katherine Lord

During migration, duplicate or mixed accounts often show up. The key is to clean them up during migration, not after. Some points to consider:

• Transform on the fly: Most tools will force you to migrate users as @A.com first, then bulk update them to @B.com inside Jira. This will make all issues updated time move to latest date, giving wrong signals in reports.
• Inactive accounts: Decide if you should map to a placeholder @B.com user (to keep the audit trail intact) or be skipped entirely.
• Domain strategy: Pick the primary domain early and keep it consistent — transformations work best when the rules are simple.
• History & traceability: Whatever mapping you choose, make sure comments, attachments, and ownership still point back correctly after the move.

For handling these cases cleanly, you may consider an enterprise migration tool and Atlassian Solutions Partner, OpsHub Migration Manager (OMM). It supports on-the-fly identity transformations, keeps history intact, and helps you move without downtime or disruption with full data fidelity — making it easier to focus on the migration instead of firefighting duplicate accounts. 

Happy to connect on call if you have any questions or want to have a personalized demo! :)

Good luck!