Opsgenie Migration: Deadline, Options and Cutover

What changed, and by when

Opsgenie is on a published end-of-life schedule. Three dates matter, each stated in Atlassian's own documentation.

Existing customers continue without interruption between those dates. You can still buy seats up to 2027-04-05, and still renew, but only if the term concludes before that date. The 2025-06-04 change removes the usual levers for buying time: no edition change to unlock a feature that would simplify the move, and no extra site to stage it on.

Decision tree

One branch matters. The rest is consequence.

Are you staying inside the Atlassian ecosystem? If yes, the destination is Jira Service Management. The current migration-options documentation lists only Jira Service Management plans, mapped from your existing edition: Opsgenie Free to JSM Free, Essentials to Standard, Standard to Premium, and Enterprise to either Premium or Enterprise. Read the deprecation table below first, because staying inside the ecosystem is not the same thing as keeping what you have.

If no, you are running a replacement selection under a deadline. Inventory first, shortlist second. The failure mode is choosing from a feature page and finding the gap during the cutover test, when the calendar has stopped being flexible.

Is the second Atlassian destination viable? Atlassian's Opsgenie documentation has also directed teams to Compass for developer alerting, with Jira Service Management framed as the path for IT operations. Anyone who picked Compass on that basis needs this.

When, not whether. Set an internal target well before 2027-04-05. Subtract a full rotation of parallel running, a cutover test, a repair window, and any change freeze you observe. What remains is the runway.

Inventory checklist

Do this before evaluating anything, Jira Service Management included. It is the one artefact that survives whichever way the decision goes. Record an owner beside each item.

• Schedules. Rotation shape and length, timezone, handoff time, and who is actually in it. Note where one person wears two hats.
• Escalation policies. Each step, its delay, target, channel and stop condition. Note which have never fired.
• Teams and groups. Membership, and specifically anything modelled as a Group rather than a team.
• Inbound integrations. Every alert source, its type, its key or endpoint, and the payload fields routing depends on.
• Outbound and bidirectional integrations. Ticketing, chat, status pages, anything receiving from Opsgenie or syncing state back.
• API and infrastructure-as-code dependencies. Terraform, scripts, CI jobs and internal tools holding a stored key. Grep your repositories for the API hostname; it finds more than asking people does.
• Contact methods and notification rules. Per person: numbers, devices, channel order, delays, quiet hours. This decides whether a page reaches a sleeping human, and it is most often reconstructed from memory.
• Heartbeats. What sends each one, its interval, and what should happen on expiry. Note which are V1.
• Routing rules. Global and team routing, time-based rules, and anything that suppresses, deduplicates or reshapes alerts. Note which are V1.
• Historical data and audit requirements. What you must retain, in what format, and who signs off that a copy suffices.
• Custom actions. Anything driven by the Edge Connector, custom scripts, or automation triggered from an alert.

What Atlassian migrates for you, and what it does not

For the Standard, Premium and Enterprise paths, Atlassian's feature-changes documentation is specific about what carries over untouched and what needs hands on it.

On sequencing, Atlassian's pre-migration guidance is advisory rather than mandatory: customers should consider upgrading deprecated global integrations, Heartbeats V1, Groups or Policies V1. Do it anyway. These are the items whose behaviour changes, and finding that out during a parallel run costs far less than finding it out during an incident.

Export: what you can actually get out

Atlassian documents a schedule export: the request exports a schedule to a .ics file, at GET https://api.opsgenie.com/v2/schedules/:identifier.ics. The same Schedule API page documents List Schedules, Get Schedule, and Get Schedule Timeline, which together let you enumerate what exists and resolve who is on call across a window.

That is useful, and it is less than it sounds. An .ics file is a calendar: it says a named person covers a named window. It does not carry the escalation policy attached to that schedule, the timeout before step two, each person's channel order, the routing rule that sent the alert to this team, or the reasoning behind any of it. Get Schedule Timeline can check that a new system resolves the same on-call person as the old one, but it is not a way to recover intent.

The calendar can be copied; the operating model has to be rewritten. Budget time to write the escalation logic down explicitly before rebuilding it anywhere. Teams routinely find here that the policy in the tool and the policy people believe they follow are not the same policy.

Requirements matrix

Score every candidate, Jira Service Management included, against the same columns. Fill it in yourself; the weights are yours, not a vendor's.

Two rows get skipped in practice: failure of the pager itself, because it feels hypothetical, and exit cost, because it feels pessimistic mid-selection. The Opsgenie end-of-life argues for both.

Dual-run plan

Parallel running means both systems receive the same alerts while only one may reach a phone. That constraint is the design. If both can notify, you have built a double-paging machine, and responders start ignoring one source, usually the new one.

Avoiding double pages. Either the new system ingests everything with every notification rule resolving to in-app only, or it notifies one volunteer whose job is to compare. Never enable both escalation paths for the same service on the same day, and write down which system is authoritative where the on-call person sees it.

How long. At least one complete rotation, so the run covers a weekend, a handover and every person in the roster. Shorter runs test configuration but not people, devices or do-not-disturb settings.

What to watch, roughly in order of how often it goes wrong.

• Routing parity. For every alert in the old system, did the same one arrive in the new, on the same team?
• Occupant parity. At each handoff, do both resolve the same person? Check a DST transition and any schedule spanning timezones.
• Volume parity. Alerts per source per day, both sides. A quieter source in the new system is usually a broken integration, not an improvement.
• Deduplication. Does a flapping source produce one alert or forty on each side?
• Close and auto-resolve. When the source recovers, does the alert close, or linger for cleanup?
• Heartbeat expiry. Stop one deliberately and confirm the new system notices in the expected interval.

Keep a difference log: one row per discrepancy, its cause, its resolution. Move alert sources in severity order, lowest first, so early mistakes happen on alerts nobody is woken by.

Controlled cutover test

Do not cut over on the strength of a configuration review. A person must observe each step rather than infer it from a log.

1. Fire from a real source. An actual integration, not the test button, which verifies the notification service rather than the path.
2. Confirm arrival and routing. The alert carries the payload fields your routing depends on and lands on the intended team.
3. Confirm step one reaches a phone. At night, on a locked and silenced device, on cellular rather than office wifi.
4. Let it escalate. Do not acknowledge. Confirm the secondary is reached after the timeout, through their own channels.
5. Acknowledge, and confirm escalation stops. A policy that keeps paging after acknowledgement is one nobody trusts twice.
6. Resolve from the source. Confirm the alert closes without manual intervention.
7. Exercise an override. Hand a shift over at short notice and repeat step three against the new occupant.
8. Exercise a dead-man path. Stop a heartbeat and confirm the resulting page reaches a person.
9. Record the evidence. Who tested, on which device and network, when, and the delay at each step.

The pass criterion is that a named person observed every step. A step skipped because it was inconvenient to test at night has not been tested.

Rollback

Rollback means different things at different stages. Write them down before you start, rather than discovering them under pressure.

Before the migration runs. Nothing has changed. Rollback is free.

During the parallel run. The old system is authoritative and the new one observes. Rollback is disabling the new system's ingestion, at near-zero cost. This is why the run should last longer than feels necessary.

After cutover, before decommissioning. The new system is authoritative, and the old configuration still exists with its integration keys intact. Rollback means re-pointing alert sources at the old endpoints and re-enabling its notification rules. That works only if you did not delete or rotate the old keys at cutover, so keep them disabled rather than deleted.

After decommissioning. Once the old configuration is deleted, its keys rotated away, or the subscription lapsed, there is nothing to return to. Rotating credentials is the practical point of no return, and it tends to happen earlier than intended because a security review asks for it.

After 2027-04-05. No rollback exists in any form. Access is shut off, the product is no longer accessible, and unmigrated data is deleted.

A workable rule: keep the old side configured and paused until the new path has carried a real production page at an unsociable hour and one full rotation has closed with an empty difference log. Then decommission deliberately, on a working day, with your export already taken and verified.

Review dates

Vendor facts move, and this page is a snapshot rather than a feed. Every source below carries the date this project last checked it, 2026-09-02, and that is the honest limit of what is claimed here.

Two cautions are specific to this topic. No Atlassian Opsgenie page exposes a last-updated date, so there is no per-page freshness to report from the vendor; the only available date is the date a human checked. And the documentation is inconsistent with itself, in that the Compass-specific Opsgenie migration pages no longer resolve while the left-hand navigation still links to them.

Before committing budget, headcount or a contract, re-check the primary sources directly rather than relying on this page, and record the date you checked beside the decision.