Opsgenie end of support: the 2027 deadline and how to plan your move

Atlassian stopped selling new Opsgenie subscriptions on 4 June 2025, and Opsgenie reaches end of support on 5 April 2027. After that date Opsgenie access is switched off and any workspace data you have not already moved out is deleted — so the real question for an on-call team is not whether to leave, but when to start and where to go. If you want the wider comparison first, see our Opsgenie alternatives guide; this page is the dated timeline and the planning checklist.

What “end of support” actually means

Atlassian announced the change on 4 March 2025 and closed new Opsgenie sales on 4 June 2025: since that date nobody can sign up for Opsgenie, and existing customers cannot change plans. (Atlassian Opsgenie licensing page, checked 2026-09-24)

Support then continues on the existing installed base until 5 April 2027. That date is a hard stop, not a soft one: access is turned off and any data you have not migrated out by then is deleted. (Atlassian Opsgenie licensing page, checked 2026-09-24)

If your team already has an Opsgenie subscription, it keeps working between now and the shutdown date, and you can still add seats to it. What has changed is that nobody new can start an Opsgenie subscription at any point between now and 5 April 2027 — the door only opens one way, and only for accounts that were already through it. (Atlassian Opsgenie licensing page, checked 2026-09-24)

Why this deadline is easy to underestimate

Nothing about Opsgenie changes for most users today. Alerts still fire, schedules still rotate, escalation policies still page the right person. That is precisely what makes the deadline dangerous: there is no degraded-performance warning sign, no error banner, no slow decline that forces the issue onto a roadmap. The tool works exactly as well on the day before the cutoff as it does two years before — until it stops working at all.

An on-call configuration is also not just data. It is the accumulated shape of how a team actually responds to incidents: who covers what, which alerts route where, which escalation tiers exist because of a specific past outage. Rebuilding that from scratch under deadline pressure, in the same week you are also trying to keep the lights on, is a worse position than starting the move while there is no pressure at all.

A timeline: work backward from 5 April 2027

There is no single correct migration timeline, but working backward from the hard deadline — rather than forward from “whenever we get to it” — is what keeps a migration from turning into a scramble. A reasonable planning horizon looks like this:

What happens to your data

Until 5 April 2027, nothing about your Opsgenie data changes on its own. (Atlassian Opsgenie licensing page, checked 2026-09-24) The REST API keeps working right up to that date, which matters practically: it is what a dry-run extract or a parallel-forwarding setup reads from, and it is your last resort for a manual export if a planned migration stalls.

After the shutdown date, two things happen at once: access to the product is switched off, and any workspace data you have not already moved out is deleted. There is no published grace period past 5 April 2027 and no announced self-service export tool beyond what exists today — which is why every item on the timeline above is dated before the deadline, not on it. If your own migration is not done by then, the record of who was on call for what, and why, goes with the product.

Where Atlassian points you: Jira Service Management

Atlassian’s own licensing and migration pages name Jira Service Management (JSM) as Opsgenie’s successor, though as of this check the Opsgenie pricing page itself still lists “Jira Service Management or Compass” as the destination — worth re-checking if you read it directly. (Atlassian Opsgenie licensing page, checked 2026-09-24)

Atlassian’s documented migration path is an automated tool (under Settings > Plan your move) that runs without downtime, a 120-day window of parallel access to both products, and a 14-day migration trial so you can see the result before committing. Alerting and on-call ship in every JSM plan; AI-assisted grouping and automation are reserved for the Premium and Enterprise tiers. (Atlassian Opsgenie migration page, checked 2026-09-24)

Not everything carries over unchanged. Atlassian’s own deprecation notes list Incident Command Center, Edge Encryption, MSP sub-accounts, Heartbeats V1 and Policies V1 as items that do not map directly to JSM; Opsgenie groups become JSM teams on the way across. (Atlassian Opsgenie deprecations documentation, checked 2026-09-24) JSM’s own per-agent pricing was not something we could confirm from a primary source at the time of writing — check Atlassian’s current pricing directly before you budget against it.

Weighing your options

JSM is the path Atlassian built for you, and it is a reasonable default if your team already lives in the Atlassian suite. It is not the only option, and treating it as the only option skips a decision worth making deliberately. Whatever you evaluate, the same questions apply:

• Migration effort. Does the destination have a real import path for your schedules, escalation policies and integrations, or are you rebuilding by hand?
• Integration coverage. Do the monitoring tools that currently page through Opsgenie have a supported path into the new platform?
• Pricing model. Per-agent, per-user, or usage-based — and what is actually included at the tier you would buy, versus sold as an add-on?
• Paging channels. Which channels are proven for your team’s real usage, not just listed as supported?
• Where it fits your stack. Staying inside a suite you already use (JSM inside Atlassian) trades a smaller number of new tools to learn against a dedicated on-call product that may fit your incident workflow more directly.

If you want the fuller comparison across every named option — PagerDuty, Jira Service Management and CallHeim, with sourced facts on each — our Opsgenie alternatives guide covers all three side by side. For dedicated on-call and incident response platforms beyond that set, our guide to PagerDuty alternatives covers the same evaluation criteria against a wider set of named vendors.

Cost is also worth pricing out explicitly rather than assumed. A per-agent JSM price and a per-user price on a dedicated on-call platform are not directly comparable line items until you know exactly which roles at your organisation actually need a paid seat — escalation targets and incident responders, typically, rather than every engineer who might occasionally look at a dashboard. Get an actual quote for your team size on each option before treating either as the cheaper choice.

A migration checklist

• List every object type you actually use in Opsgenie: users, teams, schedules, escalation policies, integrations, notification preferences, incident history and maintenance windows.
• Confirm which of those your destination platform actually imports, and which you will need to rebuild by hand rather than assume will “just come across.”
• Run a parallel-forwarding period before cutting over, so gaps in coverage show up while Opsgenie is still the safety net underneath.
• Test the full paging path on the new platform — not just that the configuration exists, but that a real alert reaches a real person.
• Set your own internal cutover date well ahead of 5 April 2027, so a stalled migration does not collide with the actual shutdown.
• Tell the whole team the old tool is going away before it goes away, not after.

How CallHeim handles this

Import tooling (early access) reads your PagerDuty or Opsgenie configuration (US-region accounts); an optional dry run lets you review the result before anything is written to your workspace.

Run in parallel during a move: CallHeim receives PagerDuty Events API v1 and v2 bodies, Opsgenie outgoing webhooks, and alerts forwarded from Splunk On-Call, Squadcast, Zenduty and Grafana OnCall. Every sender needs a CallHeim integration URL and key; existing PagerDuty routing keys are not reused.

Incident history import covers the last 90 days. Re-running an import updates the same records instead of duplicating them, and overwrites edits made to imported records.

E-mail paging is live in early access: incident pages go out through Resend with an acknowledge link, and sent and delivered status is recorded on the incident.

See CallHeim compared with Opsgenie, the Opsgenie migration path, the Opsgenie integration setup notes, or the fuller Opsgenie alternatives guide for how CallHeim stacks up against PagerDuty and Jira Service Management too.

Key takeaways

• New Opsgenie sales stopped 4 June 2025; support ends 5 April 2027, when access is cut and unmigrated data is deleted.
• Existing subscriptions keep working and can still add seats until the deadline — nobody new can start one.
• Atlassian’s documented path is an automated migration tool into Jira Service Management, with a 120-day parallel-access window and a 14-day trial.
• A handful of Opsgenie features (Incident Command Center, Edge Encryption, MSP sub-accounts, older heartbeat and policy versions) do not carry over unchanged.
• Work backward from the deadline: inventory now, evaluate and start a parallel run well before the last year, and leave margin before 5 April 2027 rather than aiming at it directly.