It shouldn’t be news that Atlassian is ceasing all support for their Server products effective February 15th, 2024. That means for those of you that haven’t made the jump yet, you have less than a year as of the writing of this article to get onboard. Aside from ‘because you have to’, there are many reasons you should be excited for this change and embrace it.
While you can totally take the migration journey on your own, given the complexities with migrating data from Atlassian’s Server products to the cloud, it’s recommended that you work with an Atlassian Solution Partner. Leveraging the expertise and experience of a Solution Partner, particularly a Platinum Solution Partner with a cloud migration specialization (*cough* shameless plug *cough*) sets you up for the best possible chance of success.
Speaking of setting yourself up for success, one of the things we here at Praecipio always recommend to our clients as part of their process in preparing to migrate, is to do a little house cleaning. There are a few areas in particular that can quickly increase the cost and scope of a migration effort. If you’re able to do some clean up around the specific areas below it can have a major impact on your bottom line.
There’s an App for that…
Jira instances have a wide variety of 3rd-party apps available to them to make anything possible. While the customization allows for uniquely tailored instances, 3rd-party applications were named the #1 stressor when moving from on-prem to cloud, and for good reason.
Not all apps are compatible with Jira Cloud. Figuring out if your apps will even work should be your first step. In addition to that, how apps integrate with the cloud version of Atlassian’s products is fundamentally different from on-prem. You’ll want to do your homework and ensure you know the true differences between the cloud version of an app and the one you have now. Spoiler alert – sometimes they’re vastly different, and your favorite feature might be missing.
When starting to plan your move, Praecipio recommends you begin vetting your app list and ask yourself these 3 questions:
How many apps do I have?
Do I need them?
Does the app move to the cloud?
Don’t be afraid to vet the list a few times. You need the app in both the cloud and on-prem for the data to move. If the app is not available in the cloud, ensure you have a plan B.
Users and Groups
Users and groups are another big ticket item when it comes to migrations. Whether your user management system is Jira itself, active directory, or a 3rd party application, it stands to reason there will be cleanup involved. As of version 1.7.7, JCMA (Jira Cloud Migration Assistant) does offer some in-line options to do some of the cleanup on the fly. Overall your best bet is to try to take care of them ahead of time, especially if you’re migrating Confluence also. Praecipio recommends the following things to look for:
Remove Duplicate Users. Admin accounts especially may come across as a duplicate user
Remove inactive users
Ensure all users have a valid email
Take your time with this; it may take a few passes to cleanup effectively.
Projects and Data
Now that we’ve passed the first two hurdles, we can start thinking about Jira Projects and the configurations that come with them.
Create a table, lay out all the projects or spaces you’re looking to migrate, and find someone to own that project. Very often we see instances where someone has moved on from the company and left behind all their project data for someone else to trip over. If nobody is using it on-prem, chances are they won’t need it in the cloud. You can also leave behind that 7 year-old project someone made to organize cleaning out the community fridge.
Praecipio recommends the following when cleaning up configurations:
Don’t let cleanup block you from migrating. If it's the difference between pulling the trigger and 3 months of revisions, pull the trigger.
Consolidate Jira priorities. Priority schemes do not exist in the cloud. When schemes migrate from on-prem, they merge into one consolidated scheme.
Check for projects that use the Default Configuration Schemes. Jira Cloud already has defaults, so when you take a project that is using the on-prem default issue type scheme, it will copy over with (migrated) in its name.
Find out what migrates and what doesn’t. Dashboards and filters do not migrate to the cloud. Some app data does not migrate. Custom fields do migrate.
Go forth and conquer
Like most migrations, there is a lot of preparation involved. Before the big day, review your instance and take as many measures as you can to ensure a successful cutover. In the end, Jira Cloud is a wonderful tool. Take your time, ask questions, and clean up where you can. If you’re interested in taking a deep dive into frequently asked questions about cloud migrations, you can check out our ebook here. If all else fails, or this seems like too much for you or your team to tackle, you can always reach out to us here at Praecipio. We’d be more than happy to help.