Migrate Jira and Confluence To The Cloud

Migrate Jira To Cloud Issues

Atlassian’s Jira Cloud Migration Assistant or JCMA tool includes:

• A run-book and pre-migration checklist. This addresses many common issues up front that would prevent the Atlassian Server from communicating with the Atlassian Cloud.
• Dark Features, which help to work around persistent user-name issues.
• The REST API, in the form of python scripts to assist in the partial environment reset between migration attempts.

While JCMA can handle the bulk of the migration of project configuration and data from the server environment to the cloud, it doesn’t do a perfect job. Indeed, certain things “refuse” to migrate, since there isn’t a perfect one-to-one swap of technical features between the server and the cloud.

There was also the need to evaluate third-party Jira apps to determine what would be applicable in the cloud environment. And SPK had to help the client upgrade the memory and heap allocations to allow JCMA to even operate.

Unfortunately, since this client had already begun the migration on their own, we were forced to work with Atlassian cloud-migration managers to extend the various trials, as we essentially restarted the project from scratch.

Migrate Confluence To Cloud Issues

The Confluence migration process is ostensibly straightforward; there’s a Confluence Cloud Migration Assistant (CCMA) tool available for it.

But the reality was not so simple. We needed to evaluate third-party Confluence apps to determine if they would be compatible with—or even available for—Confluence Cloud. And the memory and heap-allocation issues from Jira were mirrored here: Both server virtual machines (VMs) required upgrading, since their memory resources fell below Atlassian’s basic requirements for migration.

Then there was the big revelation: We soon determined that migrating the apps through the CCMA tool was neither efficient nor consistent; surprisingly, migrating the apps manually (by searching the marketplace and finding their cloud equivalents) proved far more productive.

Other Confluence migration issues also needed to be resolved:

• We encountered an issue, pre-migration, that was blocking the test users from logging into Confluence with their company credentials; this was because their email addresses had multiple aliases. SPK and the client worked together to resolve this issue and after another test migration we were able to confirm the issue was no longer a concern.
• The CCMA tool itself was getting updated almost monthly. With each update came new concerns about what may have changed—or gotten broken—after an update.
• In our post-production migration checks, we discovered that the Jira macro-repair tool wasn’t converting all of the Jira macros embedded on pages within Confluence. Working extensively with Atlassian to resolve this, we created a site backup of the cloud, changed the Jira macros at the database level using a SQL query script, and then tested the fix.
• As it turned out, over 2,000 pages were impacted by this issue. This wasn’t easy to resolve, since most of them were drafts that had migrated over from the server; simply deleting them would have had a serious effect on the data if it was ever updated by a user.

From Zero To Full Speed In No Time

After the client’s initial struggles on their own, SPK was able to get everything, in both Jira and Confluence, migrated in a few months. Most of that time, incidentally, was spent working with the Atlassian migration-support team to resolve issues, and performing a total of eight discrete test migrations.

Today, this client is happily running Jira and Confluence in the cloud. All their data is preserved and accessible. Notably, it’s not going to be the victim of Atlassian deprecation, so there’s no longer the fear of data getting lost.

They’re saving money, too. The cloud-based solution isn’t just more reliable and always up-to-date; it’s also more scalable. New users can be added quickly, and cost-effectively, in just minutes.