Jira Migration Manager
Der Jira Migration Manager ist das Fundament, das alle Migrationswerkzeuge unter einem Dach vereint und eine Jira-DC-zu-Cloud-Migration über Wochen sicher und wiederholbar macht — mit getrennten Lese- und Schreibwegen als Sicherheitsprinzip.
- Read-only-Lese-Schicht und ratenlimitierter Schreibkanal strikt getrennt
- Alle Werkzeuge auf einer Datenbasis, verkettbar zu Pipelines
- Token-gesicherte Außenkante, verschlüsselter Keystore, ein Stack je Kunde
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Ein isolierter Stack pro Kunde
- Abschlussbericht nennt auch Übersprungenes
Ein Stack für die gesamte Migration: der Jira Migration Manager
Alle Werkzeuge laufen im selben Stack — dem Jira Migration Manager (JMM). Eine read-only-Lese-Schicht zieht Data Center und Cloud in eine versionierte Momentaufnahme, die spezialisierten Werkzeuge arbeiten darauf, und jede Änderung geht durch ein einziges, kontrolliertes Schreib-Gateway. Pro Kunde ein eigener, isolierter Stack.
Quelle
Jira Data Center
- Insight / Assets
- Automationen
- Structure
- Filter, Dashboards, Felder
Jira Migration Manager
Ein isolierter Stack pro KundeProxy & Portal
Token-gesicherte Außenkante, ein Reiter je Werkzeug
Extractor — Lese-Schicht
Vollständige, versionierte Momentaufnahme von DC und Cloud (read-only), inklusive fertiger DC→Cloud-Zuordnungen
Werkzeug-Familie
Alle Migrationswerkzeuge im selben Stack — einzeln nutzbar, im Verbund stark
DataManager & Keystore
Versionierte Zwischenergebnisse, verschlüsselte Zugangsdaten je Kunde
Write-Gateway — Schreib-Schicht
Ein einziger Schreibkanal: ratenlimitiert, idempotent, lückenlos auditiert
Ziel
Jira Cloud
- Assets for JSM
- Automationen (repariert)
- Structure (migriert)
- Filter & Dashboards
Lesen und Schreiben sind getrennt: Lesezugriffe belasten das Cloud-Budget nie, jede Änderung läuft kontrolliert und protokolliert durch das Gateway — und wird gegen die Data-Center-Quelle geprüft.
Eine Migration von Jira Data Center in die Cloud ist kein Knopfdruck, sondern eine Kette vieler Schritte über Wochen — gegen eine Cloud mit harten API-Ratenlimits und mit Daten, die Sie nicht verlieren dürfen. Einzelne Skripte gehen für jede Frage live gegen Jira, verbrauchen knappes API-Budget und hinterlassen keine nachvollziehbare Spur. Genau da fehlt das Fundament, das die ganze Kette zusammenhält.
Der Jira Migration Manager liefert dieses Fundament und vereint alle Werkzeuge unter einem Dach. Das Prinzip ist durchgängig: eine read-only Lese-Schicht zieht Ihre Daten einmal vollständig ein, ein versionierter Datenmanager hält die Zwischenstände, und ein ratenlimitiertes Write-Gateway ist der einzige Weg zurück in die Cloud — alles hinter einer token-gesicherten Außenkante, Zugangsdaten im verschlüsselten Keystore, ein isolierter Stack je Kunde.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Lose Skripte gehen für jede Frage live gegen Jira
- Schreibvorgänge laufen ungebremst in die Ratenlimits der Cloud
- Zugangsdaten liegen verstreut in Skripten und Logs
- Jeder Schritt einzeln, ohne Spur und kaum wiederholbar
Mit diesem Werkzeug Jira Migration Manager
- Eine read-only Momentaufnahme versorgt alle Werkzeuge
- Ein Write-Gateway hält die Limits ein und wiederholt sicher
- Alle Zugänge verschlüsselt im Keystore, getrennt je Kunde
- Verkettete Pipelines, jede Änderung simulierbar und protokolliert
Ein roter Faden in vier Stufen
Der Jira Migration Manager führt jede Migration über denselben kontrollierten Pfad: erst lesen, dann abgleichen, dann verarbeiten, zuletzt kontrolliert schreiben. Lesen und Schreiben sind dabei strikt getrennt. Jede schreibende Änderung läuft durch das Write-Gateway — ratenlimitiert, idempotent, simulierbar und protokolliert.
-
1
Lesen ohne Risiko
Der Extractor zieht Data Center und Cloud einmal vollständig in eine versionierte Momentaufnahme. Ab da arbeiten alle Werkzeuge auf dieser eingefrorenen Datenbasis, sodass die Reads die Cloud kein zweites Mal belasten. Das Lesen ist vom Schreiben getrennt und kann nichts verändern.
Verifiziert: vollständige, versionierte Momentaufnahme liegt vor
-
2
Abgleichen
Aus der Momentaufnahme bildet die Plattform belastbare DC-zu-Cloud-Mappings, die Typ und Sprache berücksichtigen. Gleichnamige Felder unterschiedlichen Typs werden nicht verwechselt, Prioritäten sprachbewusst zugeordnet. So steht für den späteren Schreibvorgang fest, was wohin gehört.
Verifiziert: typ- und sprachbewusste Zuordnungen stehen fest
-
3
Verarbeiten
Die Werkzeuge der Plattform bauen aufeinander auf und legen ihre Zwischenstände im DataManager ab. Ein Werkzeug nutzt das Ergebnis des vorigen, statt einen Schritt erneut zu berechnen. Dadurch entstehen wiederholbare Pipelines mit nachvollziehbaren Zwischenständen.
Verifiziert: Zwischenstände versioniert im DataManager
-
4
Kontrolliert schreiben
Jede Änderung geht durch das Write-Gateway, das die Atlassian-Ratenlimits einhält und 429-Antworten samt Wiederholung selbst behandelt. Aufrufe sind idempotent, lassen sich vorab als Dry-Run simulieren und stehen anschließend lückenlos im Audit. Die Freigabe für den echten Lauf behalten Sie.
Verifiziert: jede Änderung ratenlimitiert, idempotent und protokolliert
Was es kann
Extractor: read-only Lese-Schicht
Der Extractor zieht Data Center und Cloud genau einmal vollständig in eine versionierte Momentaufnahme. Aus dieser eingefrorenen Datenbasis arbeiten alle Werkzeuge, ohne die Cloud bei jeder Frage erneut zu belasten. Er liefert dabei fertige DC-zu-Cloud-Zuordnungen statt bloßer Rohdaten. Lesen ist damit risikofrei vom Schreiben getrennt.
Write-Gateway: kontrolliert schreiben
Das Write-Gateway ist der einzige Schreibkanal in die Cloud und hält über einen globalen Token-Bucket die Atlassian-Ratenlimits ein. Es behandelt 429-Antworten und Wiederholungen automatisch, sodass kein Lauf an einem überschrittenen Limit scheitert. Jeder Aufruf ist idempotent — eine Wiederholung ändert nichts ein zweites Mal. Ein Dry-Run zeigt jede geplante Änderung vorab, und jede ausgeführte Änderung steht lückenlos im Audit.
DataManager: Arbeitsspeicher der Pipeline
Der DataManager ist der benannte, versionierte Arbeitsspeicher der Migration und hält die Zwischenergebnisse der einzelnen Werkzeuge fest. So baut ein Werkzeug auf dem Ergebnis des vorigen auf, statt jeden Schritt neu zu berechnen. Werkzeuge lassen sich dadurch zu wiederholbaren Pipelines verketten. Jeder Stand bleibt versioniert nachvollziehbar.
Keystore: verschlüsselte Zugangsdaten
Der Keystore hält alle Zugangsdaten verschlüsselt (Fernet) und getrennt nach Kunde vor. Kein Token steht je im Code oder in Logs, wo es versehentlich entweichen könnte. Die Trennung je Kunde verhindert, dass Daten oder Zugänge über Mandanten hinweg vermischt werden. Damit bleibt jeder Zugang dort, wo er hingehört.
Proxy & Portal: eine Außenkante
Proxy und Portal bilden eine einzige, token-gesicherte Außenkante vor allen Werkzeugen. Die Weboberfläche führt jedes Werkzeug in einem eigenen Reiter, sodass Sie ohne Terminal-Zugang konfigurieren und Jobs verfolgen. Die Plattform läuft intern und ist nicht offen im Netz erreichbar. So gibt es genau einen kontrollierten Zugangspunkt statt vieler offener Endpunkte.
Werkzeug-Familie auf der Plattform
Auf der Plattform laufen die spezialisierten Werkzeuge zusammen: Asset Relink, Jira Migration Helper, AutomationMigrator, StructureMigrator und weitere. Alle nutzen die Daten des Extractors als Eingang und das Write-Gateway als Ausgang, statt jeweils eigene Wege in die Cloud zu öffnen. So teilen sie eine Datenbasis und ein einziges Sicherheitsmodell. Jedes Werkzeug bleibt einzeln nutzbar und ist im Verbund stark.
Häufige Fragen vor der Migration
Überlastet die Migration unsere Cloud-Instanz?
Nein. Gelesen wird nur einmal in eine Momentaufnahme, danach belasten Abfragen die Cloud nicht erneut. Geschrieben wird ausschließlich über das Write-Gateway, das einen globalen Token-Bucket nach den Atlassian-Ratenlimits führt und 429-Antworten samt Wiederholung selbst behandelt.
Was passiert, wenn ein Lauf abbricht oder wiederholt wird?
Die Aufrufe des Write-Gateways sind idempotent — eine Wiederholung ändert nichts ein zweites Mal und erzeugt keine Dubletten. Sie können einen Lauf gefahrlos erneut starten. Die Zwischenstände im DataManager bleiben versioniert erhalten, sodass die Verarbeitung dort weiterläuft, wo sie stand.
Können wir vor dem echten Schreiben sehen, was passiert?
Ja. Jeder schreibende Schritt lässt sich als Dry-Run simulieren und zeigt jede geplante Änderung vorab, ohne etwas zu verändern. Die Freigabe für den echten Lauf behalten Sie. Nach der Ausführung steht jede Änderung lückenlos im Audit.
Wie werden mehrere Kundenmigrationen voneinander getrennt?
Jeder Kunde erhält einen eigenen, isolierten Stack mit eigenem Keystore. Daten und Zugänge werden so nicht über Mandanten hinweg vermischt. Die Zugangsdaten liegen verschlüsselt im Keystore und stehen nie im Code oder in Logs.
Kontrolliert — von Anfang bis Abschlussbericht
Lesen vom Schreiben getrennt
Gelesen wird aus einer read-only Datenschicht, geschrieben nur über einen einzigen kontrollierten Kanal. Lesezugriffe belasten Ihre Cloud nie.
Testlauf vor jedem Schreiben
Der Dry-Run zeigt vollständig, was passieren würde. Geschrieben wird erst auf Ihre ausdrückliche Freigabe.
Wiederholbar ohne Risiko
Jeder Schritt lässt sich erneut ausführen, ohne Schaden anzurichten. Eine Unterbrechung ist kein Problem, ein zweiter Lauf erzeugt keine Dubletten.
Ein isolierter Stack pro Kunde
Alle Werkzeuge laufen auf der Jira-Migration-Manager-Plattform, pro Mandat vollständig getrennt. Keine Vermischung von Daten.
Der Abschlussbericht benennt jeden Vorgang einzeln: repariert, zu prüfen, übersprungen oder fehlgeschlagen. Nichts wird im Stillen falsch verarbeitet.
Weitere Werkzeuge
Assets-Migration
Asset Relink
Migriert Insight/Assets vollständig in die Cloud: Felder und Kontexte, AQL-Filter, Screens und die Objektwerte an jedem Vorgang. Genau dort, wo Standard-Tools die Verknüpfungen verlieren.
- Felder, Kontexte und Screens in der Cloud anlegen
- AQL-Filter von Data Center nach Cloud übersetzen
- Objektwerte an jedem Vorgang neu verknüpfen
Managed Migration
Jira Migration Helper
JCMA migriert die Masse Ihrer Daten, lässt aber Konfiguration kaputt oder unmigriert zurück. Der Jira Migration Helper schließt diese Lücken Modul für Modul und fährt mit der Managed Migration die passenden Fixes pro fertigem Projekt automatisch — jedes standardmäßig im Dry-Run und gegen die echte Cloud-API geprüft.
- Filter, Dashboards, Felder, Rollen und Berechtigungen reparieren, was JCMA offen lässt
- Managed Migration: pro fertig gemeldetem Projekt automatisch die passenden Fixes fahren
- Web-UI oder CLI, jedes Modul Dry-Run-Standard und über das idempotente Write-Gateway abgesichert
Automation-Migration
AutomationMigrator
Migrierte Jira-Automationsregeln laufen in der Cloud oft nur scheinbar: Scope, Feld-Verweise, Trigger und Owner brechen, und manche Regel feuert nie. AutomationMigrator gleicht jede Regel gegen ihr Data-Center-Original ab und repariert sie API-gestützt — genau dort, wo Standard-Tools eine kaputte Regel als migriert melden.
- Scope, Feld-Verweise, Trigger und Owner pro Regel reparieren
- Stille Regeln erkennen, die angelegt sind, aber nie feuern
- Jede Reparatur erst im Dry-Run zeigen, dann auf Freigabe schreiben
Passt das zu Ihrer Migration?
Schildern Sie kurz Ihren Fall — ich sage Ihnen ehrlich, ob und wie dieses Werkzeug hilft.
Gespräch vereinbarenAtlassian beendet den Support für Data Center am 28. März 2029. Wer eine große, komplex verknüpfte Umgebung umzieht, plant das besser früh als spät.