Skip to main content

We migrated from BitBucket to Jira. Several times.

A few boxes in a yard, waiting to be moved into the house after a move. A nearly unloaded truck is parked nearby.

Managing IT projects is often like running on a treadmill: everything is fine as long as you keep moving but the movement is not actually your decision. 

Historically any major decent repository service (GitLab, BitBucket, GitHub just to name a few) also included an issue tracker alongside other features. A company we worked in the past used to create a separate repository for the issues. This was especially useful for projects with separated codebases (e.g. backend and frontend repositories).

One of our projects was using such a Bitbucket repository only dedicated to issue tracking and the customer was happy about it. In fact, they liked it much more than we did, as we much prefer Trello or our self-hosted GitLab (more about why we use a self-hosted GitLab in a future post). Everything looked good.

Then, towards the end of February 2026 we received an Atlassian email to inform us that issues and wikis would be discontinued at the end of August 2026 (see the announcement). Now, six months may sound like a lot of time but that is not necessarily the case:

  • you may not be able to jump immediately to it
  • you have to decide and discuss with the customer where else to move
  • you need to plan and build a migration that keeps all issues, users and history
  • you want to complete the migration way before the final deadline
  • you definitely want to test the migration at least once

We proposed our alternatives but the customer expressed a preference for Jira. The good part is that, being another service in the Atlassian ecosystem and the suggested way forward by BitBucket itself, it looked the perfect choice. Right? We immediately identified an automated tool provided by Atlassian and we expected the migration to be straightforward, allowing us to transfer the existing issues together with their history without significant challenges.

Boy, were we optimistic.

From the very first attempt it became clear that the process depended not only on the migration tool itself but also on the complex combination of permissions, configurations, and settings governing both environments. Every problem we solved seemed to uncover another one: once permissions were fixed, configuration constraints emerged; after resolving those, additional dependencies had to be investigated.

Even AI played only a limited role in this project. Atlassian documentation is extensive and constantly evolving, and customer-specific configuration scenarios do not always have a clear or up-to-date solution. As a result, the most effective approach was hands-on experimentation. In other words, the good ol’ “test and fix” iterations.

In the end we performed several test migrations. We were able to identify critical issues, adjust the configurations, and progressively validate the migration process. Each migration was followed by functional testing to ensure that issues, workflows, assignments, and history had been transferred correctly. As usual, co-operation between our team members and the customer staff made all the difference, enabling us to quickly share findings, address problems one by one, and ultimately establish a reliable and repeatable migration process.

Conclusions: there are no easy things in software projects, except naming and clearing cache (yes, irony light is on). Our experience confirmed that, even when a solution appears straightforward because it is natively supported by the tools… it’s not.

But we won again! And there is one less dragon around.