JSM-Queue-Repair
Nach der Migration zeigen die Abfragen hinter den JSM-Warteschlangen oft auf alte, DC-interne IDs und laufen leer. JSM-Queue-Repair setzt genau diese Abfragen wieder instand.
- Leerlaufende Agenten-Warteschlangen wieder befüllt
- Nur die Abfrage ersetzt, alles andere bleibt
- Erst nach Bestätigung, Endzustand gegengelesen
- Dry-Run vor jedem Schreiben
- Nach jeder Stufe gegen Data Center geprüft
- Geschrieben wird erst nach Ihrer Freigabe
- Nachvollziehbarer Abschlussbericht zu jedem Lauf
Agenten-Warteschlangen sind das tägliche Arbeitswerkzeug im Service Management. Zeigen ihre Abfragen nach dem Umzug auf Data-Center-interne IDs, läuft die Warteschlange leer und die Arbeit stockt. JSM-Queue-Repair ersetzt gezielt die Abfrage und lässt alle übrigen Einstellungen unangetastet.
Weil Atlassian diesen Bereich häufig umbaut, bestätigt das Werkzeug seinen Schreibweg an der echten Bearbeitungsmaske, bevor es schreibt. Vor jedem Schreiben steht ein Trockenlauf, geschrieben wird erst nach ausdrücklicher Bestätigung, und danach wird der Endzustand gegengelesen.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Warteschlangen laufen nach dem Umzug leer
- Abfragen zeigen auf tote DC-IDs
- Reparatur riskiert andere Einstellungen
- Änderung ungeprüft geschrieben
Mit diesem Werkzeug JSM-Queue-Repair
- Abfragen wieder instand, Warteschlangen gefüllt
- Auf gültige Cloud-Referenzen umgestellt
- Nur die Abfrage ersetzt, Rest bleibt
- Trockenlauf, Bestätigung, Endzustand gegengelesen
Vier Stufen
Einrichten, Schreibweg bestätigen, Trockenlauf, Schreiben.
-
1
Einrichten
Die Sitzung wird einmal im Browser angelegt und bleibt über Neustarts erhalten.
Verifiziert: Einmalige Einrichtung, danach reproduzierbar.
-
2
Schreibweg bestätigen
Die Bearbeitungsmaske einer Warteschlange wird einmal benutzt; das Werkzeug gleicht den Speichervorgang mit dem hinterlegten Weg ab.
Verifiziert: Absicherung für einen von Atlassian oft umgebauten Bereich.
-
3
Trockenlauf
Der bestehende Zustand wird gelesen, ausschließlich die Abfrage ersetzt und der geplante Schreibvorgang angezeigt.
Verifiziert: Alle übrigen Einstellungen bleiben unangetastet.
-
4
Schreiben und Prüfen
Erst nach ausdrücklicher Bestätigung wird geschrieben, anschließend der Endzustand gegengelesen.
Verifiziert: Ergebnis gegen die Cloud gegengeprüft.
Was es kann
Nur die Abfrage ersetzt
Repariert wird ausschließlich die Abfrage hinter der Warteschlange. Alle übrigen Einstellungen bleiben unangetastet.
Schreibweg vorher bestätigt
Das Werkzeug gleicht seinen Speichervorgang einmal an der echten Bearbeitungsmaske ab — die Absicherung für einen Bereich, den Atlassian häufig umbaut.
Trockenlauf vor dem Schreiben
Der bestehende Zustand wird gelesen und der geplante Schreibvorgang vollständig angezeigt, bevor etwas passiert.
Erst nach Bestätigung
Geschrieben wird erst nach ausdrücklicher Bestätigung. Danach wird der Endzustand gegengelesen.
Einmal einrichten
Die Sitzung wird einmal eingerichtet und bleibt über Neustarts erhalten. Danach läuft die Reparatur reproduzierbar.
Projektbezogen einsetzbar
Die Reparatur lässt sich gezielt für einzelne Projekte fahren, statt flächendeckend aktiv sein zu müssen.
Häufige Fragen vor der Migration
Warum laufen die Warteschlangen nach der Migration leer?
Weil ihre Abfragen auf Data-Center-interne IDs zeigen, die es in der Cloud nicht mehr gibt. JSM-Queue-Repair stellt die Abfragen auf gültige Cloud-Referenzen um.
Werden andere Einstellungen der Warteschlange verändert?
Nein. Ersetzt wird ausschließlich die Abfrage. Alle übrigen Einstellungen bleiben unangetastet.
Warum wird der Schreibweg vorher bestätigt?
Weil Atlassian diesen Bereich häufig umbaut. Das Werkzeug gleicht seinen Speichervorgang einmal an der echten Maske ab, damit die Reparatur verlässlich schreibt.
Muss das auf allen Stacks dauerhaft laufen?
Nein. Die Reparatur wird projektbezogen eingesetzt und ist bewusst nicht auf allen Stacks dauerhaft aktiv.
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.