Jimmy's Top 5 Jira Cloud Migration Tips

[#1]

Hello Everyone!

With it being migration month I thought this was the perfect time for me to offer my set of tips when it comes to performing a Cloud Migration. Some of these tips you may have seen elsewhere and a number of these were inspired by one of the first articles I ever wrote on this topic: Our Journey to High Availability with Jira - Part III

Even though I may have numbered them, these tips are in no particular order, they are all very important to consider!

#1 Authentication: Atlassian ID or Atlassian Access:

First, all of Atlassian’s Cloud products by default use Atlassian ID as the authentication method, this also defines your username as your email address. If you have been using the internal directory on the server products or you are using LDAP for authentication, you will know that your usernames might be something different. This will need to be accounted for as a part of the migration, and if you want to allow for single sign on (SSO) you will want to do some research into Atlassian Access and supported identity providers for SSO.

#2 Clean up your Data:

I know that many people have said this one in the past. It’s even in the Cloud Migration Center’s prep information. But it’s always worth repeating, the less you bring with you from your server instance the less time it will take to migrate, and the less you will continue putting off cleaning up later. Be sure to look at older projects, unused custom fields, backups of workflows and various schemes. You will feel much better if you are migrating a lean set of data!

#3 Validate Apps, Cloud Functionality & APIs:

I’m sure you already know that you want to look and see if there is a Cloud version of all the server apps you are using, but that’s only part of it. Because the APIs in the Cloud are VERY different from the server version you will also want to check/test the functionality of all the apps you have to make sure they will function the way you want them to. At the same time, if you have written custom scripts that use the APIs, you are going to want to make sure that they will either continue to work in the Cloud, or that you can update them to work with the Cloud. Lastly, it’s not a bad idea to just using the Cloud version of the product and make sure you are happy with the way it functions, and that there aren’t any glaring gaps that would be a showstopper for you company if they weren’t about to do something they could in the server version.

#4 Recruit a Beta Testing Group:

This was one of my biggest wins when I was performing the Jira Server to Cloud migration at my previous company. We had licenses for the entire company and most of the company was tracking their work in Jira. Since that was may different teams with very different workflows and processes, I was about to get representatives from all departments to test their processes with a migration of our production data and we were able to identify some issues ahead of us doing a live migration. As the users who work with the processes every day are much more familiar with what they interact with, they were in a much better position to test that things were working properly compared to myself. If this is something you are able to achieve I highly recommend it!

#5 Test, Test, Test!

Yes I know, I was literally just talking about testing, but this time I’m referring to the migration itself. If you read my other article, you will know that our first attempt to go to production was a failure. We had only performed the migration once, thought it was successful and didn’t do it again until trying it on production. When we first went to production, we saw different results. We spent the next week, running the migration, running our sanity test then, wiping everything out by running the migration again. This made sure that we knew exactly how long the migration would take to run, and what information we should expect to see while it was running. I was sick of running the migration by the time we went to production the second time, but I was also much more confident in our ability to be successful!

Bonus tip: Have a rollback plan!

On that note, make sure you have a plan of how you will go back to your server instance without data loss and user interruption before you start your production migration, thankfully we have a much better rollback plan in place then our first migration attempt that not one knew we had any difficulties as the rollback was extremely smooth.

I hope these tips will be useful for you are you start to plan your own migration. I know it can feel very overwhelming at first, trust me I have been there. You’ll manage to be successful, it will just take some time to do proper planning and testing and things will work out in the end. If you have any other questions feel free to ask in the comments. I also decided to make this a feature episode on my YouTube channel if you would prefer to watch the video instead:

Have a great week and be sure to check out the: LIVE panel with cloud migrations experts from the Atlassian Community happening later this week!

[Taranjeet Singh]

Thanks for sharing these great Jira Cloud Migration tips, @Jimmy Seddon ! These are super helpful.

[Justin C]

Hi Jimmy,

thanks for sharing this!

Currently we want to test to link our local Jira Server to the cloud site and run a test migration for 1-2 small projects just to see the outcome. Does the site-link and the migration process do anything to our local Jira server? Can we test over and over again without having trouble that the migrated projects at our loccal Jira server might get unavailable?

Greetings

Justin