Australian software company Atlassian has admitted that migration tools it developed for moving Jira users to the cloud were slower than the older systems they replaced, forcing the company into an expensive engineering effort to fix the problem before it could serve its largest customers.
The company built tools to move Jira users into the cloud that were actually slower than older code that did the same job, according to engineering leadership. Atlassian's migration platform team built a migration pipeline on an API-driven architecture that proved to be blocking and less scalable, and customers were too large to migrate using this approach.
The problem became apparent during testing. When Atlassian tested the new migration pipeline, the company found it took about 34 percent longer than its previous tools, and overall work item throughput dropped by roughly 60 percent on synthetic tests. For a company pushing enterprise customers toward mandatory cloud migration, this was untenable.
The fixes Atlassian implemented reveal how much engineering work was required to recover basic performance. The company benchmarked different worker node sizes and configurations, finding that scaling up nodes from the original small setup yielded significantly better throughput, balancing cost against performance. Beyond that, Atlassian discovered a configuration error: polling timeout was set to 40 seconds when work item processing took 60-120 seconds, causing batches to be retried mid-flight and slashing throughput by 30-40 percent, which was resolved by setting the timeout to 300 seconds.
The company also fixed autoscaling logic that caused migrations to start slowly. Atlassian implemented a mechanism to proactively ensure a minimum number of worker nodes were running whenever a significant migration kicked off, which shaved 30 to 60 minutes off migration time while reducing monthly infrastructure costs by up to A$65,000.
Scaling for enterprise
These incremental fixes compounded into substantial gains. The engineering team reported achieving 6x improvement in throughput for large migrations. End-to-end, the system migrated over 6,000 projects in a single day, with the company now ready to serve 50,000-seat Jira customers.
The migration performance issue sits within a broader context of forced cloud transitions. Atlassian decided last year to discontinue its datacenter products and shift users to cloud equivalents, five years after the company killed its server products. This means many existing customers face a second forced migration in a decade, raising questions about the pace and planning of Atlassian's platform strategy.
For customers with large, complex Jira deployments, these performance improvements are necessary but not sufficient. The broader challenge remains: No feature matching, nor migration path is guaranteed for Marketplace apps, which might create difficulties when assessing, migrating, and matching functionality during the transition. Some customers operating legacy systems integrated with Jira have concluded the cloud transition is not viable for their operations.
Atlassian's engineering transparency about the initial failure is commendable. The company identified the problem, invested significant resources to fix it, and validated the solution at scale. But the incident illustrates a tension in the company's cloud strategy: building migration tools that handle edge cases and maintaining backward compatibility with complex customer environments requires different engineering than optimising for common cases in a cloud-first architecture.
For more information on Atlassian's migration assistance programme, see the company's technical analysis of the performance optimisations. Customers facing Data Center end-of-life should review Atlassian's migration acceleration guidelines.