You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I posted before about the migration I'm in charge of from JIRA Server to Cloud but would like more clarification/help.
I have read this:
So If I understand correctly after the migration is done both JIRA Server and Cloud will be running with the data. Therefore I'll be able to tell the team to switch to JIRA Cloud, am I correct?
If yes, a good way to do the migration would be to plan the migration during a weekend; communicate about it and have
We use Confluence with links to tickets (stories, epics, ...) will they still work after the migration?
We are a Platinum Atlassian Partner in New Zealand, and have run multiple Server to Cloud migrations for our customers, so of which are quite big and would fall in the top 4% of all Atlassian Cloud instances size-wise.
Our of these we've done both site import and JCMA migrations. Yes, do not mix the two – the results as we found out are a disaster.
Create a run book. We (ab-)use Product Requirements blueprint in Confluence, with "User Story" column reserved for specific steps, each one with a clickable [ ] task box. When the run book is executed we mark down the start/stop timestamp of each step.
A migration is not instant! The latest JCMA migration of ~1500 users, 280 projects, 28Gb of attachments and two apps took 64 hours and ran from 6pm Friday to 8am Monday.
The main pain point for a migration are the 3rd party apps – consider yourself lucky if you are not using any on Server. If you do not have apps – you may still try the full site import option. If you do have apps – JCMA is much more likely to be the way, especially if the apps support automated migration. You should reach out to vendors and confirm they do not have scheduled downtime/maintenance for the weekend(s) you choose.
I suggest to plan for multiple test migrations. In our experience it takes about 5-6 of test ones to get it absolutely right. This number may be going down with JCMA getting more and more features, but still so far it's not a one-off affair.
Do let Atlassian Migration Support know 2 weeks in advance when you are doing the TEST migration and most importantly the PROD one.
With JCMA, you should also look out for things like Filters, Boards, Dashboards – you will have to use JCMA dark features for that.
Atlassian Access and the overall dance around it – deactivating the users who somehow got into Cloud over the years in bulk before migration, integrating with your IdP for SSO and User Provisioning (if supported by your IdP), breaking this link before migration (so JCMA can add users into groups that will eventually be populated from your IdP) and restoring the link after – is important to get right.
In general configuring your Cloud site permissions, including integration with IdP is an important step to get right. See here for some of our recommendations: https://community.atlassian.com/t5/Atlassian-Access-questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaq-p/1852575#M3417
We also always re-key Jira as far as groups are concerned – often in Cloud there will be no "jira-users" group coming from the IdP, while your Server data may be using this group everywhere in permissions/restrictions, notifications schemes, workflows.
Switching off mail connectivity in Cloud while you doing your TEST migrations and until you've accepted the PROD one is an important think to remember, so Cloud doesn't steal your PROD emails from the PROD mailboxes.
Yes Confluence Server, once Application Links are re-pointed to Jira Cloud will continue to work.
Once (if) you move Confluence to Cloud, you will need help from Atlassian support to update links in Jira (and Confluence) to make two products work together well again.
Do not forget Jira Cloud looks and behaves differently from Server, so besides UAT you may want to plan for some training for the teams you are moving over.
In general, I suggest not to take on this journey alone, and involve a nearby Solution Partner
I realize I should have add more information about the migration, so here they are.
We already have a free trial Cloud version that we emptied of all projects and groups
I have read here that Site Import is no longer available for migration under 101 user, so we are going to use JCMA.
I ran the Migration Assistant Home after reading the pre-migration checklist. I stopped at step 3 Migrate your data, here is the 'about your product'
So it's a relatively 'small' migration, we do not have any 3rd party apps so I'm considering myself lucky :)
Considering the size would it still be recommended to run 5-6 test run ?
@Ed Letifov _TechTime - New Zealand_ I am not familiar with "mail connectivity in Cloud" what do you mean by that? Is it the notification email from JIRA ?
I'll definitely contact a solution partner
@Nicolas Mourier You are lucky :) I would still run at least 1 test migration, verify everything thoroughly.
One thing to look out for – is any meta-data objects that may be present in Cloud before you start JCMA that will cause conflict with whatever will be coming from Server e.g. Resolutions, Project Role Names, screens and screen schemes, statuses, etc. You may want to rename everything you can to "X Old" so JCMA doesn't treat them as conflicting. In particular delete all custom fields (and empty the trash) that you can.
If anything after migration gets "(migrated)" suffix in the name – this needs investigation. It is only OK in custom fields where on Server you have multiple fields with duplicate names – these can be renamed after migration. In everything else – presence of such suffixes is red flag.
Most importantly – consider how you will be resetting the site repeatedly. For our bigger migration we use site import with an "empty" Jira and user overwrite. However, as you pointed out the site import is disabled for smaller instances. You may need to reach out to support and ask them to enable the site import specifically for the purpose of site reset. Please note deleting Jira subscription knocks out something on the billing side of Cloud if your instance is on commercial billing or extended trial license, and the billing team is not 24x7.