Weg von Opsgenie: was wann umziehen muss, vor dem 5. April 2027
Die Frist kommt von Atlassian, nicht von Ihnen. Der Verkauf von Opsgenie endete im Juni 2025, am 5. April 2027 wird der Dienst abgeschaltet und die Kundendaten werden gelöscht. Hier steht, was umziehen muss, in welcher Reihenfolge, und wie lange es wirklich dauert.
Wenn Sie Ihre Rufbereitschaft in Opsgenie organisieren, steht ein festes Datum im Kalender, und davor liegt genau eine Entscheidung. Dieser Leitfaden ist herstellerneutral: Er beschreibt, was mit dem Produkt verschwindet, was Sie inventarisieren sollten, in welcher Reihenfolge Sie umziehen, ohne eine Lücke zu reißen, und wie lange das realistisch dauert. Perstat kommt am Ende vor, unter der Frage nach der Konsolidierung, nicht als Voraussetzung.
Was die Abschaltung konkret bedeutet
Zwei Termine zählen. Der Verkauf endete im Juni 2025, neue Opsgenie-Lizenzen oder Erweiterungen gibt es seitdem nicht mehr. Abgeschaltet wird am 5. April 2027: Der Dienst geht offline, die Kundendaten werden gelöscht.
Das Wort, das Ihre Planung bestimmt, ist gelöscht. Bereitschaftspläne, Eskalationsregeln, die Konfiguration der Integrationen und die Alarmhistorie liegen danach nicht irgendwo, wo Sie sie später wieder abholen könnten. Was Sie behalten wollen, exportieren Sie vor diesem Datum.
Das ist eine Produktentscheidung von Atlassian, offen so benannt. Über die Werkzeuge daneben sagt sie nichts, sie setzt nur Ihren Zeitplan. Eine Folge ist für regulierte Teams erwähnenswert: Wenn Sie unter DORA fallen, anwendbar seit dem 17. Januar 2025, oder unter NIS2, dann ist Ihre Incident-Historie ein Nachweis. Exportieren Sie sie, solange es sie noch gibt.
Erst Inventur, dann Toolsuche
Nehmen Sie sich eine Stunde in der Opsgenie-Konsole und schreiben Sie auf, was Sie tatsächlich benutzen. Die meisten Teams finden weniger, als sie befürchtet hatten, und ein paar Dinge, die sie vergessen hatten. Fünf Kategorien decken das ab.
Bereitschaftspläne und Rotationen
Wer hat wann Rufbereitschaft, über welche Teams und Zeitzonen hinweg. Notieren Sie auch die Vertretungen und die Feiertagsmuster. Genau diese Details gehen nach einem Umzug still kaputt.
Eskalationsregeln
Die Ketten: Wer wird nach welcher Zeit alarmiert, und was passiert, wenn niemand quittiert. Halten Sie die Zeitabstände fest, nicht nur die Reihenfolge.
Integrationen und Alarmquellen
Jedes System, das einen Alarm auslöst: Monitoring-Werkzeuge, Alarme der Cloud-Anbieter, Error-Tracker, Webhooks, E-Mail-Strecken. Das ist meist die längste Liste und der Teil, der am meisten Kalenderzeit frisst, denn jede Quelle muss einzeln umgehängt und auf der neuen Seite getestet werden.
Routing und Teams
Wie Alarme auf Teams, Tags und Prioritäten verteilt werden. In Routing-Regeln steckt Erfahrungswissen, das bei einer hastigen Umstellung leicht verloren geht.
Historie und Reports
Vergangene Alarme, Incident-Verläufe, Reports zur Rufbereitschaft. Entscheiden Sie, was Sie behalten müssen, und exportieren Sie es früh, in dem Format, das Opsgenie hergibt. Fangen Sie hier an, denn das ist die einzige Kategorie mit einem harten Verfallsdatum.
Die Reihenfolge, die keine Lücke lässt
Legen Sie keinen Schalter um. Betreiben Sie beide Systeme parallel und ziehen Sie die Alarmquellen einzeln um.
- Exportieren Sie Historie und Reports jetzt, bevor sich sonst etwas ändert.
- Schließen Sie die Inventur oben ab.
- Entscheiden Sie: einzelner Ersatz oder Konsolidierung (nächster Abschnitt).
- Bauen Sie Bereitschaftspläne und Eskalationsregeln im neuen Werkzeug nach. Zunächst identisch, verbessern können Sie später.
- Hängen Sie die Integrationen einzeln um und prüfen Sie bei jeder, dass tatsächlich ein Mensch alarmiert wird, bevor Sie die nächste anfassen.
- Lassen Sie beide Systeme mindestens eine vollständige Rotation der Rufbereitschaft lang parallel laufen, damit eine echte Woche mit echten Alarmen den Aufbau belegt.
- Stellen Sie um und schalten Sie Opsgenie erst ab, wenn alles exportiert ist, was Sie brauchen.
Einzelner Ersatz oder ein Umzug für den ganzen Stack?
Das ist die eigentliche Entscheidung, und sie ist dreißig Minuten wert, bevor Sie irgendeine Auswahlliste anlegen.
Opsgenie macht Rufbereitschaft und Alarmrouting. Sie können es durch ein anderes spezialisiertes Werkzeug für Rufbereitschaft ersetzen und den Rest Ihres Stacks unangetastet lassen. Das ist der Weg mit den wenigsten Überraschungen, und für manche Teams ist er der richtige.
Die Alternative besteht darin, zu bemerken, dass die Haube ohnehin offen steht. Die meisten Teams betreiben ihre Rufbereitschaft neben einem separaten Uptime-Monitoring, einer Statusseite und einem Incident-Prozess, oft von drei oder vier Anbietern, die keine Daten miteinander teilen. Ein erzwungener Umzug ist eine seltene Gelegenheit, davon etwas an einer Stelle zusammenzuführen, ohne zusätzliche Störung, denn Sie bauen die Bereitschaftspläne ohnehin neu und hängen die Integrationen ohnehin um.
Keine der beiden Antworten ist automatisch richtig. Wenn Ihre Alarmquellen tief in einem Ökosystem stecken oder Sie auf die enge Anbindung an Jira Service Management und an Ticketing angewiesen sind, hält ein gleichartiges Werkzeug für Rufbereitschaft Ihren Arbeitsablauf intakt. Wenn Ihr Schmerz die Werkzeugvielfalt ist, vier Rechnungen und vier Konsolen für eine einzige Frage, dann steht Konsolidierung zum ersten Mal ohne zusätzlichen Aufruhr zur Debatte.
Eine ehrliche Aufwandsschätzung
Planen Sie zwei bis sechs Monate Vorlauf ein, und verwechseln Sie Vorlauf nicht mit Arbeit.
Der eigentliche Nachbau für ein kleines Team, ein paar Bereitschaftspläne und eine Handvoll Integrationen, kostet ein bis zwei Wochen echte Arbeit. Über Monate zieht sich alles, was um die Konfiguration herum liegt: sich auf den neuen Zuschnitt der Eskalation zu einigen, jede Alarmquelle umzuhängen und zu testen, ohne dafür um drei Uhr nachts einen schlafenden Kollegen zu alarmieren, lange genug parallel zu fahren, um dem Aufbau zu trauen, und der Gewohnheit Zeit zu geben, damit unter Druck alle zur richtigen App greifen. Größere Organisationen mit vielen Teams und Dutzenden Integrationen landen am oberen Ende.
Zeit kosten am Ende zwei Dinge: die Integrationen, jede einzeln umgehängt und überprüft, und der Parallelbetrieb, den Sie nicht überspringen können, ohne eine Lücke zu reißen. Planen Sie beides ein, dann ist die Frist bequem. Schieben Sie beides bis Q4 2026, dann ist sie es nicht.
Kurze Checkliste
- Zuerst Alarmhistorie, Incident-Aufzeichnungen und Reports zur Rufbereitschaft exportieren.
- Bereitschaftspläne, Eskalationsregeln, Integrationen, Routing und Reports inventarisieren.
- Entscheiden: einzelner Ersatz oder Konsolidierung.
- Bereitschaftspläne und Eskalationen identisch im neuen Werkzeug nachbauen.
- Integrationen einzeln umhängen und jede einzeln testen.
- Beide Systeme eine vollständige Rotation lang parallel betreiben.
- Umstellen, die Exporte prüfen, dann abschalten.
Wo Perstat hineinpasst
Wenn Konsolidierung auf Ihrer Liste steht, ist Perstat eine der Optionen, die Sie abwägen können. Es legt Uptime-Monitoring, Statusseiten, Incident-Bearbeitung und Rufbereitschaft in ein Produkt, in der EU gehostet von einem deutschen Unternehmen ohne US-Mutter. Die Opsgenie-Begriffe lassen sich direkt übertragen: Aus Bereitschaftsplänen werden Rotationen der Rufbereitschaft, aus Eskalationsregeln wird die Eskalationskette von Push über SMS bis zum Telefonanruf, und Quittieren bleibt Quittieren. Das Monitoring, das Sie alarmiert, steckt im selben Produkt: HTTP-, TCP- und DNS-Checks bis hinunter zu 10-Sekunden-Intervallen von sechs Kontinenten, vor dem Alarm über mehrere Regionen bestätigt, damit eine einzelne wacklige Route nicht das Team weckt. Derselbe Umzug bringt Ihnen Statusseiten auf Ihrer eigenen Domain und SLA-Reports mit kuratierten Ausschlussfenstern (Beispiel hier ).
Genauso klar sagen wir, was Perstat nicht ersetzt: Es gibt kein Jira Service Management, kein Ticketing, kein APM und kein Log-Management. Wenn das bei Ihnen tragend ist, passt ein spezialisiertes Werkzeug für Rufbereitschaft besser, und auch das ist ein gutes Ergebnis dieser Übung.
Die Vergleichsseite zu Opsgenie enthält die Zuordnung Begriff für Begriff, und die Preise stehen auf der Seite, netto zuzüglich Umsatzsteuer, und anfangen können Sie kostenlos.
Kostenlos mit dem Monitoring beginnen oder die Produkttour ansehen . Für die Tour kein Konto, für den Preis kein Vertriebsgespräch.