Migration

Opsgenie Is Shutting Down: A Practical Migration Plan

MontyApr 21, 2025 5 min read

Atlassian has announced that Opsgenie is being retired. If you rely on it, this is a migration you will do at some point, and doing it calmly is considerably cheaper than doing it in the final month.

Start with an inventory, not with a tool

Write down what you actually have. List your alert sources — everything that sends alerts in, and grep your infrastructure repositories for the API hostname to find sources nobody remembers. List routing rules, schedules, escalation policies, and outbound integrations. Then list actual usage: which of these fired in the last ninety days? A typical team finds a third of their integrations are dead, and migrating dead integrations is pure waste.

Migrate in order of pain, not order of listing

Stage one: the noisiest real source, to prove the whole path end to end. Stage two: the rest of the sources, now mechanical. Stage three: schedules and escalation. Stage four: reporting and integrations.

Run both in parallel

For at least two weeks, send alerts to both systems. This is the only way to discover that one source has a payload shape you did not anticipate. Set an explicit end date for the parallel period, or it runs for eight months.

The payload translation

Opsgenie's alert shape has fields your new system may not use. Map message to title, description to description, priority to severity. The priority mapping deserves attention: P1 to critical, P2 to high, P3 to medium, P4 and P5 both to low. Check whether your target expects specific casing — several systems require uppercase severity and silently fall back to a default otherwise.

Two behaviours to check before you commit

Deduplication: Opsgenie's alias gives explicit control over what counts as a duplicate; not every system works this way. Response semantics: some ingestion endpoints return success regardless of whether the request was accepted, so you cannot verify from the response code — verify by looking at the incidents created instead.

The schedule migration

Rebuilding rotations by hand usually takes an hour and is a good opportunity to fix things: is the rotation length still right, is the handover time sensible, does the escalation chain end with a different human, do the phone numbers still work?

The cutover

Do it in a low-risk window with the team present, keep the old configuration exported to a file, and fire a real test alert through each major source afterwards.

The timeline

If the shutdown is more than six months away, spend an afternoon on inventory now. If it is closer, compress but keep the parallel period — that is the part that catches the surprises.

Monty