User management when executing data copy

[Kalani Keala]

Hello, we've divested a business unit and need to migrate half of the company to a new instance of Atlassian.  We have the new instance and are preparing to copy data.  My question is regarding the user copy options.

Users on the new instance HAVE to use a new email address, so there will be no "need" for the user copy.  Our plan is to delete the users that are copied onto the new instance and add the new user accounts on the new instance to the copied groups.

First question, does this sound "reasonable"?  Second question, will we be charged for the copied users if we deactivate/delete them immediately following the copy?

Thanks in advance for your help.

[Marshall Walker Lee · Accepted solution]

Your plan to delete the copied users on the new instance and add new user accounts with new email addresses to the copied groups sounds reasonable. This approach ensures that the new instance has the correct user information and avoids potential issues with duplicated email addresses.

Regarding charges, if you deactivate or delete users immediately after copying them to the new instance, they should not consume a license. Users who are deactivated do not consume a license, and therefore, you should not be charged for them. However, it's always a good idea to confirm this with Atlassian support or your account manager to ensure there are no unexpected charges based on your specific licensing agreement.

[Ed Letifov _TechTime - New Zealand_]

Hello, @Kalani Keala 

Everything depends on your definition of "delete". If you literally mean the "delete" operation available in the UI for managed users – this won't work, since user accounts are global in Atlassian Cloud, so "deleting" a user would destroy their account everywhere, including the old site. The same logic applies to "deactivate".

So taken at face value, no the plan is not "reasonable" and it's likely @Marshall Walker Lee has misunderstood you.

If you want to continue with "delete" route – what you really after is removing the "old" users' access to the site. Since the new site is actually new, it will be on the new user management experience, so this is definitely possible, albeit not to do in bulk with the means available in Atlassian UI.

When we do such migrations as a Platinum Solution Partner we use our own Marketplace app User Management for Jira to handle these cases of bulk user deactivation/suspension/un-licensing. This functionality is available on the trial license – so feel free to save yourself some clicks.

Still, please note that with this "delete"/remove from site approach the references in the data itself will remain to the "old" users e.g. reporter/assignee/comment author in Jira, all issue history, as well as any direct references to users in the meta-datea e.g. Roles, permissions, workflows, notifications schemes. Also for Confluence – page author, page editor, comment author.

Some of these can be updated in bulk fashion afterwards (e.g. reporter) but most can't be.

In general Atlassian still does not support the use case you are describing.

This is really not the way to do this. The proper way is to export Cloud data into Data Center/Server XML format, update all emails to the "new" emails in bulk (e.g. with a ScriptRunner script) in a temporary DC instance and then migrate the data back to Cloud using one of the migration assistants (JCMA or CCMA). This method is still available until June 30, 2025 (what are we going to do after – no idea).

You should probably reach out to your Solution Partner (assuming you have one) – they should be able to help.