Cloud Migration, Guides

Prepare & Plan Your Jira Server-to-Cloud Migration

Contents​

 

Why Go from Jira Server to Jira Cloud?

#1) The world is going Cloud. It’s where most critical business applications are going because the SaaS model puts the burden of security, reliability, speed, and scalability on the tool provider (not on you).

Questions to quickly ask yourself:

  • How much does procuring and managing the on-premise servers and databases to host applications cost?
  • What are the monthly salary expenditures of your infrastructure team (IT, Security)? Let’s not mention organizational churn and the risks of carrying that burden.

It’s the golden age of Cloud computing… it’s time to get into it.

#2) Atlassian is going Cloud, too. Atlassian has spent 3+ years investing in Cloud. You get streamlined administration, instant scalability, instant access to new features, security updates, and more. Their investment is their future, too. February 2024 is when Jira Server will be unsupported. If you would have tried to buy Server licenses recently, you must have noticed that Atlassian won’t even sell you the new ones. Going forward, your only choice is either Jira Cloud or Jira Data Center. All current Jira/Atlassian Server customers must use 2023 to plan and execute their migration.

 

Critical Questions Before You Begin Preparations

Cloud migrations are no less than journeys. They start with gathering requirements and getting the right people involved. Here are a few basic questions you should be prepared to answer as you go forward.

NOTE: These questions will help you know what team members need to participate in this process. You cannot do this alone; trust us.

  1. What Atlassian applications and add-ons will be migrated to the Cloud?
  2. What migration strategy are you employing? All at once? In phases?
  3. What are your long-term goals with this move?
  4. Do you have organizational commitment and support around this project?
  5. Is your destination Jira instance procured?
  6. What is your expected timeline for the migration process? Is it realistic?
  7. What is the size and complexity of your current IT infrastructure?
  8. Who are the stakeholders involved? (Think of infrastructure, superusers, tool admins, consumers of Jira reporting, and project managers)
  9. Do you have a budget for the migration process?
  10. What are your security and compliance requirements with your Jira data?
  11. What are your ongoing requirements for data storage, backup, and recovery?
  12. Do you need outside support to ensure a successful migration?
  13. What kind of training gaps do you have for your current Jira users?
  14. What expectations do you have for downtime?
  15. Do you have a migration cutover failure plan?
  16. What are your post-migration support needs?

Intimidated yet? This guide cannot address all of these questions, but you will have to account for them at some point. Every migration is different, but they always involve important, mission-critical data, so keeping all factors accounted for is important.

 

Get to Know Your Resources

Atlassian has invested in great documentation and tools to help you migrate to the Atlassian Cloud platform.

Here are some quick links to helpful content and documentation:

In addition to Atlassian content and documentation, you also have Atlassian Cloud Migration Managers and Migration Support Engineers. These resources can help resolve technical issues and provide guidance but are not fully dedicated resources for your migration.

The Atlassian Community is vibrant and active. Common migration questions, are asked and the search bar can be your biggest friend when you need a quick answer. For unique questions, Atlassian Support Engineers do their best to respond quickly, especially for up-voted questions.

Lastly, there’s Atlassian Solution Partners (like Trundl). They are your best bet for hands-on-keyboard support and best practice guidance for your particular Cloud Migration use case. They work with your team directly and lead the entire Cloud Migration project.

Atlassian Solution Partners should be considered if…

  • Your Atlassian instance is large, complex, or involves mergers before prior to the final migration
  • Your internal teams need help
  • Security and compliance are uniquely sensitive/critical
  • Your Jira instance has 1,000+ users
  • You have an accelerated Cloud Migration timeline
  • You have a lot of critical add-ons (functionality & data must have continuity in the Cloud instance)
  • You need help organizing the project (UATs, upgrades, training, etc.)
 

Determine Your Migration Strategy

Approach: Once you have identified your resources and solution partners to assist you with your Cloud migration project, the next step is to learn how to select the right migration approach. When planning for a migration, it is important to assess what needs to be migrated to the Cloud and which ones to leave behind on your server instance. The focus primarily lies on four key components: Users, Data, Add-ons, and Attachments.

User Migration: You need to decide if you want to migrate the entire user directory or just a specific set of users. If you wish to go for the entire user directory, it will include active, inactive, and also partial users and the migration can be done using Jira Cloud Migration Assistant (JCMA). You can also opt for only partial user directory migration; you can use the CSV methodology for the free upload of users before we migrate data to the cloud instance.

Data Migration: It depends on what you want to migrate to the target Cloud instance and whether it’s an existing or fresh one. If you prefer to migrate only some of the data or a few parts of the data from the Server to a Cloud instance, both are possible using JCMA. At the same, if it is an existing Cloud instance you can go with JCMA, and in case of a fresh Cloud instance, you can directly opt for site import.

Add-ons: Check if the Add-ons are compatible with the Cloud instance. Some Add-ons are compatible with server and Cloud instances, while others aren’t. You need to check with the vendor for the compatibility analysis to ensure a smooth transition.

Attachment Migration: As a new Atlassian feature, JCMA’s attachment migration compatibility with site import is now available. This allows for site import to ‘pre-load’ attachments. Earlier, JCMA was used to upload attachments and link them to the Jira project data that was migrated with Site Import. This ensured that the attachments were visible and accessible on the cloud site. Now, attachments can still be uploaded before or after the Site Import, however, after the site import archive is created, it is enriched with attachment linking data. So, there is no longer a need for a JCMA linking step to be done after the Site Import. Moreover, the attachment linking process using the enricher is faster and more reliable than the old JCMA attachment linking process.

 

Factoring Add-ons for the Migration

Did you know migrating app data can be a real challenge if the compatibility analysis is not done before the transition? Many customers use add-ons to upgrade their features with the Server instance. Most of these add-ons are not compatible with Cloud instances. To troubleshoot it is necessary to determine whether the apps planned for migration are compatible with the Cloud instance. Atlassian collaborates with top Marketplace Partners which enables automated app data migrations using Jira Cloud Migration Assistant and Confluence Cloud Migration Assistant.

Creating an ‘Add-on Compatibility’ document will help to check whether the Server Add-ons are compatible with Cloud Add-ons. For some Add-ons, the data can be migrated to the Cloud instance. Hence, it is recommended to list out all the plug-ins and check with each and every vendor about that plug-in to see if there is any migration path available for that add-on to be migrated to the Cloud.

JCMA also has a feature to compare plug-ins and do the compatibility analysis between Server and Cloud. However, when the information on the app data is unavailable, it too redirects to the vendor.

 

Set Project Timeline Expectations with Your Organization

Do you need help determining the timeframe and budget for your migration? Here’s a rough estimation of the timeframes to get you started:

  • 100+ users: Several hours to a few days
  • Up to 1,000 users: 3 months
  • 1,000 to 5,000 users: 6 months
  • 5,000+ users: 9 months+

These estimations are based on rough calculations and actual timescales may vary depending on the complexity of the project.

 

Secure Your Target Cloud Instance

Migrations have their own timelines, and a typical 7-day trial on a license doesn’t cut it. Get a trial license with terms that align with your Server maintenance subscription. You can get a free Cloud Migration trial for yourself, or you can have a Solution Partner get it for you, along with additional benefits. Ask Trundl, they make it easy, no strings attached.

NOTE: If you have an active Server or Data Center license with more than 60 days of maintenance left, you can get a free, extended Cloud Migration trial for the remainder of your license. If your maintenance has expired or has 60 days or less, you are eligible for a free 60-day Cloud Migration trial.

 

Prepare Your Project Plan

1: Initiation: When the project kicks off, all the documents related to the project are accessed, and risk analysis is done.

2: Discovery: Once the analysis is completed, the migration plan is built based on the current assessment.

3: UAT (User Acceptance Testing): Now, the test environment is created and developed, and test runs are conducted to get client approval.

4: Pre-Production: After the test runs are completed, it is time to create the run books and finalize production migration dates. The rollback plan is also set at this stage.

5: Production Migration: Migration is performed, and smoke testing is conducted. The final client acceptance is taken to sign off the project.

6: Post Migration: At this stage, the documentation is reviewed, and post migration support is determined.

 

Assessing Your Current Server Environment:

The first step in the migration process is to assess your current server environment. This includes identifying the servers and applications you need to migrate and assessing their performance, security, and scalability. Additionally, you’ll need to identify any dependencies between the servers and applications as well as any data that needs to be migrated. This assessment will help you determine what needs to be migrated and how it needs to be migrated.

At the same time, only during the assessment phase, you will be able to find out the difference between Cloud and self-managed deployments such as features, maintenance, and costs. This will give you a fair understanding of what sets Cloud apart and why you need to make the transition.

Prior to the migration, it is important to understand your current server environment and what your team actually needs. Eliminating unnecessary tech stack and streamlining products, workflows, and tools that are effective for your organization can help your team benefit from the transition better. While auditing your current landscape, take note of your Atlassian products, tools, apps, and integrations along with the size and complexity of the data using Cloud Migration Assistants for Jira and Confluence.

Are you wondering how you define the path for identifying these details? How do you take stock of all this information? Worried about how you assess which products and apps you will need in the Cloud?

 

Ask yourself these 8 quick questions:

1. How many products, apps, and tools are being actively/inactively used by your teams, and for what purpose?

2. Are there multiple apps serving the same purpose?

3. Any instance that you were not aware of and if so what do you plan to do with them – keeping them in your Cloud site or archiving them?

4. Is there any app whose functionality and features are already available in the Cloud product?

5. What are your Atlassian product versions?

6. What is the cost difference between Server and Cloud apps?

7. Do you or your team regularly create and maintain customizations for Atlassian products? How often do you update workflows and custom

fields in your instances?

8. Are there any expired app licenses?

Did you know Atlassian provides a more personalized recommendation best suited to your needs to support your migration? Click here to know more. 

 

Clean Up Opportunities

Cleaning up unused data and user accounts with invalid email IDs at the UAT (User Acceptance Testing) phase will make the production migration process smooth. Many Jira teams have inactive data and workflows in their Server instance that need to be addressed. Similarly, the Server instance allows you to create user accounts without a valid email ID, so this is a common problem. In the Cloud, having a valid email ID during account creation is mandatory. So, before moving to the Cloud, make sure to remove all the unwanted data and invalid user accounts so that your Cloud instance will have fresh data and a specific set of users. This will help you keep your storage clean with a lot of free space.

 

User Authentication and SSO for the Cloud

Once you subscribe to Atlassian Access, you will automatically get the option of SAML (Security Assertion Markup Language) single sign-on. SAML enables single sign-on (SSO) for users logging into Atlassian Cloud products from verified domains. Through SSO you can access multiple Atlassian products without having to authenticate each time.

To enable SAML single sign-on, you can go to the Security section of your identity provider and select Identity providers.

You can also refer to Configure SAML single sign-on with an identity provider | Atlassian Support to understand what you must do before you set up SAML single sign-on.

 

Handling Dashboards, Filters, and Project Boards

Though JCMA is used for performing Server to Cloud migration, one of the challenges is that JCMA doesn’t migrate filters, cross boards, dashboards, project boards, notification schemes, etc. They need to be manually migrated using CSV import or might have to be recreated on the Cloud instance. It can also be done by enabling dark features, also known as feature flags.

Feature Flags Description Environment Reference
com.atlassian.jira.migration.dashboard
-migration.feature.enabled		 To migrate all dashboards using JCMA Jira Server
How to migrate all dashboards with the Jira Cloud Migration Assistant (JCMA)
com.atlassian.jira.migration.export
.all.filters		 To migrate all filters using JCMA Jira Server
How to migrate all boards and filters with the Jira Cloud Migration Assistant (JCMA)
com.atlassian.jira.migration.export
.multiprojects.boards		 To migrate all boards using JCMA Jira Server
How to migrate all boards and filters with the Jira Cloud Migration Assistant (JCMA)
com.atlassian.jira.migration.
media-linking.feature		 To migrate attachments using JCMA Jira Server
Jira Cloud Migration Assistant attachment migration with site import
migration-assistant.disable.
app-outdated-check		 To check the outdated version for CCMA Confluence Server
How to install a specific version of the Confluence Cloud Migration Assistant

 

 

Testing and Finalizing the Migration

Before executing a production migration, we advise all customers—no matter the size of the company or the complexity of the migration—to first go through a test migration. In the Testing phase, you need to conduct a trial run to verify that everything is working correctly, estimate the duration of the migration, and identify any potential problems before the production migration begins.

It is also important to back up data from your Server instance and any existing Cloud data prior to migration and conducting User Acceptance Testing (UAT) to ensure common day-to-day tasks work as expected in the Cloud environment.

Once you have assessed the time needed for your test migration, choose a date for the production migration. To reduce the chance of any disruptions or data discrepancies, it is best to choose a time when your team is less likely to need access to your self-managed instance or Cloud site, such as at night or over a weekend. Allow extra time for troubleshooting and if you are migrating more than 1,000 users, ensure to contact your resources at least two months prior to the intended migration date.

Another significant step is to communicate all the details of the upcoming migration and planned timelines to your team. Include information such as when the migration will take place, what downtime users should expect, and ask them to avoid making any changes during the transition. Explain what will happen to the old site after migrating, including whether it will remain accessible or readable, and what the new URL(s) will be.

Additionally, provide instructions on how users will sign in and who they should reach out to in the event of any issues or difficulty logging in. Suggest that users review any onboarding material to become familiar with the new Cloud environment. Lastly, acknowledge that there may be some issues during the migration process and allow an adjustment period for clean-up and to get everything working as planned.

 

Migrating Files and Applications

The migrating phase is the most crucial and highly anticipated phase in the entire migration process. At this stage, you will be able to identify any last-minute issues and resolve them right there, execute your production migration and move your data and users to the Cloud. However, before making the transition, make sure that you have assessed and completed the Pre-Migration Checklist for both Jira and Confluence.

Wondering where you can find these checklists? Here is Atlassian’s pre-migration checklist for you to scan through before launching your migration.

Make sure to put your sites into read-only mode before migrating. For Confluence, remove all permissions except read. For Jira, create a permission scheme with “browse” permission & apply it to all projects. Update site-wide banners to mention read-only mode during migration, then remove when finished. Now it’s time to run the production migration by following the steps outlined for your Server migration project. Once you have identified the App Migration pathways, install, and migrate the apps significant to your requirements to the Cloud.

You can refer to Atlassian’s documentation on how to use the Cloud Migration Assistants to carry out your migration using this method.

 

Post-Migration Testing

Take a moment to appreciate your team for being able to successfully complete the migration with proper planning, preparation, and execution. Once you have migrated your apps and users, check to see if the migrated data are working as expected by performing post-migration testing. You can also refer to Atlassian’s Testing Guide while reviewing your data. 

Now that you have successfully migrated to Cloud, make sure to incorporate these last few steps to help your users finally get started with an upgraded working system in Cloud.

Check Atlassian’s “Getting Users Started in Cloud” documentation for more clarity.

1. Send out a communication to stakeholders with key information:

Inform them that the migration has been successfully completed, why this transition was done, and how they can get started with it. Here are a few instructions that can be communicated.

    • Bookmark the new link to your Cloud site
    • Provide instructions on how end users will log in
    • Specify what must be reset (e.g. avatars or passwords, if not using SSO)
    • Outline any changes to apps or functionality
    • Inform users of the training that will be provided
    • Make it clear who to contact for help

2. Help your team get used to Cloud:

Set aside some time besides working hours dedicated to help your team solve any post-migration issues. You can also create a Slack room for post-migration issues, feedback and questions.

3. Let go of your Server instance:

Back up data for audit purposes and let your maintenance expire if no longer using Server instance.

 

Get the Support You Need Now!

We will be happy to provide you with free advice, and if needed, an end-to-end Migration solution. At Trundl, our team of migration support engineers will help you move to the cloud by resolving technical issues and providing additional guidance if needed. Experience a seamless transition from the data server to the cloud by leveraging Atlassian’s cloud features and tools such as the free cloud migration trial and cloud migration assistants for Jira and Confluence. So, what are you waiting for? Reach out to us now!

Disclaimer: The views and opinions expressed in this article are exclusively those of the author and do not necessarily reflect Trundl’s official policy. Please note, the information provided may be subject to change.

 

Now it’s your turn:

Tell us what you think of this article. Would you like to suggest a correction? Do you need further help with the next steps? We’re all ears! Please write to us!
Get an estimate for Jira Server to Jira Cloud Migration
Drop us a line, we will get back to you on Licenses, Deployment and Support