WorkflowMigrator
Workflows sind der Bereich, in dem der native Pfad die meisten Nacharbeiten hinterlässt. Der WorkflowMigrator überträgt sie und arbeitet die typischen Bruchstellen gleich mit ab.
- Feld-, Status- und Projektbezüge sauber umgeschlüsselt
- Was keine Cloud-Entsprechung hat, kommt in den Abweichungsbericht
- Fehlerbilder vorab beheben, als Runbook-Schritt festgehalten
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Geschrieben wird erst nach Ihrer Freigabe
- Nachvollziehbarer Abschlussbericht zu jedem Lauf
Übersetzte Feld-, Status- und Projektbezüge, Regeln, die es in der Cloud so nicht gibt, Validatoren aus Zusatz-Apps, die den Migrationsassistenten stolpern lassen: Der WorkflowMigrator schlüsselt diese Bezüge um, bildet DC-Regeln auf Cloud-Entsprechungen ab und schreibt alles, was keine Entsprechung hat, in einen Abweichungsbericht — statt es stillschweigend wegzulassen.
Der eigentliche Hebel liegt aber woanders: Typische Fehlerbilder, die eine Migration abbrechen lassen, behebt er schon in der Vorbereitung und hält das Vorgehen als Runbook-Eintrag für den Produktivlauf fest. So wird aus dem Testlauf der Lauf, in dem der Produktivlauf entsteht.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Workflows brechen an übersetzten Bezügen
- App-Validatoren lassen den Assistenten abbrechen
- Fehlendes verschwindet stillschweigend
- Der Produktivtag ist eine Premiere
Mit diesem Werkzeug WorkflowMigrator
- Feld-, Status- und Projektbezüge sauber umgeschlüsselt
- Fehlerbilder vorab behoben
- Ohne Cloud-Entsprechung: im Abweichungsbericht
- Der Produktivtag ist eine Wiederholung
Vom Testlauf zum Produktivlauf
Jede Erkenntnis wird zum festen Schritt.
-
1
Testmigration
Die Workflows werden übertragen; dabei zeigen sich die typischen Fehlerbilder und Bruchstellen.
Verifiziert: Jede Bruchstelle benannt, nichts stillschweigend weggelassen.
-
2
Behebung
Die Fehlerbilder werden schon in der Vorbereitung behoben, Bezüge umgeschlüsselt, Regeln abgebildet.
Verifiziert: Ergebnis gegen das DC-Original geprüft.
-
3
Runbook-Eintrag
Das Vorgehen wird als fester Schritt im Runbook für den Produktivlauf festgeschrieben.
Verifiziert: Nachvollziehbar, wiederholbar, nicht aus dem Gedächtnis.
-
4
Produktivlauf
Am Stichtag wird das Runbook Zug um Zug abgefahren — in einem Zug, ohne manuelle Zwischenschritte.
Verifiziert: Der Produktivlauf ist eine Wiederholung, keine Premiere.
Was es kann
Bezüge umgeschlüsselt
Feld-, Status- und Projektbezüge werden von Data-Center- auf Cloud-Werte umgesetzt, damit die Workflows in der Cloud dasselbe tun wie vorher.
Regeln abgebildet
DC-Regeln werden auf ihre Cloud-Entsprechungen abgebildet. Was sich nicht abbilden lässt, verschwindet nicht, sondern wird benannt.
Abweichungsbericht
Alles ohne Cloud-Entsprechung landet in einem Abweichungsbericht — mit Fundort, damit die Nacharbeit gezielt möglich ist.
Fehlerbilder vorab beheben
Typische Fehler, die eine Migration abbrechen lassen, werden schon in der Vorbereitung behoben, nicht erst am Stichtag.
Runbook statt Gedächtnis
Jede Behebung wird als Runbook-Eintrag festgeschrieben. Am Produktivtag wird das Runbook Zug um Zug abgefahren, ohne aus dem Gedächtnis rekonstruierte Handgriffe.
Dry-Run und Verifikation
Wie jedes schreibende Werkzeug läuft der WorkflowMigrator zuerst im Trockenlauf und prüft das Ergebnis gegen das Data-Center-Original.
Häufige Fragen vor der Migration
Was passiert mit Regeln, die es in der Cloud nicht gibt?
Sie werden nicht stillschweigend weggelassen. Was sich nicht auf eine Cloud-Entsprechung abbilden lässt, landet mit Fundort im Abweichungsbericht, sodass die Nacharbeit gezielt möglich ist.
Wie hilft das am Migrationstag?
Jede Behebung aus der Vorbereitung wird als Runbook-Schritt festgeschrieben. Am Produktivtag wird dieses Runbook Zug um Zug abgefahren — ohne Handgriffe, die jemand aus dem Gedächtnis rekonstruieren muss.
Werden Änderungen sofort scharf geschrieben?
Nein. Der WorkflowMigrator läuft zuerst im Trockenlauf und prüft gegen das Data-Center-Original. Geschrieben wird erst nach Freigabe.
Deckt er auch Validatoren und Post-Functions ab?
Er bildet ab, was eine Cloud-Entsprechung hat, und weist den Rest aus. Kundenspezifische Groovy-Logik und app-spezifische Post-Functions gehören zur Restarbeitsliste, die das Runbook und der Abschlussbericht sauber ausweisen.
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.
Läuft auf dem Jira Migration Manager
Dieses Werkzeug steht nicht allein. Es läuft auf der Plattform, die alle Werkzeuge vereint: Eine read-only Lese-Schicht zieht Data Center und Cloud in eine versionierte Momentaufnahme, und jede Änderung geht durch ein einziges, kontrolliertes Schreib-Gateway.
Mehr zum Jira Migration ManagerWeitere Werkzeuge
Migrations-Plattform
Jira Migration Manager
Die Plattform, die alle Migrationswerkzeuge unter einem Dach vereint und eine Jira-DC-zu-Cloud-Migration sicher und wiederholbar macht: getrennte Lese- und Schreibwege, ratenlimitiert in die Cloud, Zugangsdaten verschlüsselt, ein isolierter Stack je Kunde.
- Read-only-Lese-Schicht und ratenlimitierter Schreibkanal strikt getrennt
- Alle Werkzeuge auf einer Datenbasis, verkettbar zu Pipelines
- Ein kontrollierter Zugangspunkt, verschlüsselter Keystore, ein Stack je Kunde
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
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.