Communardo - Azure Migration
Azure DevOps is like a fully equipped commercial kitchen: everything is there, everything is built in, and after years of use, you have set up your favorite drawers exactly where you need them. However, operating costs are rising, the licensing model is no longer up to date – and sometimes you wonder whether it could be a little less monolithic.
A customer with an impressive Azure DevOps landscape – including heaps of custom fields, individual ticket types, specially defined dropdowns and creative extensions – was faced with precisely this question. And one challenge in particular: how do you migrate such a monster into the Atlassian stack without loss, without the development teams suddenly finding themselves without their bugs, pipelines and pull requests on Monday morning?
Spoiler: It works. But it takes patience, precision – and a good deal of in-house development.
Initial situation
The customer had been using Azure DevOps intensively for years: from work items and repositories to pipelines and test plans. But above all: highly customized.
There were separate ticket types, cross-project custom fields, relationships between bugs, epics, tasks and PRs – in short: a lovingly optimized but highly individualized system.
The desire to switch to the Atlassian stack (Jira, Bitbucket, Confluence & Co.) came from several directions:
Azure DevOps license model too inflexible
Jira already established in parts of the company
Technical harmonization desired
Better integration with other systems outside of Microsoft
The requirements were anything but trivial: all data had to be migrated – completely, comprehensibly and in such a way that the history was preserved. No “start again”, no “we’ll only export the most important things”, but a migration at a surgical level.
Implementation
Phase 1: Disillusionment with on-board resources
The first idea: maybe there’s an easy way. Azure DevOps offers some export functions – but the disillusionment came quickly. Although you can export CSV files, everything that goes beyond standard tickets (i.e.: everything) is kindly ignored. Relationships between tickets? Gone. History? Not a thing. Pipelines, repos, test cases? Not provided.
So the strategy was adapted: API instead of hope.
Phase 2: API-supported migration
The focus was now on a clean, traceable data export from Azure DevOps – completely via the REST APIs. And in such a way that:
Work items including custom fields and states are retained
Links between tickets, bugs, epics, tasks, etc. can be mapped
histories, comments and attachments are recorded
repositories including branches, tags and PRs can be mapped
pipelines, build definitions and test plans can also be exported
It was clear early on that an existing tool would not be able to do this. So we developed our own export tool – tailored to the customer’s complex structure.
Phase 3: Iterative migration with trial exports
Several test exports were carried out with the tool in hand. These test runs were primarily concerned with:
Correct mapping of all fields from Azure DevOps to Atlassian
Validation of repositories and PRs
Ensuring data quality for complex links
Detection of cases in which 1:1 mapping was not possible
Each iteration brought new insights: A field type that had three states in Azure but only two in Jira. A ticket link that was logical in Azure but led to a circular argument in Jira. And, of course, small pitfalls such as misinterpreted TimeStamps or Unicode characters that had their own agenda.
All of this was solved step by step – with mapping tables, transformation rules and a lot of logging in case a ticket “slipped through”.
Phase 4: Final export – without standstill
After around three months, the setup was complete: The tool was stable, the mapping was clearly documented and the data was complete. The final export was carried out on a weekend – parallel to the import into the Atlassian stack. Thanks to a high degree of automation and prepared migration scripts, the switch was completed by Monday morning. The teams were able to continue working straight away – as if nothing had happened.
Result
The switch from Azure DevOps to Atlassian was not only smooth, but also virtually loss-free. The results at a glance:
The entire migration was prepared, tested, documented and implemented in just three months.
High customer satisfaction, as all requirements were met: complete receipt of tickets, relationships, histories, repos, pipelines and test plans.
Data loss of less than 1%, mainly due to inconsistent special cases that could not be mapped – and were already identified during preparation.
No downtimes, as exports and imports were processed automatically within a narrow time window.
Long-term license and cost benefits through consolidation on Atlassian products.
Conclusion
Big migrations don’t need drama queen moments, but clear goals, good preparation – and sometimes a bit of DIY. Switching from Azure DevOps to Atlassian is no walk in the park, but it can be done with the right tools and the necessary care. The key lies not in a complete off-the-shelf solution, but in a process that takes into account the specifics of the customer.
And the best thing is that the development teams didn’t even realize on Monday that they were now working with a completely new system. If that’s not a good sign.