Migrating off Opsgenie: a checklist for your alert flow

Atlassian stopped selling Opsgenie in June 2025, and support ends on April 5, 2027 — after which the product shuts down and unmigrated data is deleted. If your team pages through Opsgenie today, you have a hard deadline and, more usefully, a rare license to rethink the alert flow you have been accreting since you first set it up.

Most teams will treat this as a like-for-like swap: pick a new pager, recreate the schedules, repoint the integrations, done. That works, but it wastes the moment. The migration window is the one time you will ever have organizational permission to ask what your alert pipeline should actually look like — because everything is already on the table.

First, separate the three jobs Opsgenie was doing

Opsgenie (like every tool in its class) bundles three distinct jobs:

1. On-call mechanics — schedules, rotations, escalation policies, the 3 a.m. phone call. This is the part you must replace, and Atlassian's own migration path (Jira Service Management) or any dedicated on-call product can do it. Whatever you pick, this layer's only requirement is that it is boring and reliable.
2. Alert routing and grouping — the rules and dedup logic that decide which alerts become pages. This is where most teams' Opsgenie configuration has quietly rotted: years of one-off routing rules, aliases, and suppression windows that nobody fully understands anymore.
3. Making sense of what happened — turning a burst of related alerts into "here is the incident, here is the probable cause." Opsgenie never really did this job; humans did it at 3 a.m., in the dark, by reading raw alerts.

The like-for-like swap replaces job 1 and ports job 2's accumulated rot verbatim. The better plan: replace job 1 with the most boring option available, and use the migration window to move jobs 2 and 3 into a layer built for them.

The parallel-run window is your friend

You don't have to cut over in one weekend. Webhooks fan out: during migration you can have Opsgenie (or its replacement) keep paging exactly as it does today, while a second consumer receives the same alert stream and does the correlation and analysis work alongside.

That's the pattern we built Culprit's Opsgenie and Jira Service Management adapters for. You add one outgoing webhook integration in Opsgenie or JSM Operations — an endpoint URL and an auth header, about ten minutes of clicking — and every alert your existing flow handles also lands in Culprit, where it is correlated into incidents and analyzed for probable root cause. Your pager of record does not change. Nothing about your escalation path is at risk. You're evaluating the new layer against live production traffic, not against a demo dataset.

Two details worth knowing before you wire it up:

• Enable only "alert is created" and "alert is closed" in the integration's action mapping, and tick "add alert description." Opsgenie's other webhook actions (acknowledge, add-note, assign) are workflow chatter, not signal.
• Opsgenie priorities carry over — P1 through P5 map onto severity automatically, so your existing priority discipline survives the move.

What to look at during the parallel run

Give it two weeks of real traffic and then ask three questions:

What's the compression ratio? Count the alerts that went in and the incidents that came out. If 400 Opsgenie alerts collapsed into 12 incidents, that ratio is the noise your on-call rotation has been absorbing by hand. It is also the clearest number you'll ever get for justifying the migration project to whoever asks.

Was the analysis right? For each incident, compare the automated root-cause hypothesis against what your responder actually concluded. It will not be right every time — no automated analysis is — but "roughly right in 60 seconds" against "definitely right after 40 minutes of log-diving" is the trade you're evaluating.

What left the building? Pull up any alert in your old flow and look at what's in it: internal hostnames, customer emails in stack traces, the occasional bearer token in a panic dump. Every vendor in your notification chain has been receiving those. In Culprit, that data is tokenized at the edge before storage, analysis, or notification — so the parallel run is also a live demonstration of what your alert pipeline looks like when sensitive values stop traveling through it.

The checklist

• [ ] Pick your on-call replacement early — schedules and escalation policies migrate slowly, and the JSM path has a documented parallel-run allowance.
• [ ] Export your Opsgenie configuration now (integrations list, routing rules, alert policies). You'll want the inventory even if you port none of it.
• [ ] Audit routing rules before porting them. Any rule nobody can explain gets a two-week trial deletion during the window, not a permanent home in the new system.
• [ ] Stand up the parallel run: keep the existing pager, add a webhook consumer for correlation and analysis, compare for two weeks.
• [ ] Measure the compression ratio and the analysis accuracy. Decide with numbers.
• [ ] Cut over the pager last, after everything downstream of it has already proven itself.

The deadline is April 2027, but the useful part of this migration isn't beating the shutdown — it's that for one project cycle, "we've always done it this way" is off the table.

Setup details for the Opsgenie and JSM Operations webhook integrations are in your Culprit workspace under Settings → Services → adapter recipes.