Jira Migration Helper
JCMA bringt Ihre Daten in die Cloud, lässt aber die Konfiguration unvollständig oder beschädigt zurück. Der Jira Migration Helper repariert diese Lücken Modul für Modul und automatisiert die Nacharbeit mit der Managed Migration — jeder Schritt 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
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Ein isolierter Stack pro Kunde
- Abschlussbericht nennt auch Übersprungenes
JCMA migriert die Masse Ihrer Daten zuverlässig, doch ein erheblicher Teil der Konfiguration bleibt liegen oder kommt beschädigt in der Cloud an: gespeicherte Filter mit toten Feldreferenzen, leere Dashboards, übersprungene Custom Fields und unvollständige Berechtigungsschemata. Genau hier setzt der Jira Migration Helper an und arbeitet diese Nacharbeit Modul für Modul ab. Jedes Modul läuft standardmäßig im Dry-Run und mit vollständigem Änderungsprotokoll, schreibende Zugriffe gehen über ein ratenlimitiertes, idempotentes Write-Gateway — so verändern Sie Ihre Cloud-Instanz kontrolliert und nie doppelt.
Neu ist die Managed Migration: die Automatisierungs-Schicht über den Reparatur-Modulen. Sie dockt an eine laufende JCMA-Migration an und fährt für jedes fertig gemeldete Projekt automatisch die passenden Fixes. So entfällt die manuelle Nacharbeit Projekt für Projekt, und Ihre Cloud-Konfiguration ist fertig, sobald JCMA durch ist.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Gespeicherte Filter laufen in der Cloud ins Leere
- Dashboards sind leer, Felder und Rollen fehlen
- Die Nacharbeit läuft Projekt für Projekt von Hand
- JCMA-Fehler-Logs muss man von Hand durchsuchen und deuten
Mit diesem Werkzeug Jira Migration Helper
- Filter sind auf Feld-IDs und Cloud-IDs übersetzt und laden wieder
- Gadgets, übersprungene Felder und Berechtigungen sind nachgezogen
- Die Managed Migration fährt die Fixes pro fertigem Projekt automatisch
- Der Log-Analyzer klassifiziert und behebt automatisch, wo es sicher ist
In vier geprüften Schritten
Der Jira Migration Helper schreibt nichts blind. Jedes Modul läuft standardmäßig zuerst im Dry-Run und zeigt vorab genau, was passieren würde — geschrieben wird erst auf Ihre Freigabe. Die Managed Migration fährt diese Schritte für jedes fertige Projekt automatisch, jeder schreibende Zugriff über das ratenlimitierte, idempotente Write-Gateway.
-
1
Bestandsaufnahme nach JCMA
Der Jira Migration Helper liest den Zustand nach der JCMA-Migration aus und erfasst, was liegengeblieben oder beschädigt ist: tote Feldreferenzen in Filtern, leere Dashboards, übersprungene Felder und unvollständige Schemata. Sie sehen den Umfang der Nacharbeit, bevor irgendetwas verändert wird.
Verifiziert: Umfang der offenen Nacharbeit benannt und sichtbar
-
2
Reparatur Modul für Modul
Jedes Reparatur-Modul läuft zuerst im Dry-Run und zeigt genau, was es ändern würde. Sie geben gezielt frei, was geschrieben werden soll; geschrieben wird über das idempotente Write-Gateway, sodass auch ein wiederholter Lauf nichts doppelt verändert.
Verifiziert: jede Änderung vorab im Dry-Run gezeigt und freigegeben
-
3
Managed Migration
Der Migration Orchestrator dockt an die laufende JCMA-Migration an und fährt für jedes fertig gemeldete Projekt automatisch die passenden Fixes. Eine Queue mit Dependency-Gate hält die Reihenfolge ein, und nach einer Unterbrechung setzt der Lauf sauber an der letzten Stelle wieder auf.
Verifiziert: jedes fertige Projekt automatisch und in der richtigen Reihenfolge bearbeitet
-
4
Verifikation & Bericht
Nach jedem Modul gleicht der Jira Migration Helper das Ergebnis gegen die echte Cloud-API ab. Übersprungene Fälle, mehrdeutige Treffer und Fehlschläge stehen benannt im Abschlussbericht, den Sie als ZIP herunterladen — nichts wird im Stillen falsch repariert.
Verifiziert: Ergebnis gegen die Cloud-API geprüft, alles im Bericht dokumentiert
Was es kann
Filter- & JQL-Reparatur
Macht gespeicherte Filter wieder cloud-tauglich: übersetzt Feldnamen auf Feld-IDs und cf-Referenzen, korrigiert „Customer Request Type“ zu „Request Type“ und hängt Verweise auf andere Filter auf die neuen Cloud-IDs um. Operatoren werden angepasst (etwa = zu ~ bei Textfeldern), und unsortierbare ORDER-BY-Klauseln werden bereinigt, damit der Filter überhaupt lädt. Ein System-Clause-Guard schützt valide project=-Klauseln, und auch fremd-besessene Filter werden per sicherem Owner-Swap repariert.
Dashboards reparieren
Bringt Dashboards zurück zum Leben: Gadget-Verknüpfungen auf Filter und Felder werden von DC auf die Cloud-IDs übersetzt und native Gadgets neu aufgebaut. Tote Projekt-Berechtigungen werden bereinigt, ohne dass ein Dashboard dabei versehentlich zu weit freigegeben wird.
Übersprungene Custom Fields
Legt die Felder an, die JCMA überspringt — etwa Felder ohne Screen, die nur per Automation oder ScriptRunner gesetzt werden. Inklusive Kontext und Optionen, auch bei kaskadierenden Auswahlfeldern, damit nachgelagerte Automatisierungen und Skripte weiterlaufen.
Rollen & Berechtigungsschemata
Gleicht Berechtigungsschemata zwischen DC und Cloud ab und ergänzt fehlende Grants mit sicherem Holder-Mapping für Benutzer, Gruppen und Rollen. So hat nach der Migration niemand zu viel und niemand zu wenig Zugriff.
Managed Migration
Der Migration Orchestrator dockt an eine laufende JCMA-Migration an und fährt für jedes fertig gemeldete Projekt automatisch die passenden Reparatur-Module. Eine Queue mit Dependency-Gate arbeitet die Projekte in der richtigen Reihenfolge ab, ein Doppel-Gate verhindert versehentliche Mehrfach-Läufe. Wird der Lauf unterbrochen, setzt er sauber an der letzten Stelle wieder auf, statt von vorn zu beginnen.
Logs & Jobs automatisch
Der Migration Log Analyzer liest die JCMA-Fehler-Logs, klassifiziert die Meldungen und behebt sie automatisch, wo es sicher ist — den Rest legt er benannt zur Entscheidung vor. Der Migration Job Manager legt JCMA-Jobs an, startet Pre-Checks und Migration und überwacht laufend den Status. So steuern Sie die gesamte Migration aus einer Hand, statt zwischen Tools und Log-Dateien zu springen.
Häufige Fragen vor der Migration
Warum reicht JCMA allein nicht?
JCMA migriert die Masse Ihrer Daten zuverlässig, lässt aber viel Konfiguration kaputt oder unmigriert zurück — etwa Filter mit toten Feldreferenzen, leere Dashboards und übersprungene Felder. Der Jira Migration Helper schließt genau diese Lücken Modul für Modul. So ist nicht nur die Datenmenge übertragen, sondern Ihre Cloud-Instanz auch wieder benutzbar.
Was macht die Managed Migration konkret?
Die Managed Migration ist die Automatisierungs-Schicht über den Reparatur-Modulen. Sie dockt an eine laufende JCMA-Migration an und fährt für jedes fertig gemeldete Projekt automatisch die passenden Fixes, in der richtigen Reihenfolge und mit Resume nach Unterbrechung. So müssen Sie die Nacharbeit nicht von Hand und nicht erst am Ende erledigen.
Kann ich beim automatischen Lauf versehentlich etwas kaputt machen?
Jedes Modul läuft standardmäßig im Dry-Run und zeigt vorab, was es ändern würde. Schreibende Zugriffe gehen über ein idempotentes Write-Gateway, sodass ein wiederholter oder fortgesetzter Lauf nichts doppelt verändert. Ein Doppel-Gate verhindert versehentliche Mehrfach-Läufe, und alles steht im vollständigen Änderungsprotokoll.
Wie bediene ich den Jira Migration Helper?
Sie arbeiten wahlweise über ein token-gesichertes Web-UI mit Live-Konsole und ZIP-Download des Berichts oder über die CLI. In beiden Fällen ist jedes Modul Dry-Run-Standard und führt ein vollständiges Änderungsprotokoll. So wählen Sie zwischen geführter Oberfläche und Automatisierung in der Pipeline, ohne an Kontrolle zu verlieren.
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
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
- Token-gesicherte Außenkante, 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
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.