AssetMigrator
Insight bzw. Assets ist der anspruchsvollste Teil einer Jira-Migration. Der AssetMigrator baut Ihre komplette Objektwelt in einem leeren Cloud-Tenant neu auf — Struktur, Werte und Verknüpfungen — und weist am Ende nach, dass alles angekommen ist.
- Schemas, Objekttypen und Objekte vollständig neu aufgebaut
- Objekt-zu-Objekt-Verknüpfungen inklusive
- Am Ende gegen das DC-Original abgeglichen
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Geschrieben wird erst nach Ihrer Freigabe
- Nachvollziehbarer Abschlussbericht zu jedem Lauf
Objektschemata, Referenzen und die Asset-Werte auf den Vorgängen müssen vollständig in die Cloud kommen — sonst laufen später Abfragen und Automationen ins Leere. Der AssetMigrator übernimmt das in einer vierstufigen Pipeline: erst den Data-Center-Stand lesen, dann offline in eine saubere Anlege-Reihenfolge bringen, dann in der Cloud anlegen und zuletzt gegen das Original prüfen.
Die Reihenfolge ist der Knackpunkt: Objekttypen entstehen eltern-zuerst, Skalar-, Status- und Benutzerwerte zuerst, danach die Referenzen samt schemaübergreifender Auflösung. So greifen am Ende alle Verknüpfungen und nicht nur die Hälfte.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Assets von Hand nachgebaut, Objekt für Objekt
- Verknüpfungen brechen oder fehlen
- Unklar, ob wirklich alles angekommen ist
- Falsche Reihenfolge, halbe Ergebnisse
Mit diesem Werkzeug AssetMigrator
- Komplette Struktur automatisch aufgebaut
- Objekt-zu-Objekt-Referenzen bleiben erhalten
- Abgleich gegen das Original mit vollständigem Mapping
- Eltern-zuerst, deterministisch aufbereitet
Die vier Stufen
Von der Erfassung bis zum Nachweis.
-
1
Erfassen
Ein Snapshot der Objektstrukturen wird aus dem Data Center gelesen.
Verifiziert: Rein lesend, vollständiger Stand.
-
2
Aufbereiten
Alle Objekte werden offline in eine saubere Anlege-Reihenfolge gebracht.
Verifiziert: Abhängigkeiten aufgelöst, bevor geschrieben wird.
-
3
Anlegen
Schemas, Objekttypen (eltern-zuerst, mit Attributen) und Objekte werden angelegt, danach die Referenzen samt schemaübergreifender Auflösung gesetzt.
Verifiziert: Pflichtfeld- und Eindeutigkeits-Regeln nachgezogen.
-
4
Verifizieren
Die Cloud wird gegen das Data-Center-Original abgeglichen und ein vollständiges Mapping geschrieben.
Verifiziert: Nachweis: Die Cloud entspricht dem Original.
Was es kann
Komplette Struktur neu aufgebaut
Schemas, Objekttypen und Objekte entstehen vollständig im Cloud-Ziel — nicht nur die Hülle, sondern mit Skalar-, Status- und Benutzerwerten.
Eltern-zuerst-Reihenfolge
Objekttypen werden in der richtigen Abhängigkeitsreihenfolge angelegt. Was aufeinander aufbaut, entsteht auch in dieser Reihenfolge.
Referenzen inklusive
Referenz-Attribute und Referenzwerte werden samt schemaübergreifender Auflösung gesetzt — die Objekt-zu-Objekt-Verknüpfungen bleiben erhalten.
Pflichtfelder und Eindeutigkeit
Pflichtfeld- und Eindeutigkeits-Regeln werden nachgezogen, statt sie stillschweigend zu übergehen.
Gegen das Original geprüft
Zum Abschluss wird die Cloud gegen das Data-Center-Original abgeglichen und ein vollständiges Mapping geschrieben.
Offline aufbereitet, deterministisch
Die Anlege-Reihenfolge wird offline aus dem Snapshot berechnet — reproduzierbar und unabhängig von der Reihenfolge der Eingaben.
Häufige Fragen vor der Migration
Läuft der AssetMigrator auch bei sehr großen Objektwelten?
Ja. Die Anlege-Reihenfolge wird offline aus dem Snapshot berechnet, bevor überhaupt geschrieben wird. Gerade bei großen, verflochtenen Strukturen ist das der entscheidende Unterschied zur Handarbeit.
Bleiben die Verknüpfungen zwischen Objekten erhalten?
Ja. Nach den Objekten werden die Referenz-Attribute und Referenzwerte gesetzt, inklusive schemaübergreifender Auflösung. Die Objekt-zu-Objekt-Beziehungen kommen vollständig mit.
Wie wird sichergestellt, dass nichts fehlt?
Die letzte Stufe gleicht die Cloud gegen das Data-Center-Original ab und schreibt ein vollständiges Mapping. Was nicht übereinstimmt, wird ausgewiesen, nicht übergangen.
Was, wenn im Ziel schon Assets vorhanden sind?
Der AssetMigrator ist auf den Aufbau in einem leeren Cloud-Tenant ausgelegt. Für die Reparatur und Anbindung in einem bereits migrierten Ziel ist Asset Relink das passende Werkzeug.
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.