Opsgenie is being sunset: the calm migration guide for on-call teams

If you run on-call on Opsgenie, you already know the news: Atlassian is winding the product down. The date to circle is April 5, 2027 — full end of support, product shutdown, and data deletion. That turns a tool you never had to think about into a project with a deadline, with a hard requirement to get your schedules, policies and history out before they're gone. The good news — a migration done right is a non-event for your responders. Nobody should get paged at 3 a.m. because you switched tools.

This is the playbook we walk teams through. It works for any destination, not just ours.

First, don't rush the cutover

The single biggest mistake teams make is a hard switch on a Friday. On-call migrations fail in the routing, not the export. So the rule is: run the new tool in parallel with Opsgenie for a week or two before you flip production alerts. It costs you almost nothing and removes all the risk.

What you actually need to migrate

Opsgenie is more than schedules. Inventory these before you start — this is your migration checklist:

• On-call schedules & rotations — daily/weekly rotations, overrides, and who's on now.
• Escalation policies — the rung-by-rung "if not acked in N minutes, page the next person/team."
• Teams & routing rules — which alerts go to which team.
• Integrations (inbound) — every monitoring tool that fires into Opsgenie (Datadog, Prometheus/Alertmanager, New Relic, Grafana, CloudWatch, etc.).
• Notification channels — SMS, voice, email, mobile push, Slack.
• Alert de-duplication / grouping rules — so you don't recreate alert-storm noise.

The step-by-step

1. Export everything from Opsgenie

Pull your schedules, escalation policies, teams and integration list via the Opsgenie API (or the admin export). Keep a copy — this is also your rollback insurance.

2. Recreate rotations & escalation paths in the new tool

A good replacement will import these directly so you're not hand-rebuilding rotations. Map each Opsgenie team to a service + escalation policy in the new system. Re-point notification preferences (who wants SMS vs. push vs. voice).

3. Verify in parallel — test-page every rung

This is the part teams skip and regret. For each escalation policy, fire a test incident and confirm:

• the on-call person is paged on their preferred channel,
• the escalation actually climbs to the next rung if unacked,
• alert grouping/de-dup behaves like it did in Opsgenie.

4. Cut over — then decommission

Once parallel-running looks clean, flip your monitoring webhooks from the Opsgenie endpoint to the new one, one integration at a time (start with the least critical). Watch a full on-call rotation. Then, and only then, disable Opsgenie.

What to look for in a replacement

Since you're switching anyway, don't just replace like-for-like — this is a rare chance to fix what annoyed you about Opsgenie. Weigh candidates on:

How PagerCo fits

We built PagerCo as a modern home for exactly this migration. It imports your Opsgenie schedules, escalation policies and services directly, so on-call never goes dark — and it adds the things Opsgenie didn't: AI investigation that surfaces a likely root cause in the first minutes of an incident, Autopilot that can auto-resolve well-understood recurring incidents, and paging over WhatsApp, SMS, voice, Slack and push — at a fraction of the enterprise price.

If Opsgenie's sunset put "choose a new on-call tool" on your plate, we're happy to help you scope the migration — even if you don't pick us. See how the Opsgenie migration works → or start it free →.

Written by the team building PagerCo, an AI-native incident-management and on-call platform.