Introduction

Migrating from a server to a cloud-based system is a pivotal step for businesses seeking enhanced efficiency and scalability. However, when it comes to Jira, this transition is far from straightforward. This blog post delves into the intricacies and challenges of migrating Jira from server to cloud.

The 25 Reasons

Here are several items I came across during the process that I think you should know:

  1. JCMA has a lot of bugs: Boards or filters or plans for advanced roadmaps not migrating, JCMA breaks in the middle of the process, you name it. Sometimes, the strategy involves multiple migrations with different versions of JCMA to bypass these bugs or to migrate more elements.
  2. A new release of JCMA is launched all the time, and you must decide whether moving to the latest version is beneficial for the project or if you should stick with the version you used in staging, since with that version you really know the outcome and all the bugs that have already been found.
  3. A comprehensive assessment is essential to determine what will be migrated and what won’t, the strategy for Jira and each plugin, and a runbook detailing all planned actions.
  4. Some clients have other Atlassian products and multiple instances to consolidate, and in this case, you will have to bring everything to the on-premises environment, consolidate everything there, and the final migration is to the Cloud.
  5. Communication about the plan and timeline must be constantly reported to Atlassian, especially for large clients, as a team may need to be on standby during the production migration phase.
  6. Often, database interventions are necessary to correct numerous objects for migration, increasing the risk of breaking something or requiring extensive post-migration analysis, which can take several hours.
  7. Issues and archived projects must be fixed, whether due to missing issue types or statuses. A dark feature is currently needed for their migration.
  8. Some apps are migrated via JCMA, others are not. This is where much of the time is spent adapting for the cloud or creating a runbook efficient enough to migrate everything over a single weekend.
  9. For some apps, conversion to cloud is entirely manual, demanding significant time from the migration team to redo all configurations.
  10. Many clients need help cleaning up configurations and custom fields. As on-premises environments provide database access, this is their last chance for such cleanup, since after everything is in Cloud, only REST API access is available, making the process more difficult and less comprehensive.
  11. Dashboards are unlikely to migrate without numerous errors or missing gadgets.
  12. User data must be fixed before migration, such as missing emails, invalid characters, or duplicate emails.
  13. Each pre-migration check to identify errors can take hours, and it’s common to encounter communication breakdown errors, interrupting the process and requiring log analysis to identify the cause.
  14. Larger clients may need several scripts: to make projects read-only, consolidate groups, merge duplicated fields, and so on.
  15. Support for some apps is poor, causing migration delays due to slow responses, whether for migration guidance or information on where data is stored and certifications like SOC 2.
  16. Apps migrate differently. While some tie data to the project being migrated, others transfer all plugin data to the cloud, regardless of whether the project is included in the plan.
  17. Plugin gadgets and custom fields definitely won’t migrate. For some clients, we’ve had to convert plugin custom fields into Jira custom fields to avoid data loss.
  18. Many clients prefer migrating only relevant users, requiring extensive analysis and strategic planning.
  19. The client is not always aware of what is not migrated to the cloud. It’s important to highlight these aspects and have a meeting with the client to explain what will not be migrated, to avoid leaving them frustrated in the middle of the process.
  20. Scripts from Script Runner must be converted for the cloud version, and depending on complexity, some may not migrate or will have limitations.
  21. Your workflows lose their design (status locations are lost), which is critical for some clients.
  22. Scripts must be run in the environment to remove tags like “(migrated)” that Atlassian introduces in all custom fields and field configurations post-migration.
  23. Workflows lose all properties and triggers, so you’ll need to reconfigure them manually in the cloud or create a script for assistance. This script must modify workflows in draft mode and publish them automatically, adding further complexity to the solution.
  24. Automation for Jira must be redone in the cloud, so for clients with hundreds of automations, I usually use a script, but even then, they must be reviewed.
  25. Sometimes the list of features of an app in the cloud is quite different from what is in the on-premises app, and some of these features are important to the client, creating more frustration. Some vendors have a very clear feature parity list, while others do not.

Conclusion

Migrating Jira from a server to the cloud is a task laden with challenges and potential pitfalls. It requires careful planning, patience, constant contact with the Atlassian engineers, a deep understanding of both the server and cloud environments, and a strategic approach to manage the numerous technical and logistical hurdles.

However, despite these complexities, the transition to the cloud can offer significant benefits in terms of flexibility, scalability, and future-proofing your project management tools. By being aware of the potential issues and preparing accordingly, organizations can navigate these waters successfully and emerge with a more robust and efficient system.