Runbook-Generator
Am Migrationstag entscheidet nicht die Datenmenge, sondern die Handgriffe, die niemand mehr erinnert. Der Runbook-Generator macht daraus eine konkrete Arbeitsvorlage — aus denselben Daten wie Gutachten und Angebot.
- Fertiges Runbook aus dem echten Inventar
- Restarbeitsliste in neun Kategorien
- Sichtbare Lücken statt geratener Zahlen
- Rein lesend, kein Schreibzugriff
- Ausgewertet gegen das Data-Center-Original
- Kein Eingriff in den laufenden Betrieb
- Ergebnisse nachvollziehbar dokumentiert
Der Runbook-Generator liest acht Endpunkte rein lesend aus, klassifiziert den Stand und rendert daraus ein fertiges Runbook für den Migrationstag — keine Schätzung, sondern die Arbeitsvorlage, die Zug um Zug abgefahren wird.
Der eigentliche Mehrwert steckt in der Restarbeitsliste: Alles, was sich weder nativ noch werkzeuggestützt migrieren lässt, wird in neun Kategorien ausgewiesen — von kundenspezifischem Groovy über Scripted Fields bis zu nicht-nativen Service-Management-Feldern. Wo die Datenlage keinen belastbaren Wert hergibt, steht ein sichtbarer Platzhalter statt einer geschätzten Zahl. Ein Runbook, das ehrlich lückenhaft ist, ist am Migrationstag mehr wert als eines, das vollständig aussieht.
Was eine Standard-Migration offen lässt
Nach der Standard-Migration
- Handgriffe aus dem Gedächtnis rekonstruiert
- Unklar, was von Hand bleibt
- Geschätzte Zahlen, die als Schätzung untergehen
- Runbook widerspricht Gutachten und Angebot
Mit diesem Werkzeug Runbook-Generator
- Eine konkrete Arbeitsvorlage, Zug um Zug
- Restarbeitsliste in neun Kategorien
- Sichtbare Platzhalter, wo Werte fehlen
- Alles aus einer Datenquelle
So entsteht Ihr Runbook
Rein lesend, aus dem echten Inventar.
-
1
Auslesen
Acht Endpunkte werden rein lesend erfasst.
Verifiziert: Kein Eingriff in den Betrieb.
-
2
Klassifizieren
Der Stand wird klassifiziert: was nativ läuft, was werkzeuggestützt geht und was manuell bleibt.
Verifiziert: Restarbeit in neun Kategorien eingeordnet.
-
3
Restarbeit ausweisen
Die manuelle Nacharbeit wird als eigene Runbook-Seite ausgewiesen, mit sichtbaren Platzhaltern, wo Werte fehlen.
Verifiziert: Keine geratenen Zahlen.
-
4
Runbook rendern
Aus dem klassifizierten Stand wird die fertige Ablaufanleitung für den Migrationstag gerendert.
Verifiziert: Zug um Zug abfahrbar.
Was es kann
Fertiges Runbook
Aus acht rein lesend erfassten Endpunkten wird eine konkrete Ablaufanleitung für den Migrationstag gerendert.
Restarbeitsliste in neun Kategorien
Alles, was weder nativ noch werkzeuggestützt migrierbar ist, wird klassifiziert: Groovy in Bedingungen, Validatoren und Post-Functions, ScriptRunner-Logik, app-spezifische Aktionen, Scripted Fields, Behaviours, freistehende Skripte, app-verwaltete Felder und nicht-native Service-Management-Felder.
Sichtbare Lücken
Wo die Datenlage keinen belastbaren Wert hergibt, steht ein sichtbarer Platzhalter — keine geschätzte Zahl, die später niemand mehr als Schätzung erkennt.
Eine Datenquelle für alles
Das Runbook entsteht aus denselben Rohdaten wie Gutachten und Angebot. Deshalb passt es zum Rest und widerspricht sich nicht.
Rein lesend
Der Generator erfasst read-only und verändert nichts. Er erstellt eine Arbeitsvorlage, keinen Eingriff in Ihre Systeme.
Ehrlich statt vollständig-aussehend
Ein Runbook, das seine Lücken zeigt, ist am Stichtag mehr wert als eines, das vollständig aussieht und es nicht ist.
Häufige Fragen vor der Migration
Woraus entsteht das Runbook?
Aus acht rein lesend erfassten Endpunkten Ihrer Instanz — denselben Rohdaten, aus denen auch Gutachten und Angebot entstehen. Deshalb passen die Dokumente zusammen.
Was ist die Restarbeitsliste?
Eine Aufstellung dessen, was sich weder nativ noch werkzeuggestützt migrieren lässt, klassifiziert in neun Kategorien — von kundenspezifischem Groovy bis zu nicht-nativen Service-Management-Feldern.
Warum sichtbare Platzhalter statt Zahlen?
Weil eine geschätzte Zahl später niemand mehr als Schätzung erkennt. Ein sichtbarer Platzhalter macht die Lücke ehrlich sichtbar — am Migrationstag ist das mehr wert.
Verändert der Generator etwas?
Nein. Er arbeitet rein lesend und erstellt eine Arbeitsvorlage. Geschrieben wird erst am Migrationstag über die eigentlichen Werkzeuge.
Sicher und nachvollziehbar
Lesen vom Schreiben getrennt
Gelesen wird aus einer read-only Datenschicht, geschrieben nur über einen einzigen kontrollierten Kanal. Lesezugriffe belasten Ihre Cloud nie.
Rein lesend ausgewertet
Ausgewertet wird ausschließlich lesend; es wird nichts in Ihre Systeme zurückgeschrieben. Betrieb und Cloud-Budget bleiben unberührt.
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.
Alle Ergebnisse sind nachvollziehbar dokumentiert und lassen sich gegen das Data-Center-Original prüfen. Nichts wird im Stillen verändert oder weggelassen.
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.