Für Teams, die Opsgenie für On-Call-Pläne, Alerts, Eskalationen und Incidents einsetzen, ist die Frist eindeutig: Atlassian wird Opsgenie am 5. April 2027 abschalten. Danach ist das Produkt nicht mehr zugänglich und alle noch nicht migrierten Daten werden gelöscht.
Atlassian stellt einen Migrationspfad zu Jira Service Management bereit, und ein großer Teil der technischen Umstellung ist automatisiert. Bestehende Owner können in den Opsgenie-Einstellungen einen empfohlenen Migrationspfad einsehen, ein Migrationsdatum auswählen und den Großteil der Daten und Konfigurationen mit der Zielinstanz von Jira Service Management synchronisieren. Das Wort „automatisiert“ sollte jedoch nicht mit „vollständig erledigt“ verwechselt werden.
Die Datenmigration kann unkompliziert sein. Die operative Migration ist die eigentliche Arbeit. Eine gute Umstellung stellt eine wichtigere Frage als: „Haben wir unsere Schedules migriert?“ Sie fragt: Werden unsere Teams nach der Umstellung auf Incidents wirksamer reagieren als zuvor?
Die zentralen Funktionen von Opsgenie werden in Jira Service Management eingebettet. Alerting, On-Call-Operations, Incident-Workflows, Service Management, Assets und Wissensmanagement werden damit in einer stärker vereinheitlichten Plattform zusammengeführt. Das Ziel besteht darin, die Trennung zwischen Development und IT Operations zu reduzieren. Personen, die auf einen Incident reagieren, sollen mit demselben verbundenen Kontext arbeiten wie Teams, die Services verantworten und Ursachen beheben.
Für die meisten Kunden kann Atlassians Migrationswerkzeug On-Call-Schedules, Eskalationsrichtlinien und Incident-Workflows ohne Downtime übertragen, sobald die Migration gestartet wurde. Nicht jede Konfiguration erfordert jedoch denselben manuellen Nachgang. Integrationen, Regeln für das Alert-Routing, individuelle Workflows, Nutzer und Teampraktiken sollten überprüft werden, bevor ein Migrationsdatum festgelegt wird.
Die Chance besteht nicht darin, das alte Opsgenie-Setup nur an einem neuen Ort nachzubauen. Sie liegt darin, zu entscheiden, welche Bestandteile des bisherigen Setups Teams weiterhin bei einer guten Reaktion helfen — und welche zu operativer Altlast geworden sind.
Die häufigste Schwäche im Incident Management ist nicht eine fehlende Alert-Regel. Es ist unklare Verantwortung. Wenn um 02:00 Uhr ein Alert ausgelöst wird, sollte jeder wissen, welcher Service betroffen ist, wer ihn verantwortet, wer On-Call ist, wer Entscheidungen treffen darf und wie das richtige Fachwissen eingebunden wird.
Vor dem Wechsel zu Jira Service Management sollten Organisationen ein einfaches Service-Ownership-Modell erstellen oder validieren. Jeder kritische Service benötigt einen benannten fachlichen oder technischen Owner, ein verantwortliches Team, eine On-Call-Rotation, definierte Supportzeiten und einen Eskalationspfad. Diese Informationen müssen gepflegt werden, wenn sich Teams, Systeme und Verantwortlichkeiten verändern.
Eine Konfiguration, die Alerts an eine allgemeine Gruppe weiterleitet, kann akzeptabel aussehen, bis ein Incident mehrere Teams, Regionen oder Lieferanten betrifft. Klare Ownership verwandelt einen Alert in Handlung. Sie verringert zudem die operative Last der wenigen Personen, die nur deshalb zu Standardansprechpartnern werden, weil sie die Legacy-Umgebung am besten kennen.
Alert Fatigue ist eine der schnellsten Ursachen für schlechtere Incident Response. Wenn Engineers zu viele Alerts mit geringem Wert erhalten, lernen sie, Benachrichtigungen zu ignorieren, die Bestätigung zu verzögern oder Alerts in eine gemeinsame Queue zu leiten, die niemand aktiv verantwortet. Die Übertragung derselben Regeln in Jira Service Management löst dieses Problem nicht.
Nutzen Sie das Migrationsfenster, um zu bewerten, welche Alerts tatsächlich handlungsfähig sind. Ein nützlicher Alert sollte dem Responder sagen, was passiert ist, welcher Service betroffen ist, wie dringend das Problem ist und wo die Informationen für die erste Diagnose liegen. Idealerweise verlinkt er auf ein Runbook, ein Dashboard, ein aktuelles Deployment oder eine bekannte Änderung.
Teams sollten Alerts identifizieren, die wiederholt ohne Handlung geschlossen werden, solche ohne klaren Service Owner und solche, die nicht zu einer definierten Reaktion führen. Wenn diese Alerts vor der Migration entfernt oder neu gestaltet werden, entsteht eine ruhigere und zuverlässigere Betriebsumgebung. Zudem werden die Vorteile einer einheitlichen Plattform nach der Umstellung sichtbarer.
Eine Eskalationsrichtlinie ist nicht nur ein technischer Routing-Mechanismus. Sie ist eine Geschäftsentscheidung über Risiko, Verfügbarkeit und Kundenauswirkung. Wer wird zuerst alarmiert? Wie viel Zeit ist angemessen, bevor ein Incident eskaliert wird? Wann sollten Management oder Geschäftsführung informiert werden? Welche Fälle erfordern die Beteiligung externer Lieferanten?
Diese Fragen wurden möglicherweise vor Jahren beantwortet, oft als Reaktion auf einen konkreten Incident, und danach nicht mehr überprüft. Die Opsgenie-Migration ist ein sinnvoller Anlass, dies nachzuholen. Eine reife Richtlinie unterscheidet zwischen Incident-Schwere, Kundenauswirkung, Service-Kritikalität und Geschäftszeiten. Sie alarmiert nicht bei jedem Ausfall dieselben Personen.
Jira Service Management kann den gemeinsamen Workflow und die Transparenz bereitstellen, die für diese Entscheidungen nötig sind. Teams sollten die Richtlinie jedoch definieren, bevor sie das Tool konfigurieren. Andernfalls übernimmt die neue Plattform lediglich die Unklarheiten der alten.
Runbooks sind nur dann wertvoll, wenn Responder sie während eines Incidents finden und befolgen können. Ein langes Dokument in einem schwer auffindbaren Confluence-Bereich ist kein operatives Werkzeug. Gute Runbooks sind knapp, aktuell, klar verantwortet und direkt mit den Services und Alerts verknüpft, die sie unterstützen.
Für jeden kritischen Service sollte ein First Responder innerhalb weniger Minuten mehrere Fragen beantworten können: Was leistet der Service? Wie sind Kunden betroffen? Wo befinden sich die wichtigsten Monitoring-Daten? Welche Sofortmaßnahmen sind sicher? Wen muss man kontaktieren und wann muss eskaliert werden? Die Reaktion muss nicht jede Root Cause lösen. Sie muss dem Team helfen, die Situation schnell und konsistent zu stabilisieren.
Der Wechsel zu Jira Service Management ist ein guter Moment, Alerting, Incidents, Service Records und Wissensmanagement zu verbinden. Je mehr Kontext einem Responder im Moment des Alerts zur Verfügung steht, desto weniger Zeit geht für die Suche über getrennte Tools und für grundlegende Rückfragen in einem Incident-Channel verloren.
Atlassians empfohlener Pfad umfasst Lernen, Planung, Testen und Migrieren. Die Testphase sollte mehr sein als eine technische Validierung. Nutzen Sie sie als operative Generalprobe.
Testen Sie einen Alert über seinen gesamten Lebenszyklus. Prüfen Sie, ob er die richtigen Personen erreicht, Ruhezeiten und Eskalationszeitpunkte berücksichtigt, den passenden Jira-Service-Management-Vorgang öffnet oder verknüpft und hilfreichen Kontext liefert. Führen Sie eine Tabletop-Übung mit einem realistischen Szenario durch, etwa einem nicht verfügbaren kundenorientierten Service oder einer fehlerhaften Integration. Binden Sie technische Responder, Service Owner, Support-Verantwortliche und Kommunikations-Stakeholder ein.
Das Ziel ist nicht nur festzustellen, ob die Plattform einen Alert erzeugen kann. Es geht darum herauszufinden, ob die Organisation unter Druck eine kohärente Entscheidung treffen kann.
Atlassian hat den Verkauf neuer Opsgenie-Lizenzen am 4. Juni 2025 eingestellt. Bestehende Kunden können das Produkt bis zum Ende des Supports weiter nutzen. Nach dem 5. April 2027 endet jedoch der Zugriff und verbliebene Daten werden gelöscht. Wer bis in die letzten Monate wartet, konzentriert das Risiko genau in der Phase, in der Teams Ruhe, Kapazität und sorgfältige Tests benötigen.
Ein sinnvoller Zeitplan beginnt mit einer Discovery-Phase: Dokumentieren Sie das bestehende Setup, erfassen Sie Integrationen, identifizieren Sie Ownership-Lücken und prüfen Sie die Alert-Qualität. Danach folgen ein Testumzug und operative Tests. Erst dann sollte die produktive Umstellung terminiert und allen beteiligten Personen in der Incident Response eine fokussierte Einführung gegeben werden.
Dieser Ansatz gibt Organisationen Zeit, Verbesserungen bewusst vorzunehmen, statt vermeidbare Probleme in eine hastige Migration mitzunehmen.
Die Abschaltung von Opsgenie ist eine Frist, aber auch eine Chance. Organisationen, die sie als reine Checklistenaufgabe behandeln, werden ihre Daten erfolgreich migrieren, aber möglicherweise dasselbe Alert-Rauschen, dieselbe unklare Ownership und dieselbe fragmentierte Incident Response behalten.
Organisationen, die den Übergang nutzen, um Service Ownership zu klären, die Alert-Qualität zu verbessern, Eskalationsrichtlinien zu aktualisieren und Runbooks mit der tatsächlichen Response-Arbeit zu verbinden, können mit einem widerstandsfähigeren Betriebsmodell aus der Migration hervorgehen. Das beste Migrationsresultat lautet nicht nur „Opsgenie-Daten übertragen“. Es lautet: schnellere, ruhigere und besser informierte Reaktionen beim nächsten kritischen Incident.
Die meisten Probleme im Revenue Operations beginnen nicht beim Anlegen einer Opportunit
Von Basis-Setup bis zu fortgeschrittenen Automatisierungen. Schritt-für-Schritt-Anleitu
Viele Unternehmen investieren massiv in Atlassian-Lizenzen und Implementierungen, nur u
