Asset Relink
Beim Umzug in die Cloud reißen die Verbindungen zwischen Ihren Assets und den Vorgängen ab. Asset Relink stellt sie wieder her — vollständig, wiederholbar und nach jedem Schritt geprüft.
- Felder, Kontexte und Screens in der Cloud anlegen
- AQL-Filter von Data Center nach Cloud übersetzen
- Objektwerte an jedem Vorgang neu verknüpfen
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Ein isolierter Stack pro Kunde
- Abschlussbericht nennt auch Übersprungenes
Insight/Assets verbindet Server, Verträge oder Bauteile mit tausenden Vorgängen. Bei der Standard-Migration in die Cloud bleibt davon wenig heil: Die Objekt-IDs ändern sich, die Asset-Felder verlieren ihre Schema-Bindung und ihre Filter, und die Werte an den Vorgängen zeigen ins Leere. Felder sind plötzlich leer oder gar nicht mehr auswählbar, Automationen rund um Assets laufen nicht mehr.
Asset Relink baut diesen Zustand vollständig wieder auf — in drei Stufen. Zuerst die Felder und ihre Kontexte, dann die Screens und die AQL-Filter, zuletzt die Objektwerte an jedem einzelnen Vorgang. Nach jeder Stufe gleicht das Tool das Ergebnis gegen die Data-Center-Daten ab. Ein Testlauf zeigt vorab genau, was passieren würde; geschrieben wird erst auf Ihre Freigabe.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Asset-Felder sind leer oder nicht mehr auswählbar
- Gespeicherte AQL-Filter laufen ins Leere
- Werte an den Vorgängen zeigen auf falsche oder fehlende Objekte
- Automationen rund um Assets feuern nicht mehr
Mit diesem Werkzeug Asset Relink
- Jedes Feld ist an sein Objekt-Schema gebunden und befüllbar
- Filter sind nach Cloud übersetzt, Ungültiges erkannt und ausgelassen
- Jeder Wert ist über eine stabile Objekt-Kennung neu verknüpft
- Felder und Werte stehen wieder bereit, die Logik greift
In drei geprüften Stufen
Asset Relink schreibt nichts blind. Jede Stufe lässt sich beliebig oft wiederholen, ohne Schaden anzurichten, und wird nach Abschluss gegen die Data-Center-Daten abgeglichen. Ein Testlauf zeigt vorab genau, was passieren würde — geschrieben wird erst auf Ihre Freigabe.
-
1
Felder & Kontexte
Asset Relink legt die Asset-Felder in der Cloud an und bindet jedes an das richtige Objekt-Schema. Erst diese Bindung macht aus einem vorhandenen Feld ein befüll- und auswählbares Feld.
Verifiziert: Feld existiert und ist korrekt ans Schema gebunden
-
2
Screens & AQL-Filter
Jedes Feld wird an die richtigen Screens gehängt — je Projekt und Vorgangstyp, auch dort, wo es in Data Center nur im Hintergrund per Automation gefüllt wurde. Parallel werden die Objekt-Filter von Data Center nach Cloud übersetzt; ungültige Filter werden erkannt und ausgelassen.
Verifiziert: Felder auf den richtigen Screens, gültige Filter übersetzt
-
3
Objektwerte neu verknüpfen
Asset Relink verbindet jeden Asset-Wert an jedem Vorgang wieder mit dem richtigen Cloud-Objekt. Die Auflösung läuft über eine stabile Objekt-Kennung und in Stapeln, sodass aus Stunden Minuten werden.
Verifiziert: jeder Wert gegen die Data-Center-Quelle abgeglichen
Was es kann
Felder und Kontexte
Legt die Asset-Felder in der Cloud an und bindet jedes an das richtige Objekt-Schema. Erst damit ist ein Feld nicht nur vorhanden, sondern auch befüll- und auswählbar.
Screens und Eingabemasken
Hängt jedes Asset-Feld an die richtigen Screens — je Projekt und Vorgangstyp. Auch Felder, die in Data Center nur im Hintergrund per Automation gefüllt wurden.
AQL-Filter übersetzen
Überträgt die Objekt-Filter von Data Center nach Cloud (IQL zu AQL). Filter, die in der Cloud ungültig wären, erkennt das Tool und lässt sie aus — statt später das Schreiben an Vorgängen zu blockieren.
Objektwerte neu verknüpfen
Verbindet jeden Asset-Wert wieder mit dem richtigen Cloud-Objekt. Die Auflösung läuft über eine stabile Objekt-Kennung und in Stapeln — aus Stunden Handarbeit werden Minuten.
Schreibt auch im Sperrfall
Verweigert die Cloud-API den Schreibzugriff, setzt Asset Relink die Werte über einen sicheren Forge-Sonderweg. So bekommt auch ein Feld seinen Wert, das gar nicht auf der Eingabemaske liegt.
Prüfung nach jeder Stufe
Nach Feldern, Screens und Werten gleicht Asset Relink das Ergebnis gegen die Data-Center-Daten ab. Mehrdeutige Treffer, übersprungene Projekte und Fehlschläge stehen benannt im Abschlussbericht — nichts wird im Stillen falsch verknüpft.
Häufige Fragen vor der Migration
Bleiben meine Asset-Felder am Ende leer?
Bei der Standard-Migration verlieren Felder ihre Schema-Bindung und sind nicht mehr auswählbar. Asset Relink legt jedes Feld neu an, bindet es ans richtige Objekt-Schema und prüft danach, dass es befüllbar ist.
Funktionieren meine gespeicherten Filter noch?
Asset-Filter sind in der Cloud zunächst ungültig. Asset Relink übersetzt sie von IQL nach AQL und meldet die, die sich nicht sauber übertragen lassen — statt sie still scheitern zu lassen.
Was passiert mit meinen Automationen?
Automationen rund um Assets feuern nur, wenn Felder und Werte wieder stehen. Genau das stellt Asset Relink her: Sobald Felder gebunden und Werte verknüpft sind, greift Ihre bestehende Logik wieder.
Und wenn die Cloud-API das Schreiben blockiert?
Für genau diesen Fall gibt es einen sicheren Forge-Sonderweg. Asset Relink setzt die Werte auch dort, wo die normale API verweigert — und selbst dann, wenn das Feld gar nicht auf der Eingabemaske liegt.
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
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
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.