Opsgenie end of life date: full timeline to April 5, 2027

Opsgenie end of life is April 5, 2027. That is the date Atlassian calls "end of support": access to Opsgenie is shut off, the REST APIs stop responding, and any data you did not migrate is deleted. New sales already ended on June 4, 2025, and teams whose Opsgenie came bundled with Jira Service Management lost it in October 2025. This page lays out the full timeline, what stops working at each step, who is affected, and what to do before the deadline.

Quick summary

• Opsgenie shuts down on April 5, 2027. Atlassian's support docs say access is cut off that day and unmigrated data is permanently deleted.
• End of sale was June 4, 2025. Existing customers can still add seats and renew, provided the term ends before April 5, 2027.
• If you migrate to Jira Service Management or Compass with Atlassian's tool, Opsgenie is turned off automatically 120 days after your migration date, which can land well before April 2027.
• JSM-bundled Opsgenie ended in October 2025. Standalone Opsgenie runs until the 2027 date.
• The Opsgenie REST APIs keep working until April 5, 2027, so you can still export schedules, escalation policies, and routing rules as JSON today.

Why listen to us

I am Léo, founder of Hyperping. We sell an on-call and monitoring product that competes with Opsgenie's replacements, and we run a free migration service for Opsgenie customers, so I have a commercial interest in where you go next. I wrote this page because the date questions ("when is Opsgenie going away", "opsgenie end of life date") kept landing on our alternatives guide, which does not answer them directly. Every date below comes from Atlassian's own announcement and support pages, and I link to them so you can check.

What does "end of life" mean for Opsgenie?

Atlassian's announcement and migration pages do not say "end of life". They use two other terms, and they mean different things:

• End of sale, June 4, 2025: Atlassian stopped selling Opsgenie to new customers and stopped edition upgrades. Existing customers keep using it, and can still add seats and renew inside their current tenant.
• End of support, April 5, 2027: this is the shutdown. Atlassian's support documentation says users will no longer be able to log in or retrieve data, remaining Opsgenie-based integrations stop working, the mobile app is deactivated, and unmigrated data is permanently deleted.

"End of life" is the term most people outside Atlassian use for the second date. So when someone asks whether Opsgenie is going away, the answer is yes, on April 5, 2027, and Atlassian has announced no extended-support option beyond it.

Opsgenie end of life timeline

Sources: Atlassian's announcement post The evolution of IT operations, the Migrate from Opsgenie page, and the support article What happens when Opsgenie is turned off.

What stops working, and when?

For standalone customers who have not started an Atlassian migration, nothing changes until April 5, 2027. Opsgenie keeps alerting, schedules keep rotating, and the API keeps answering. You are running on a product with a published end date, but the product itself works as before.

For customers who migrate to JSM or Compass with Atlassian's tool, the timing is different. During the 120-day parallel window both products run and data is synced between them. When that window ends, or when you turn Opsgenie off manually, Atlassian's support docs say the following happens:

• Users can no longer log in to Opsgenie or retrieve any data from it.
• The Opsgenie mobile app is deactivated.
• Any integration still pointing at Opsgenie (Datadog, Prometheus, CloudWatch, custom webhooks) stops delivering alerts.
• Only migrated data is available in JSM: alerts, schedules, escalation policies, incident history, audit logs, and migrated configuration. Everything else is deleted.

On April 5, 2027 the same thing happens for everyone still on the platform, and the REST APIs go with it. Opsgenie-hosted status pages go offline too, so subscribers need a new URL before that day. Anything you want to keep has to be exported before then.

Who is affected: standalone vs JSM-bundled Opsgenie

Standalone Opsgenie

You bought Opsgenie directly, on the Free, Essentials, Standard, or Enterprise edition, and your team logs in at its own Opsgenie URL. The April 5, 2027 date applies to you in full. Atlassian describes its migration to JSM or Compass as "largely automated for most customers", and you can keep renewing until the shutdown, so your last term may end shortly before the date rather than on it.

Opsgenie bundled with Jira Service Management

Some Jira Service Management Cloud plans came with Opsgenie attached rather than sold separately. Atlassian's migration guidance says these sites did not go through the standard migration process and were handled on a separate track. That track closed in October 2025, and those teams now use the on-call and alerting features built into JSM itself.

If you are in this group, the 2027 date is not your deadline, since your Opsgenie access already ended. The open question for you is whether JSM's built-in on-call is what you want long term, which is covered in OpsGenie vs Jira Service Management.

What does Atlassian recommend, and where does it fall short?

Atlassian offers two destinations and splits them by team type in its own guidance:

• Jira Service Management for ITSM teams: end-to-end incident management with alerting, on-call, change management and problem management.
• Compass for DevOps teams: alerting and on-call management alongside a software component catalog.

Atlassian describes the migration as largely automated, and it comes with the 120-day parallel window. Atlassian also says customers "may be eligible for a limited-time promotional discount", and that customers without an existing JSM subscription who migrate before their Opsgenie term ends get the remaining time credited to the destination product.

Before defaulting to that path, these are the limits I would weigh:

• Per-agent pricing. JSM is priced per agent, and on-call features depend on the tier. Look up the current figure on Atlassian's JSM pricing page and multiply it by everyone who needs to acknowledge an alert, including responders who never touch a ticket queue.
• No uptime monitoring. Neither JSM nor Compass checks your endpoints from outside. You keep whatever monitoring tool fed Opsgenie, and every one of its integrations has to be rewired.
• Several products instead of one. Public status pages are a separate Atlassian product (Statuspage), and Compass is separate from JSM, so a full replacement can mean two or three subscriptions.
• The 120-day window. Once you migrate, Opsgenie turns itself off 120 days later. A "try JSM and see" migration commits you far sooner than April 2027.
• Mobile on-call lives inside the Jira Cloud app rather than a dedicated app. From the feedback I read, responders find it slower than Opsgenie's app was.

Nothing forces you into JSM. The REST API exports the schedules, escalation policies, and routing rules you need to rebuild on another platform. I ranked the options in the Opsgenie alternatives guide and will not repeat that here. If you want to see how Hyperping lines up specifically, the OpsGenie alternative comparison page covers features and pricing side by side: our Essentials plan is $29/mo ($24 billed yearly) with on-call schedules, escalation policies, phone call alerts, 50 monitors, and a status page, so the monitoring that fed Opsgenie comes in the same tool.

What to do before the shutdown

As I write this in August 2026, there are under eight months left. A careful migration takes four to eight weeks, and you do not want to be doing it in March 2027 alongside everyone else who waited. These five steps are in order.

1. Export your Opsgenie configuration now

Alert history exports as CSV from the alert list or the analytics reports. On-call schedules, escalation policies, routing rules, and your integration list have no full configuration export in the UI, so pull them as JSON through the Opsgenie REST API (the schedule, escalation, and policy endpoints) while it still answers. Do this even if you have not chosen a destination: after April 5, 2027 there is nothing left to export.

2. Pick a destination

Decide between Atlassian's two paths and a third-party replacement. The deciding factors are per-agent cost at your team size, whether you want monitoring and status pages in the same tool, and how much of the setup you are willing to rebuild by hand. The alternatives guide and the JSM comparison are the two reads for this step.

3. Rebuild schedules, escalation policies, and integrations

Recreate rotations, overrides, escalation steps, and notification channels on the new platform, then repoint every alert source away from Opsgenie. The Opsgenie integration migration guide walks through Datadog, Prometheus, AWS CloudWatch, and Grafana one by one, and the 14-step migration checklist covers the rest of the setup.

4. Run both platforms in parallel

Keep Opsgenie alerting alongside the new tool for two to four weeks and fire test alerts through every escalation path, including the ones that only trigger at night. Hyperping has a native Opsgenie integration for exactly this, so both platforms receive the same alerts until you are confident in the routing.

5. Cut over well before April 2027

Set your own cutover date around your renewal rather than the shutdown, disable routing to Opsgenie, update runbooks and onboarding docs, and archive your final exports somewhere your team can find them. If you migrate through Atlassian's tool, remember that the 120-day window is your real deadline, not April 5, 2027.

If you would rather not do the rebuild yourself, we move Opsgenie customers to Hyperping for free: send us your export and we recreate monitors, schedules, escalation policies, alert channels, and your status page within 48 hours, then you run both in parallel and cut over when ready.