StatusTranslationMigrator
Auch Status-Übersetzungen kennt die Cloud offiziell nicht. Der StatusTranslationMigrator schließt die Lücke — und geht dabei drei Wege, um möglichst jeden Status zu treffen.
- Status-Übersetzungen je Sprache in die Cloud
- Dreistufiger Abgleich, auch projektbezogen
- Herkunft je Treffer belegt, Lücken ausgewiesen
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Geschrieben wird erst nach Ihrer Freigabe
- Nachvollziehbarer Abschlussbericht zu jedem Lauf
Status-Übersetzungen sind heikel, weil derselbe Status in verschiedenen Workflows anders heißen kann. Der StatusTranslationMigrator liest die Übersetzungsmaske je Sprache aus, ergänzt die Status-Namen aus der API und ordnet dann in drei Durchläufen zu.
Zuerst der direkte Abgleich, dann der umgekehrte Weg über die bereits übersetzte Bezeichnung, zuletzt die projektbezogene Auflösung für Status, die global nicht auffindbar sind. Jeder Treffer wird mit seiner Herkunft festgehalten, Status ohne Entsprechung werden gesondert ausgewiesen.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Status-Übersetzungen fehlen in der Cloud
- Gleiche Namen, falsche Zuordnung
- Unklar, woher eine Übersetzung stammt
- Nicht auffindbare Status fallen weg
Mit diesem Werkzeug StatusTranslationMigrator
- Je Sprache korrekt übersetzt
- Dreistufiger Abgleich trifft den richtigen Status
- Herkunft je Treffer belegt
- Projektbezogen aufgelöst oder ausgewiesen
Vier Stufen
Export, Mapping, Zusammenführen, Import.
-
1
Export
Die Übersetzungsmaske des Data Center wird je Sprache vollständig ausgelesen und um die Status-Namen aus der API ergänzt.
Verifiziert: Vollständig je Sprache.
-
2
Status-Mapping in drei Durchläufen
Direkter Abgleich, umgekehrter Weg über die übersetzte Bezeichnung, projektbezogene Auflösung.
Verifiziert: Herkunft je Treffer festgehalten.
-
3
Zusammenführen
Je nach Treffer-Art wird die passende Sprachfassung gesetzt, auch rückwirkend die englische, wo das Data Center sie führt.
Verifiziert: Status ohne Entsprechung gesondert ausgewiesen.
-
4
Import
Vorschau, dann Schreiben — je Sprache ein Vorgang über alle Status.
Verifiziert: Erledigte Sprachen festgehalten.
Was es kann
Dreistufiger Abgleich
Direkter Abgleich, umgekehrter Weg über die übersetzte Bezeichnung und projektbezogene Auflösung — für Status, die global nicht auffindbar sind.
Herkunft je Treffer
Zu jeder Zuordnung wird festgehalten, aus welchem Durchlauf sie stammt. Das macht das Ergebnis überprüfbar.
Lücken ausgewiesen
Status ohne Entsprechung werden gesondert ausgewiesen, nicht stillschweigend verworfen.
Alle Sprachen, nicht nur eine
Der Migrator holt sämtliche gepflegten Sprachfassungen in die Cloud, je nach Treffer-Art die passende — und ergänzt dabei auch die englische Bezeichnung rückwirkend, wo das Data Center sie führt.
Vorschau vor dem Schreiben
Vor dem Import zeigt eine Vorschau vollständig, was gesetzt würde.
Ein Vorgang je Sprache
Die Cloud erwartet je Sprache einen einzigen Vorgang über alle Status — genau so wird geschrieben, erledigte Sprachen werden festgehalten.
Häufige Fragen vor der Migration
Wie findet der Migrator Status, die global nicht auffindbar sind?
Über einen dritten Durchlauf, der projektbezogen auflöst. Was der direkte und der umgekehrte Abgleich nicht treffen, wird so noch zugeordnet.
Kann ich nachvollziehen, woher eine Übersetzung kommt?
Ja. Jeder Treffer wird mit seiner Herkunft festgehalten — aus welchem der drei Durchläufe er stammt.
Was passiert mit Status ohne Entsprechung?
Sie werden gesondert ausgewiesen statt stillschweigend verworfen, damit Sie gezielt nacharbeiten können.
Warum je Sprache nur ein Vorgang?
Weil die Cloud es so erwartet: je Sprache ein einziger Vorgang über alle Status. Genau so wird geschrieben, und erledigte Sprachen werden festgehalten.
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.