FieldTranslationMigrator
Für Feld-Übersetzungen bietet die Cloud keinen dokumentierten Standardweg. Der FieldTranslationMigrator schließt diese Lücke — und trifft dank echtem Mapping deutlich mehr Felder als ein Namensabgleich.
- Feld-Übersetzungen je Sprache in die Cloud
- Feld-Mapping aus der Extractor-API, kein Namensraten
- Nicht zuordenbare Felder in einer eigenen Klärliste
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Geschrieben wird erst nach Ihrer Freigabe
- Nachvollziehbarer Abschlussbericht zu jedem Lauf
Custom-Field-Übersetzungen gehen bei einer Migration leicht verloren, weil es in der Cloud keinen offiziellen Weg dafür gibt. Der FieldTranslationMigrator liest die Übersetzungen über einen dedizierten Data-Center-Endpunkt aus und legt sie auf die richtigen Cloud-Feld-IDs.
Der Unterschied steckt im Mapping: Es kommt direkt aus der Extractor-API, nicht aus dem Abgleich von Feldnamen. Die normalisierte Zuordnung findet rund doppelt so viele Treffer wie ein reiner Namensabgleich — und was sich trotzdem nicht zuordnen lässt, landet in einer eigenen Klärliste statt im Nichts.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Feld-Übersetzungen bleiben in der Cloud leer
- Namensabgleich trifft nur die Hälfte
- Unzuordenbare Felder verschwinden
- Ein Abbruch bedeutet von vorn
Mit diesem Werkzeug FieldTranslationMigrator
- Übersetzungen je Sprache übertragen
- Mapping aus der Extractor-API, doppelt so viele Treffer
- Klärliste macht sie sichtbar
- Wiederaufnahme an der Abbruchstelle
Fünf Stufen
Vom Export bis zu den Beschreibungen.
-
1
Export
Alle Feld-Übersetzungen werden über einen dedizierten Data-Center-Endpunkt ausgelesen.
Verifiziert: Rein lesend, vollständig je Sprache.
-
2
Feld-Mapping
DC-Feld auf Cloud-Feld direkt aus der Extractor-API, kein Namensraten.
Verifiziert: Rund doppelt so viele Treffer wie ein Namensabgleich.
-
3
Zusammenführen
Die Übersetzungen werden auf die Cloud-Feld-IDs gelegt; nicht zuordenbare Felder gehen in die Klärliste.
Verifiziert: Jede Zuordnung nachvollziehbar.
-
4
Import
Vorschau, dann Schreiben je Sprache, mit Wiederaufnahme nach Abbruch.
Verifiziert: Erst nach Freigabe, erledigte Sprachen festgehalten.
-
5
Beschreibungen
Optionaler Abgleich der Feld-Beschreibungen von Data Center in die Cloud, ebenfalls mit vorgeschalteter Vorschau.
Verifiziert: Nur nach ausdrücklicher Auswahl.
Was es kann
Mapping aus der Extractor-API
Das Feld-Mapping kommt direkt aus der Datenschicht, nicht aus dem Raten über Feldnamen. Die normalisierte Zuordnung findet rund doppelt so viele Treffer.
Je Sprache übertragen
Die Übersetzungen werden je Sprache auf die richtigen Cloud-Feld-IDs gelegt und geschrieben.
Klärliste statt Stillschweigen
Felder, die sich nicht zweifelsfrei zuordnen lassen, kommen in eine eigene Klärliste — sichtbar, nicht verloren.
Vorschau vor dem Schreiben
Vor dem Import zeigt eine Vorschau vollständig, was gesetzt würde. Geschrieben wird erst danach.
Wiederaufnahme nach Abbruch
Der Import läuft je Sprache und setzt nach einer Unterbrechung an der Abbruchstelle wieder auf, statt von vorn zu beginnen.
Beschreibungen optional mit
Auf Wunsch werden auch die Feld-Beschreibungen von Data Center in die Cloud abgeglichen, ebenfalls mit vorgeschalteter Vorschau.
Häufige Fragen vor der Migration
Warum trifft das Mapping mehr Felder als ein Namensabgleich?
Weil es aus der normalisierten Zuordnung der Extractor-API kommt, nicht aus dem Vergleich von Feldnamen. In der Praxis findet das rund doppelt so viele Treffer.
Was passiert mit Feldern, die sich nicht zuordnen lassen?
Sie werden nicht stillschweigend übergangen, sondern in einer eigenen Klärliste ausgewiesen, damit Sie gezielt entscheiden können.
Was, wenn der Import mittendrin abbricht?
Der Import läuft je Sprache und nimmt nach einem Abbruch an der Abbruchstelle wieder auf. Bereits erledigte Sprachen werden festgehalten.
Werden auch die Feld-Beschreibungen übertragen?
Auf Wunsch ja, als eigener, vorschaubarer Schritt. Ohne Auswahl bleibt es bei den Übersetzungen.
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.