Jira Cloud Migration: The Testing Checklist You Can’t Ignore

Migrating to a new Jira Cloud instance is a daunting process, and it comes with plenty of moving parts, spanning your workflows, user base, and active backlog.

Based on our experience, though, we can't say it enough: test, test, and test again. In this guide, we’ll explain the dangers of taking shortcuts at the testing phase and will cover our full Jira Cloud migration testing checklist.

The Importance of Testing for Jira Cloud Migration

In our experience supporting migrations, we’ve seen how skipping or limiting the testing phase can result in unexpected issues surfacing once the system goes live. These situations are always preventable, and they underline just how important a thorough testing process is.

At the project post-mortem stage, the key question is why there wasn’t a sufficiently robust testing process in place. Should our consultants be pushing harder to test every element of every workflow scrupulously? Or is the issue that the project didn’t fully scope out what mattered most to the client’s teams?

We conclude that it’s a bit of both, and that’s why we view the significant task of project management as being just as important as technical work during a migration. 

Jira Cloud Migration Testing Overview

Our Jira experts have experience in handling dozens of large-scale migrations. Based on this, we advise that any good migration plan should include the following steps. There should be:

• Clear responsibilities for testing
• A comprehensive checklist of what needs to be verified 
• Enough time to fix issues before launch

Having backups in place is indispensable and means that the migration can be rolled back in a worst-case scenario. However, reversing the migration will create significant disruption for your organization, wasting time and money, and it won’t make your teams any happier about the process change, so it should only be considered as a last resort.

Clear responsibilities

In any given project, it’s useful to have a project lead who serves as an ultimate point of responsibility and authority. They’re in charge of the schedule, measuring performance, and allocating resources, as needed.

This is particularly important when handling a complex process like a migration, which will touch teams across the organization and has the potential to significantly disrupt work if it goes off the rails. Quality assurance is a key part of this, making sure that there’s space laid out for a realistic schedule, including substantial leeway for unforeseen issues.

You can also get ahead of issues by ensuring that there is clear communication with your teams, explaining what is happening, when, and why, and welcoming engagement in order to make the change process more manageable. This is a core part of the project and should be a key responsibility for the project leader.

A Comprehensive Testing Checklist

As part of the testing process, you’ll need a full checklist of all the functionality and features that need to be reviewed ahead of launch. Naturally, you shouldn’t make assumptions. You’ll likely learn a great deal by checking in with your teams and engaging representatives on how they actually use the product, helping you to identify features that might otherwise be overlooked or underappreciated.

Your testing checklist should include:

• All the day-to-day processes in your projects (such as creating, updating, and transitioning issues) and the issue types you use (with a particular focus on customized elements)
• The functionality used for your backlogs, boards, and sprints
• How your data appears once migrated into the new instance (with close attention being paid to custom elements and fields)
• Whether group names and configuration settings could create conflicts
• All the user permission levels active on your instance, and the ability of users to access relevant features and information
• Your security settings, access controls, and firewall rules
• All your processes running via Marketplace apps and third-party integrations (and with other Atlassian products), and how structural changes will affect dependencies
• How your data center and cloud site will work, and your storage needs and capacity
• Confirmation that all crucial data is backed up at each stage

Before the final migration runs, you’ll want to switch your old instance to read-only mode to stop any new data from being entered. This switch-off should form part of the testing process and should be coupled with messaging for users explaining what is happening and when.

Ensuring your security settings and user permissions are deployed correctly on the new instance is also of particular importance. If you have duplicate or unused accounts or redundant integrations, then it’s sensible to remove them before the migration goes ahead to reduce vulnerabilities that could give intruders access to your systems (as well as reducing the amount of data that needs to be migrated). It’s also a good opportunity to roll out two-factor authentication, if it hasn’t already.

It’s also important to involve representatives from different teams (including your dev, security, and support departments) to help identify issues that might not otherwise emerge in general testing.

Atlassian’s Cloud Migration Assistant can help you connect to your cloud site and run trials. The tool can also be useful by providing a post-migration report and error log once test migrations have run, flagging issues that have emerged.

Time to Fix Issues

Having a plan isn’t the end of the process, of course. Once you’ve identified issues, you need to have enough time built into the schedule to allow you to resolve them, so you can launch the new instance with a high level of confidence that your data and workflows are intact.

It’s very important to allow for enough time to run thorough testing, connecting the migration team and testers, and then implement fixes. You can assume that anything that’s not identified at this stage will not get fixed and that any unresolved issues will create bigger problems later.

Atlassian recommends running testing for one month ahead of a cloud migration, with this phase taking up 25% of the overall migration project workload. This gives you plenty of time to find and address issues and re-run test migrations until you’re happy with the outcome (ensuring, each time, that previous iterations of the new instance have been fully removed).

It’s also worth noting that the migration process isn’t instantaneous. Atlassian advises that the Jira Cloud Migration Assistant can deploy between 5 million and 21 million issues in 24 hours, depending on your level of optimization.

With this done, you can schedule a migration date (selecting a slot that will result in minimal disruption for your organization) and set out on final preparations for the process.

Conclusion

While running a business can be like the process of building an airplane engine mid-flight, our firm recommendation is to pursue a policy of measure twice, cut once when it comes to the delicate process of Jira Cloud migrations.

Trying to fix issues after the fact or, worse, rolling back the migration will waste time and resources and significantly dent the enthusiasm of your teams for the project. In addition, if your new instance comes with default passwords, open user access permissions, or reduced multi-factor authentication requirements, then it could open up significant security vulnerabilities for your organization.

Our take is outlined in this formula:
Proper Testing + Early Fixes + Repeating in Production = A smooth user experience for everyone

Pursuing thorough assessment, planning, and testing can also help identify duplication and redundancies, so the process also allows you to streamline and optimize your use of the product. In addition, it gives you the chance to review your use of apps and train your teams on new (or existing) functionality, allowing you to start afresh with an upgraded platform and set of processes.

If you want to learn more about this topic, don't hesitate to get in touch with our team.