Wer Opsgenie nur technisch umzieht, verlegt sein Alarmchaos nach Jira Service Management

Der gefährlichste Denkfehler bei der Opsgenie-Migration lautet: Die Daten werden schon rüberkopiert, also wird der Betrieb danach schon irgendwie weiterlaufen. Genau das reicht nicht. Atlassian baut die Alarmierungs- und On-Call-Funktionen sichtbar in Jira Service Management ein, aber der eigentliche Reibungspunkt liegt nicht im Export der Alerts. Er liegt in Rollen, manuellen Nacharbeiten, nicht mitgezogenen Regeln, umzustellenden APIs und der Frage, ob Teams den neuen Zielzustand vor dem Termin wirklich als Betriebsmodell durchdacht haben.

Die aktuellen Atlassian-Dokumente sind an diesem Punkt bemerkenswert offen. Ja, große Teile der Daten und Konfigurationen werden automatisch synchronisiert. Gleichzeitig benennt Atlassian sehr klar, welche Dinge eben nicht automatisch sauber landen: Chat-Integrationen, Actions, Incident Rules, einzelne Altfunktionen, veraltete Heartbeat-Varianten oder APIs, die nach dem Wechsel nicht auf dem alten Pfad bleiben sollten. Wer den Move nur als Produktwechsel plant, trägt sein Alarmchaos deshalb nicht ab, sondern nur in eine andere Oberfläche.

Atlassian migriert nicht einfach ein Produkt, sondern verschiebt die Betriebslogik

Atlassian begründet den Wechsel ausdrücklich mit einem operativen Problem: On-call-Responder sollen nicht dauerhaft zwischen Opsgenie und Jira Service Management springen müssen. Laut Atlassian sind die Kernfunktionen für Alerting, On-call und Incident Management inzwischen nativ in Jira Service Management verfügbar, damit Dev- und Ops-Arbeit stärker auf einer gemeinsamen Plattform läuft. Das ist fachlich nachvollziehbar. Für Teams bedeutet es aber auch, dass die Migration nicht nur technische Datenbewegung ist, sondern eine Verschiebung von Zuständigkeiten, Workflows und Sichtbarkeit.

Genau deshalb ist bereits der Startpunkt wichtiger als viele Migrationspläne zugeben. Atlassian schreibt, dass nur ein Opsgenie Owner mit zusätzlicher Site-Admin-Rolle die Migration terminieren kann. Außerdem muss bei neuen Zielsites der Billing Admin die Kostenfreigabe bestätigen. Schon daran sieht man: Der Umzug ist nicht bloß eine Admin-Aufgabe im Hintergrund. Wenn Rollen, Budgetzuständigkeit und Zielprodukt nicht vorab geklärt sind, hängt der Prozess schnell an einem organisatorischen Nadelöhr und nicht an der Technik.

Hinzu kommt der Zeitrahmen. Die Migration kann laut Atlassian nur bis zu eine Woche im Voraus terminiert werden. Das klingt komfortabel, ist aber in Wahrheit ein Signal an den Betrieb: Die eigentliche Vorbereitung darf nicht erst am Tag der Terminwahl beginnen. Wer erst dann über Lizenzen, Zielrolle, Nutzerabbildung oder Nacharbeiten nachdenkt, plant keinen kontrollierten Umzug, sondern einen Sprint unter Druck.

Die eigentlichen Risiken sitzen in den Teilen, die nicht automatisch mitkommen

Besonders wichtig ist Atlassians klare Trennung zwischen synchronisierten Daten und manuellen Restarbeiten. Die Dokumentation nennt mehrere Baustellen, die Teams aktiv nachziehen müssen. Chat-Integrationen wie Slack oder Microsoft Teams werden nicht einfach vollständig übernommen, weil sie erneute Authentifizierung und neue Anbindung brauchen. Actions und Incident Rules aus Opsgenie werden laut Atlassian ebenfalls nicht automatisch in Jira Service Management aufgebaut. Stattdessen sollen sie in Jira Automation neu modelliert werden. Das ist kein kleines Konfigurationsdetail, sondern berührt den Kern vieler Incident-Abläufe.

Praktisch heißt das: Wenn ein Team seine Reaktionsqualität auf automatisch ausgelöste Regeln, Incident-Kommunikation oder Chat-getriebene Zusammenarbeit stützt, dann ist die Migration ohne diese Nacharbeiten funktional unvollständig. Ein grüner Migrationsstatus reicht dann nicht. Entscheidend ist, ob die operativen Routinen im Zielsystem tatsächlich wieder funktionieren. Wer das nicht überprüft, riskiert genau die unangenehmen Lücken, die erst im nächsten Major Incident sichtbar werden.

Auch Heartbeats sind so ein unterschätzter Fall. Atlassian erklärt, dass Heartbeats grundsätzlich mit nach Jira Service Management wechseln können, ihre Serverpfade aber von opsgenie.net auf Atlassian-Server wechseln. Zusätzlich werden Heartbeats ohne zugewiesene Teams nicht mitgenommen, weil diese alte Variante im Zielsystem nicht mehr unterstützt wird. Das ist operativ heikel, wenn externe Scripts oder Monitoring-Checks noch fest auf den alten Hostnamen oder auf verwaiste Konfigurationen zeigen. Der Umzug ist also nur dann belastbar, wenn auch die Anschlussstellen außerhalb der Oberfläche geprüft werden.

Was nach der Migration verschwindet, sollte vor dem Termin schon bekannt sein

Die Support-Dokumentation zu Feature-Änderungen macht den nächsten Punkt deutlich: Nicht alles lebt im Zielsystem unverändert weiter. Atlassian nennt ausdrücklich deprecations und Ersatzpfade. Slack-Integrationen für Incidents aus Opsgenie werden nicht synchronisiert und sollen im Zielsystem über neue Integrationen und Automationsregeln ersetzt werden. Das frühere Incident Command Center wird nicht weitergeführt; einzelne Bausteine daraus gehen in Incident Configurations oder andere Jira-Service-Management-Funktionen auf. API Key Management wird durch Atlassian Authentication ersetzt, alte REST-Endpunkte sollen auf Jira Service Management umgestellt werden, und einzelne Team-Details oder Altfunktionen aus älteren Opsgenie-Versionen bleiben auf der Strecke.

Genau hier kippen viele Umzüge in ein trügerisches Sicherheitsgefühl. Die Daten sind vielleicht da, aber der gewohnte Betriebsweg ist es nicht mehr. Wenn etwa eine Integration zwar historisch noch sichtbar ist, aber künftig neu aufgebaut werden muss, dann reicht ein grober Smoke-Test auf „Alerts kommen an“ nicht aus. Man muss prüfen, welche Funktion vorher real genutzt wurde und welches neue Gegenstück sie in Jira Service Management bekommt. Sonst wird aus einer technischen Migration ein schleichender Funktionsverlust.

Atlassian weist außerdem darauf hin, dass bestimmte historische Berichte oder Altfunktionen gar nicht mehr im selben Sinn weitergeführt werden. Das ist für Governance relevant, weil Reporting, Auditierbarkeit und Eskalationsbelege oft nicht als erste Migrationsaufgabe sichtbar sind, im Streitfall aber plötzlich wichtig werden. Wer nur auf Alarmzustellung schaut, unterschätzt die Steuerungsseite des Tools.

Die Read-only-Phase ist kein Ruhemodus, sondern Ihr letztes Umbaufenster

Ein wichtiger Punkt aus der Jira-Service-Management-Dokumentation ist die Read-only-Phase. Sobald Opsgenie in diesen Zustand wechselt, können Alerts und On-call-Schedules dort nicht mehr konfiguriert werden. Die Daten bleiben sichtbar und werden weiter synchron gehalten, Änderungen müssen aber im neuen System erfolgen. Das ist keine Schonfrist zum Abwarten, sondern das letzte Fenster, in dem Teams offene Altpfade gezielt aufräumen sollten.

Atlassian nennt dafür konkrete Nacharbeiten: Chat-Tools verbinden, Alert Actions und Incident Rules neu aufbauen, mobile Nutzung auf Jira umstellen und REST-API-Endpunkte auf Jira Operations umziehen. Der Punkt ist strategisch wichtig: Wer diese Phase nur als technisches Nebeneinander interpretiert, lässt die Restarbeiten liegen, bis Opsgenie endgültig abgeschaltet wird. Wer sie als Übergabefenster behandelt, kann dagegen gezielt nachweisen, dass Bereitschaften, Integrationen, Kommunikationswege und Automationslogik im Zielsystem wirklich tragfähig sind.

Dazu passt auch der Migration Guide. Atlassian beschreibt ihn als personalisiertes Aufgabenboard, das nach der Migration 120 Tage verfügbar bleibt und je nach Rolle unterschiedliche To-dos zeigt. Das ist nützlich, darf aber nicht missverstanden werden. Der Guide ist eine Hilfe, kein Ersatz für Betriebsführung. Er zeigt Aufgaben an, doch die Verantwortung, sie fachlich richtig zu priorisieren und sauber abzunehmen, bleibt bei den Teams.

Was ein belastbarer Move-Plan jetzt enthalten sollte

Für ITSM-, Platform- und Operations-Verantwortliche lässt sich daraus ein nüchterner Dreischritt ableiten. Erstens: Vor dem Termin den realen Zielzustand festlegen, also Rollen, Billing-Freigabe, Nutzerabbildung, Integrationen, Automationsersatz und API-Pfad. Zweitens: Beim eigentlichen Move nicht nur auf den Kopierstatus schauen, sondern auf die Lückenliste, die Atlassian selbst benennt. Drittens: Die Read-only-Phase als verpflichtende Härtungsphase behandeln, in der kein alter Sonderweg ungetestet liegen bleiben darf.

Wer das beherzigt, bekommt aus dem Wechsel zu Jira Service Management mehr als nur ein konsolidiertes Toolset. Er gewinnt eine sauberere Incident- und On-call-Logik. Wer dagegen nur die Daten bewegt, wird zwar formal migriert sein, aber beim nächsten Störfall merken, dass Chat, Regeln, Rollen oder Schnittstellen nur halb angekommen sind. Genau deshalb ist der Satz für diesen Umzug so wichtig: Nicht der technische Transfer entscheidet über den Erfolg, sondern die Betriebsreife danach.

Quellen

• Atlassian: Migrate from Opsgenie
• Atlassian Support: Schedule an Opsgenie migration
• Atlassian Support: Start moving from Opsgenie to Jira Service Management
• Atlassian Support: What is the migration guide and how to use it
• Atlassian Support: Feature changes and deprecations in Jira Service Management
• Atlassian Support: Set up operations and complete your move to Jira Service Management