BDQ's in-house Cloud Migration tools

BDQ stands for Business Data Quality - we started out doing data quality tooling for data migrations so we are very familiar with problems that can occur while migrating data. Throughout all of the various migrations we have performed, we’ve used the experience of our in-house Atlassian Experts to develop bespoke tools that help to smooth out bumps in the road we encounter during the process.

Here at BDQ, we specialise in Cloud Migrations. We are Atlassian Solution Partners and have performed migrations from Server and Data Center to Atlassian’s Cloud for companies of all shapes and sizes - from small boutique companies, all the way up to global Enterprises. We often come up against the same problems over and over again. Problems like finding duplicate email addresses, finding inactive or deleted users, user permission changes and other much more technical issues. Fortunately, we have fantastic Atlassian Experts with a deep knowledge of Atlassian systems and IT solutions on staff that have developed programs, automations and workflows that enable us to offer a painless, professional migration process to customers of all sizes.

Addressing uniqueness

One of the most difficult and reoccurring issues we find during an Atlassian Cloud migration, is the duplication or complete lack of email addresses. When using Jira or Confluence Cloud, all users must have an email address and that email address must be unique as the email address is one of the key identifiers for a user. This can have knock-on effects with users owning things, having access to things and making sure that they have the correct access permissions.

This issue can be compounded by also encountering inactive or deleted users, especially those that own particular parts of the configuration of the products you are trying to migrate. This will cause those items to not migrate when you are using the Jira Cloud Migration Assistant (JCMA) or Confluence Cloud Migration Assistant (CCMA), so it is incredibly important to find and address these problem items. And as your instance grows and/or ages, the number of these kind of duplicate, deleted and inactive users increases, complicating you migration even further.

We have developed a tool that takes the standard output reports from JCMA and complies the data a slightly more digestible format - the output logs are the facts of the situation but our tool reformats the data and makes it easier to follow.

Unfiltered problems

Another issue that we often find is that migration assistants such as CCMA and JCMA don’t have the functionality out of the box to migrate things like filters, automations, dashboards and boards across from your Jira Server/Data Center to Atlassian Cloud. It does seem like Atlassian are in the process of changing this, as there is a “dark” feature - a kind of preview if you will - of the function that may appear in the tool later on. But for now, an after market option is the only choice. We have developed our own way of checking for and migrating across the items that the standard tooling might miss, meaning that when we migrate you, all the items you are expecting to find and are used to seeing/using, will be there waiting for you (although they may look or feel slightly different.)

Another issue, especially should you decide to perform the migration yourself, is the temptation to remove parts of your instance that you know longer need before migrating. While this may seem like the perfect time to descope and declutter your instance by deleting or archiving the superfluous projects, this can have wider ranging implications. This also applies for any Jira projects that have been deleted or archived in the past. One example is JQL filters. You may have Jira filters set up that rely on those projects and once they are removed, the filter no longer works as desired. In order to safely remove unwanted items and repair any broken links from items previously removed, we have developed tooling that helps with modifying the JQL to edit the filters and remove the missing content.

Our approach

One of the main things that performing so many Atlassian Cloud Migrations has taught us, is the way we want to approach the work involved. We opt for a “test first” approach, that revolves around multiple iterations, keeping a runbook to track the steps and performing as many pre-flight checks as possible to ensure that everything is ready before the final product migration. Atlassian provide a number of different tests, which they call the “preflight”, which are pieces of SQL that you can execute against the underlying repository underneath Jira to identify some of these issues. We have taken that outline, and added additional tests for various other different problems that we found during previous customer migrations.

We have taken all of these different tests, both Atlassian’s and our own, and added them in to a harness that provides us with an output report, detailing all of the problems that will occur if we were to attempt the migration as it stands. This allows us to deal with the issues in the reports, develop the runbook, then run the test program again, and again, and again until we have identified all those issues, resolved all those issues, and we are confident that when we move into the production Cloud migration, that we're going to get the result that we all want.

However, the last thing we want to do is prolong the amount of time your Jira or Confluence migration takes with unnecessary or excessive testing. To this end, we have developed some reporting tools that will assess the source system and the target system and inform us of the differences between the two. Using this tool allows us to see what has migrated and what hasn’t. This is especially helpful when looking at things such as permissions.

UAT and you

The other part of a successful Atlassian Cloud migration, other than making sure that everything works as expected afterwards, is making sure that you, the customer, understand and are happy with how/what we are doing. This user acceptance testing (UAT) allows us to get your feedback and make any alterations you require as we go. Again, as with the preflight tests, we will perform the UAT as many times as we feel are necessary to ensure your satisfaction before we start the main production migration.

We have also developed a utility script that provides us with a progress indicator, which is another useful item that is missing from the migration tools that are publicly available. This tool polls the rest API on and provides us with a number that represents the exact percentage for how much of the migration that is complete.

In some instances, the customer may want to keep their old Jira Server system up as an archive or back up. We have configured a tool that acts as a bulk archive permissions scheme editor. This means that we can go through the archived system and remove write access for the users. This is useful as it also allows us to very quickly go back in and allow access to the archived systems should the customer need it. As most companies don’t have a flat read/write only permission scheme, the tool allows us to only restore only the level of access a user had before we ran our tool and avoid possible breaches.

Summary

So there you have it. Just a few of the bespoke tools we have developed in order to provide customers like you with a painless, professional Atlassian Cloud migration experience, so you can enjoy the benefits that Jira Cloud and Confluence offer. We also offer enhancement hours should you decided to make further quality of life changes or improvements after your migration has been successfully completed. You can find more details on our Enhancement Hours here.

If you are thinking of migrating your Confluence or Jira instances from Data Center or Server to the Atlassian Cloud, please consider using a certified Atlassian Solution Partner like BDQ to help you make it through with the least possible disruption to your day-to-day activities. If you have any questions, please don’t hesitate to get in touch, let’s talk about what you need.