AutomationMigrator
Ihre Automationsregeln überstehen den Cloud-Umzug nur teilweise — und manche feuern nie wieder, ohne dass es jemand merkt. AutomationMigrator gleicht jede Regel gegen ihr Data-Center-Original ab, repariert sie API-gestützt und verifiziert, dass sie wirklich läuft.
- 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
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Ein isolierter Stack pro Kunde
- Abschlussbericht nennt auch Übersprungenes
Jira-Automationsregeln überstehen den Umzug in die Cloud nur teilweise. Projekt-Scope-Verweise, Feld-IDs, Status-Werte, Trigger-Formate und der ausführende Owner brechen beim Übertragen — und eine Regel, die im Editor korrekt aussieht, tut deshalb noch lange nichts. Besonders tückisch ist der stille Laufzeit-No-op: Die Regel ist angelegt, sie wirkt vollständig, aber sie feuert nie. Der Defekt fällt erst Wochen später auf, wenn ein Vorgang nicht zugewiesen wird oder eine SLA nicht startet.
AutomationMigrator analysiert jede migrierte Cloud-Regel gegen ihr Data-Center-Original und repariert sie über die API — Scope, Feld-Referenzen, Trigger- und Action-Schemata, Owner und Actor. Dahinter steht ein erweiterbarer Katalog von Fehlerklassen. Der Kern arbeitet deterministisch, ohne KI und ohne API-Schlüssel; eine KI-gestützte Mehraugen-Verifikation läuft als separates Gate vor der Aktivierung. Jede Konversion ist ein auditierbares Artefakt, ein Dry-Run zeigt jede geplante Änderung vorab — und den Freigabe-Knopf drücken Sie.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Migrierte Regeln verweisen auf falschen Projekt-Scope oder tote Feld-IDs
- Eine Regel ist angelegt, sieht korrekt aus, feuert aber nie
- Defekte fallen erst Wochen später im Tagesgeschäft auf
- Niemand weiß, was ein Tool an den Regeln verändert hat
Mit diesem Werkzeug AutomationMigrator
- Scope und Feld-Verweise sind typ-bewusst auf die Cloud aufgelöst
- Die ausführende Komponenten-Version stimmt, die Regel läuft wirklich
- Jeder Bruch wird beim Scan benannt und vor der Aktivierung gefangen
- Jede Konversion ist ein auditierbares Artefakt mit Freigabe durch Sie
In drei geprüften Schritten
AutomationMigrator schreibt nichts blind. Erst wird gegen das Data-Center-Original gescannt, dann die Reparatur berechnet und im Dry-Run gezeigt — geschrieben wird erst auf Ihre Freigabe, und danach wird gegen tatsächlich ausführende Cloud-Regeln verifiziert.
-
1
Scan gegen das Original
AutomationMigrator stellt jede Cloud-Regel neben ihr Data-Center-Original und erkennt die Fehlerklassen, die beim Umzug entstanden sind. Auch Regeln, die gar nicht erst migriert wurden oder als JCMA-Teilkopie ankamen, werden dabei sichtbar.
Verifiziert: jede Abweichung benannt und einer Fehlerklasse zugeordnet
-
2
Reparatur im Dry-Run
Aus den erkannten Fehlerklassen berechnet das Tool die nötige Reparatur — Scope, Feld-Verweise, Trigger- und Action-Schemata, Owner und Actor. Der Dry-Run zeigt jede geplante Änderung im Detail, bevor irgendetwas in die Cloud geschrieben wird.
Verifiziert: jede geplante Änderung vorab sichtbar und freigebbar
-
3
Schreiben und verifizieren
Nach Ihrer Freigabe schreibt AutomationMigrator die Reparatur über das Write-Gateway und verifiziert das Ergebnis gegen tatsächlich ausführende Cloud-Regeln. Erst diese Prüfung zeigt, ob eine Regel nur angelegt ist oder wirklich feuert.
Verifiziert: jede Regel gegen eine wirklich ausführende Cloud-Regel abgeglichen
Was es kann
Abgleich gegen das Original
AutomationMigrator stellt jede Cloud-Regel neben ihr Data-Center-Original und findet, was beim Umzug gebrochen ist. Geprüft werden Scope, Feld-Verweise, Trigger- und Action-Schemata sowie der ausführende Owner. So sehen Sie nicht nur, dass eine Regel existiert, sondern ob sie dem entspricht, was sie früher tat.
Stille Regeln aufspüren
Manche Regel ist angelegt, sieht korrekt aus und feuert trotzdem nie — ein stiller Laufzeit-No-op, der erst Wochen später auffällt. AutomationMigrator erkennt diesen Zustand, bevor er Schaden anrichtet. Maßstab ist die korrekte Komponenten-Version pro Aktionstyp, abgeleitet aus echten, tatsächlich ausführenden Cloud-Regeln.
Katalog von Fehlerklassen
Jeder typische Bruch hat seine eigene Fehlerklasse — vom falschen Projekt-Scope über tote Feld-Verweise bis zum SLA- und Owner-Defekt. AutomationMigrator ordnet jeden Befund einer Klasse zu und kennt die passende Reparatur dazu. Der Katalog ist erweiterbar, sodass neu erkannte Muster aufgenommen werden, statt von Hand nachgearbeitet zu werden.
Typ-bewusste Feld-Auflösung
Zwei Felder mit derselben customfield-ID können in der Cloud völlig unterschiedliche Schemata haben. AutomationMigrator unterscheidet sie und löst jeden Verweis typ-bewusst auf, statt eine ID blind durch eine andere zu ersetzen. So landet eine Regel nicht auf dem falschen Feld, nur weil die Nummer zufällig passt.
Mehraugen-Verifikation
Der Reparatur-Kern arbeitet deterministisch, ohne KI und ohne API-Schlüssel. Eine KI-gestützte Mehraugen-Prüfung läuft danach als separates Gate vor der Aktivierung und sieht sich jede Konversion noch einmal an. Beide Pfade sind getrennt, sodass das Ergebnis nachvollziehbar bleibt und die KI nichts unbemerkt verändert.
Dry-Run und Audit-Spur
Vor jedem Schreibzugriff zeigt ein Dry-Run jede geplante Änderung im Detail. Jede Konversion wird als auditierbares Artefakt festgehalten, sodass nachvollziehbar bleibt, was warum geändert wurde. Bedienen können Sie das per Web-UI mit Live-Konsole und Token-Auth oder per CLI mit scan und fix.
Häufige Fragen vor der Migration
Woher weiß ich, ob eine Regel wirklich läuft oder nur angelegt ist?
Eine Regel kann vollständig aussehen und trotzdem nie feuern — ein stiller Laufzeit-No-op. AutomationMigrator prüft die ausführende Komponenten-Version je Aktionstyp und leitet den Maßstab aus echten, tatsächlich laufenden Cloud-Regeln ab. So unterscheidet das Tool „angelegt" von „läuft wirklich".
Verändert eine KI meine Regeln, ohne dass ich es kontrollieren kann?
Nein. Der Reparatur-Kern arbeitet deterministisch, ohne KI und ohne API-Schlüssel. Die KI läuft nur als separates Verifikations-Gate vor der Aktivierung und schreibt selbst nichts. Jede Änderung wird vorab im Dry-Run gezeigt und erst auf Ihre Freigabe geschrieben.
Was passiert mit Feldern, die dieselbe ID, aber ein anderes Schema haben?
Dieselbe customfield-ID kann in der Cloud auf ein völlig anderes Feld zeigen. AutomationMigrator löst Feld-Verweise typ-bewusst auf und unterscheidet diese Fälle, statt eine ID blind zu übersetzen. So landet keine Regel auf dem falschen Feld, nur weil die Nummer passt.
Kann ich auch ScriptRunner-Skripte und JCMA-Teilkopien mitnehmen?
Ja. Der Befehl scan-stubs erkennt JCMA-Teilkopien, die nur halb angekommen sind, und convert bereitet ScriptRunner-Skripte als Conversion-Tasks auf. Assets-bezogene Lookups werden an Asset Relink übergeben, sodass auch diese Verweise korrekt aufgelöst werden.
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
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.