Hello, @Trung G
1) Get a local Solution Partner to help you: https://www.atlassian.com/partners
2) If Cloud Jira has a commercial or extended eval license and you "wipe" it by resetting following the instructions provided by Atlassian here (https://confluence.atlassian.com/cloudkb/how-to-reset-atlassian-cloud-instance-to-the-original-default-settings-including-removal-of-all-data-691012037.html) – it disconnects from the licenses in the backend. You will need to reach out to the Billing and Licensing team via Atlassian Support (https://support.atlassian.com/) to restore the link. Confluence seems to survive the same process better, but the mileage may vary – reset your sites 2-3 days before your migration.
3) Instead an empty Jira site should be loaded – this will retain the link. Atlassian Migrations Support can provide you a cleaned-up XML export to use for this.
4) Deleting users in Cloud completely or just from the site anonymises their data (due to privacy laws around the world) – hence "Former User" problem.
5) If you are importing Jira content as a full-site import – you need to load users beforehand by providing a users file and group membership file to Atlassian Migrations Support.
Since you are migrating both Jira and Confluence – you need to combine your Server users across Jira and Confluence. The emails in the resulting files must be unique and valid e.g. no "@example.com" or something that won't pass email address validation. The usernames and emails in Jira and Confluence data must be consistent casing-wise and match what you are sending in the file to Migration Support.
So should be the group names – can't have the same group in different cases between Jira and Confluence, and in general - make all your groups lower case.
7) Please note, Portal Only users in JSM must NOT be included in the file above, only licensed users should. If any fo these need to use SSO provided by Access – you will need to migrate them to Atlassian Account afterwards. Manually. One by one.
8) I would highly recommend asking Migration Support to remove all users (but one site- and org- admin) from the site before a migration to avoid errors.
9) You may want to clean up your users while you are still on the server i.e. deactivate those who haven't used the products for a while (e.g. 6 months).
You may need to move users around form the internal directory to the internal one or export a CSV file for the above. Use our UserManagement for Confluence app for this. Feel free to use it on evaluation license. Buy if you like it. Reach out to our 24x7 support if you need more advice or talk to your Solution Partner.
10) You may need to rename the users – changing the usernames and emails.
We use Adaptavist ScriptRunner with a custom Groovy script working off a CSV file.
Talk to a Solution Partner – they should be able to help.
11) In general – you need to do A LOT of renaming in your Server data. Since you mentioned Access – you may need to re-key your Server data e.g. replace all "jira-users" references with whatever group name will be coming via Access (if any) from your IdP that will have the same meaning in the products.
From experience you will need to use a lot of ScriptRunner, SQL, and sed wizardry.
Get a local Solution Partner to help you.
12) If you are using JCMA to migrate Jira – don't, since you are migrating JSM.
13) If you are using CCMA to migrate Confluence – do it after you've resolved your users problem, use option "merge with existing users"
14) Not sure what exactly your comment about users in Access "shown as having access to Confluence but with the institution hub URL" really means – sounds like you have another Confluence instance in the picture?
You may want to make sure groups that are coming from your IdP and give access to products on different sites have the site name in the group name – so you can actually be selective what site's product you are giving access to.
Make sure you configure Access correctly – see here for Azure AD, it will be similar with other IdPs: https://community.atlassian.com/t5/Jira-Service-Management/Azure-AD-login-and-incoming-email-not-matching-up/qaq-p/1821809#M88619
Again, get a Partner that actually understands Access integration.
15) Run multiple test migrations and document every step in a run book. Run it again and again until you are absolutely sure you got it right, and your user acceptance testing accepted the result.
16) I understand that you seem to have almost got there on the first attempt – but normally a migration like this will take 3 to 6 months, if done properly, without data loss and surprises afterwards.
17) Did I mention "talk to a Solution Partner"?
Good luck.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.