Migrating off Opsgenie: what to move, and when, before April 5, 2027

The deadline is Atlassian's, not yours. Opsgenie stopped selling in June 2025 and shuts down on April 5, 2027, with customer data deleted. Here is what to move, in what order, and how long it actually takes.

If you run on-call in Opsgenie, you have a fixed date on the calendar and one decision to make before it. This guide is vendor-neutral: it covers what leaves with the product, what to inventory, the order that keeps you covered while you move, and an honest read on how long it takes. Perstat shows up at the end, under the consolidation question, not as the premise.

What the shutdown actually means

Two dates matter. End of sale was June 2025, so there are no new Opsgenie purchases or expansions. Shutdown is April 5, 2027, when the service goes offline and customer data is deleted.

The word that governs your planning is deleted. Schedules, escalation policies, integration configuration, and alert history are not parked somewhere you can retrieve later. Whatever you want to keep, you export before the date.

This is Atlassian’s product decision, stated plainly. It says nothing about the tools around it; it just sets your timeline. One consequence worth flagging for regulated teams: if you fall under DORA, applicable since January 17, 2025, or under NIS2, your incident history is evidence. Export it while it still exists.

Start with an inventory, not a tool search

Give yourself an hour in the Opsgenie console and write down what you actually use. Most teams find less than they feared and a few things they had forgotten. Five buckets cover it.

Schedules and rotations

Who is on call, when, across which teams and time zones. Note the overrides and holiday patterns too; those are the details that break quietly after a move.

Escalation policies

The chains: who gets paged, after how long, and what happens when nobody acknowledges. Capture the timing, not just the order.

Integrations and alert sources

Every system that opens an alert: monitoring tools, cloud provider alarms, error trackers, webhooks, email pipelines. This is usually the longest list and the part that eats the most calendar time, because each source has to be re-pointed and tested on the other side.

Routing and teams

How alerts map to teams, tags, and priorities. Routing rules encode institutional knowledge that is easy to lose in a rushed cutover.

History and reports

Past alerts, incident timelines, on-call reports. Decide what you need to keep and export it early, in whatever format Opsgenie gives you. Do this first, because it is the only bucket with a hard expiry.

The order that keeps you covered

Do not flip a switch. Run both systems in parallel and move alert sources one at a time.

1. Export history and reports now, before anything else changes.
2. Finish the inventory above.
3. Decide: point replacement or consolidation (next section).
4. Rebuild schedules and escalation policies in the new tool. Keep them identical at first; improve later.
5. Re-point integrations one source at a time, and confirm each one actually pages a human before moving to the next.
6. Run both systems in parallel for at least one full on-call rotation, so a real week of alerts proves the setup.
7. Cut over, then decommission Opsgenie once you have exported everything you need.

Point replacement, or one move for the whole stack?

This is the real decision, and it is worth thirty minutes before you shortlist anything.

Opsgenie does on-call and alert routing. You can replace it with another dedicated on-call tool and leave the rest of your stack alone. That is the low-surprise path, and for some teams it is the right one.

The alternative is to notice that you already have the box open. Most teams run on-call next to separate uptime monitoring, a status page, and an incident process, often from three or four vendors that do not share data. A forced migration is a rare chance to collapse some of that into one place at no extra disruption, because you are rebuilding schedules and re-pointing integrations anyway.

Neither answer is automatically correct. If your alert sources are deep in one ecosystem, or you lean on tight Jira Service Management integration and ticketing, a like-for-like on-call tool keeps your workflow intact. If your pain is tool sprawl, four bills and four consoles for one question, consolidation is on the table for the first time without extra upheaval.

An honest effort estimate

Plan for two to six months of lead time, and do not confuse lead time with work.

The hands-on rebuild for a small team, a few schedules and a handful of integrations, is a week or two of real effort. What stretches it across months is everything around the config: agreeing on the new escalation design, re-pointing and testing each alert source without paging a sleeping colleague at 3 a.m. for a test, running in parallel long enough to trust it, and letting muscle memory catch up so people reach for the right app under pressure. Larger orgs with many teams and dozens of integrations land at the upper end.

The two things that actually cost time are integrations, each one re-pointed and verified, and parallel running, which you cannot skip and stay covered. Budget for both and the deadline is comfortable. Ignore them until Q4 2026 and it is not.

A short checklist

• Export alert history, incident records, and on-call reports first.
• Inventory schedules, escalation policies, integrations, routing, and reports.
• Decide: point replacement or consolidation.
• Rebuild schedules and escalations identically in the new tool.
• Re-point integrations one at a time, testing each.
• Run both systems in parallel for one full rotation.
• Cut over, confirm your exports, then decommission.

Where Perstat fits

If consolidation is on your list, Perstat is one option to weigh. It puts uptime monitoring, status pages, incident response, and on-call in one product, hosted in the EU by a German company with no US parent. The Opsgenie concepts map over directly: schedules become on-call rotations, escalation policies become escalation from push to SMS to phone call, and acknowledgment stays acknowledgment. The monitoring that pages you sits in the same product: HTTP, TCP, and DNS checks down to 10-second intervals from six continents, confirmed across regions before an alert fires, so one flaky route does not wake the team. The same move gives you status pages on your own domain and SLA reports with curated exclusion windows (sample here).

We are equally clear about what it does not replace: there is no Jira Service Management, no ticketing, no APM, and no log management. If those are load-bearing for you, a dedicated on-call tool is the better fit, and that is a fine result of this exercise.

The Opsgenie comparison page has the concept-by-concept mapping, and pricing is on the page, net of VAT, with a free tier to start.

Start monitoring free or take the product tour. No signup for the tour, no sales call for the price.