Communardo – Azure Migration
Azure DevOps ist wie eine voll ausgestattete Großküche: Alles ist da, alles ist eingebaut, und nach Jahren der Nutzung hat man sich seine Lieblings-Schubladen genau da eingerichtet, wo man sie braucht. Nur: Die Betriebskosten steigen, das Lizenzmodell ist nicht mehr zeitgemäß – und manchmal fragt man sich, ob es nicht auch etwas weniger Monolith sein darf.
Ein Kunde mit einer beeindruckenden Azure DevOps-Landschaft – inklusive haufenweiser Custom Fields, individueller Ticket-Typen, eigens definierter Dropdowns und kreativer Erweiterungen – stand genau vor dieser Frage. Und vor allem vor einer Herausforderung: Wie migriert man so ein Monster verlustfrei in den Atlassian Stack, ohne dass die Entwicklerteams am Montagmorgen plötzlich ohne ihre Bugs, Pipelines und Pull Requests dastehen?
Spoiler: Es geht. Aber es braucht Geduld, Präzision – und ein gutes Stück Eigenentwicklung.
Ausgangssituation
Der Kunde nutzte Azure DevOps über Jahre hinweg intensiv: von Work Items über Repositories bis hin zu Pipelines und Testplänen. Aber vor allem: stark angepasst.
Es gab eigene Tickettypen, projektübergreifende Custom Fields, Beziehungen zwischen Bugs, Epics, Tasks und PRs – kurz gesagt: ein liebevoll optimiertes, aber hochgradig individualisiertes System.
Der Wunsch, auf den Atlassian Stack (Jira, Bitbucket, Confluence & Co.) zu wechseln, kam aus mehreren Richtungen:
Lizenzmodell von Azure DevOps zu unflexibel
Jira bereits in Teilen des Unternehmens etabliert
Technische Harmonisierung gewünscht
Bessere Integration mit anderen Systemen außerhalb von Microsoft
Die Anforderungen waren dabei alles andere als trivial: Alle Daten sollten migriert werden – vollständig, nachvollziehbar und so, dass die Historie erhalten bleibt. Kein „Neu anfangen“, kein „Wir exportieren nur das Wichtigste“, sondern eine Migration auf chirurgischem Niveau.
Durchführung
Phase 1: Ernüchterung mit Bordmitteln
Die erste Idee: Vielleicht gibt’s ja einen einfachen Weg. Azure DevOps bietet einige Exportfunktionen – aber die Ernüchterung kam schnell. Zwar kann man CSV-Dateien exportieren, aber alles, was über Standard-Tickets hinausgeht (also: alles), wird dabei freundlich ignoriert. Beziehungen zwischen Tickets? Weg. Historie? Fehlanzeige. Pipelines, Repos, Testfälle? Nicht vorgesehen.
Also wurde die Strategie angepasst: API statt Hoffnung.
Phase 2: API-gestützte Migration
Der Fokus lag nun auf einem sauberen, nachvollziehbaren Datenexport aus Azure DevOps – komplett über die REST-APIs. Und zwar so, dass:
Work Items mitsamt Custom Fields und States erhalten bleiben
Verknüpfungen zwischen Tickets, Bugs, Epics, Tasks etc. nachgebildet werden
Historien, Kommentare und Attachments erfasst werden
Repositories inkl. Branches, Tags und PRs abbildbar sind
Pipelines, Builddefinitionen und Testpläne ebenfalls exportiert werden können
Es war früh klar: Ein bestehendes Tool würde das nicht leisten. Also wurde ein eigenes Export-Tool entwickelt – maßgeschneidert für die komplexe Struktur des Kunden.
Phase 3: Iterative Migration mit Probeexporten
Mit dem Tool in der Hand wurden mehrere Probeexporte durchgeführt. In diesen Testläufen ging es vor allem um:
Korrektes Mapping aller Felder von Azure DevOps zu Atlassian
Validierung der Repositories und PRs
Absicherung der Datenqualität bei komplexen Verlinkungen
Erkennung von Fällen, in denen keine 1:1-Abbildung möglich war
Jede Iteration brachte neue Erkenntnisse: Ein Feldtyp, der in Azure drei Zustände hatte, aber in Jira nur zwei. Ein Ticket-Link, der in Azure logisch war, aber bei Jira zu einem Zirkelschluss führte. Und natürlich kleine Fallstricke wie falsch interpretierte TimeStamps oder Unicode-Zeichen, die ihre ganz eigene Agenda hatten.
All das wurde schrittweise gelöst – mit Mapping-Tabellen, Transformationsregeln und einer Menge Logging, falls doch mal ein Ticket „durchrutschte“.
Phase 4: Finaler Export – ohne Stillstand
Nach rund drei Monaten stand das Setup: Das Tool war stabil, das Mapping sauber dokumentiert, die Daten vollständig. Der finale Export wurde an einem Wochenende durchgeführt – parallel zum Import in den Atlassian Stack. Durch ein hohes Maß an Automatisierung und vorbereiteter Migrationsscripte war der Wechsel bis Montagmorgen abgeschlossen. Die Teams konnten direkt weiterarbeiten – als wäre nichts passiert.
Ergebnis
Der Wechsel von Azure DevOps zu Atlassian verlief nicht nur reibungslos, sondern auch nahezu verlustfrei. Die Ergebnisse im Überblick:
In nur drei Monaten wurde die gesamte Migration vorbereitet, getestet, dokumentiert und durchgeführt.
Hohe Kundenzufriedenheit, da alle Anforderungen erfüllt wurden: vollständiger Erhalt von Tickets, Beziehungen, Historien, Repos, Pipelines und Testplänen.
Datenverlust unter 1 %, hauptsächlich durch inkonsistente Sonderfälle, die nicht abbildbar waren – und bereits in der Vorbereitung identifiziert wurden.
Keine Downtimes, da Exporte und Importe automatisiert in einem engen Zeitfenster abgewickelt wurden.
Langfristige Lizenz- und Kostenvorteile durch die Konsolidierung auf Atlassian-Produkte.
Fazit
Große Migrationen brauchen keine Drama-Queen-Momente, sondern klare Ziele, gute Vorbereitung – und manchmal eben ein bisschen Eigenbau. Der Wechsel von Azure DevOps zu Atlassian ist kein Spaziergang, aber mit den richtigen Werkzeugen und der nötigen Sorgfalt machbar. Der Schlüssel liegt nicht in der Komplettlösung von der Stange, sondern in einem Prozess, der auf die Besonderheiten des Kunden eingeht.
Und das Beste: Die Entwicklerteams haben am Montag nicht einmal gemerkt, dass sie jetzt mit einem völlig neuen System arbeiten. Wenn das kein gutes Zeichen ist.
