Opsgenie End of Life: Every Date, What Actually Stops and What You Have to Decide

Product end of life announcements are often much calmer than you'd expect. There's no dramatic crescendo or flashing lights; more often than not, you just get a blog post, a licensing page and a gradual yet frightening realization that the tool you've relied on for years now has an expiration date. That's where Opsgenie is right now. And its announcement landed in the software world with the emotional weight of a breakup text.

Atlassian's set the dates and your team (if they're still running Opsgenie) now has a finite window to decide what's next. The choice shouldn't be mysterious and ethereal. It can be perfectly manageable if you know what to expect and where to look.

Let's walk through all the key dates, what's changing and what's not, the realistic paths you can take and the things teams often forget until it's (almost) too late.

A quick orientation before we get into it

Before I start throwing dates and tables at you, let's take a minute to understand exactly what the change looks like.

Firstly, Atlassian isn't shutting down as a company and Opsgenie isn't vanishing into a puff of smoke. It's simply being folded like an umbrella into Jira Service Management and Compass, which is basically Atlassian's way of saying that the alerting and on-call features will still exist but the standalone product won't.

Think of it like your favourite TV show character being written out of the show but still coming back for flashback episodes. They're not gone, they're just behind the scenes.

And don't worry, you won't just wake up one day and poof! Opsgenie is gone. It'll be a slow, predictable timeline that you can stroll down calmly if you start now. You can sprint down later if you like the adrenaline rush of panic and scrambling, or if you're a real daredevil, you can ignore it entirely until someone shouts “Why is Opsgenie offline?” at 7.30 in the morning.

The Dates

Here's how it's been and how it'll all go down:

An important note: End of sale in June 2025 doesn't mean Opsgenie stops working completely. It just means that Atlassian won't be taking on any new customers. Existing customers can still renew (as long as the term ends before the shutdown) and add seats, but can no longer change editions. Opsgenie will keep working until April 5, 2027, which is when everything goes kaput.

After that, Opsgenie will be but a fond memory in the hallway of your software house, along with any data you didn't migrate before it switched off.

What actually stops working and what doesn't

Let's separate myth from reality here. Sometimes “support ends” can be misinterpreted as “the server has exploded,” which isn't very helpful. So, let's break it down properly.

Support availability

As mentioned, support won't magically disappear overnight. Atlassian will keep providing Opsgenie-specific support until April 2027, so you can still file tickets and get help with whatever you need.

There was one earlier change on April 5, 2025: Opsgenie chat support was replaced with a support request system, the same way Jira Service Management (JSM) support works. While that may sound scary, it wasn't the end of support for Opsgenie but a simple change in how you procure it. It was like switching from text to WhatsApp. The friend is still there, the medium just changed.

Product roadmap

Put simply, the roadmap is frozen. There won't be any more product updates, new features or enhancements rolling out in the future. Atlassian is moving its investment over to JSM instead of Opsgenie as a standalone product.

This pretty much means that if you've been waiting around for a specific Opsgenie feature, don't hold your breath.

Service operation

You'll have Opsgenie until April 5, 2027. You'll still get alerts, your schedules will keep rotating, your escalations will still run and nothing will suddenly stop working out of nowhere. But after that date, it's all gone. And if you're one of those teams who waited until the last minute to migrate your data, you'll be basking in the true meaning of regret when you see it all evaporate along with Opsgenie.

Your Three Paths (And the Real Cost of Doing Nothing)

Now you've got the timeline, it's time to ask yourself what you're going to do about it. Will you act on it today and get your act together before it's too late? Or will you have a good old cry when April 5, 2027 is suddenly tomorrow and you've procrastinated doing something about it?

The good news is you have three options, each with its own unique little personality.

Path 1: Move to JSM

The recommended path by Atlassian, since Opsgenie's alerting and on-call features are being absorbed by Jira Service Management (with some features moving to Compass, Atlassian's developer portal). Atlassian even provides migration tooling to get your configuration from A to B. And after you migrate, you get 120 days of parallel access to Opsgenie to validate the setup, so the last-minute panic is completely avoidable.

If your team already uses JSM or wants a full ITSM platform, moving to JSM will feel like natural evolution since your incident management, alerting, routing and entire platform happens in one place.

An important thing to remember, though, is that JSM's alerting model isn't identical to Opsgenie's. Schedules and escalations need careful checking. JSM also applies plan-based retention to alert data, which can really matter for teams with heavy compliance requirements.

One cost to check before you commit: JSM's native status pages are Enterprise-only, so teams on Standard or Premium usually need a separate Atlassian Statuspage subscription. We broke down the two-product cost of JSM Premium and Statuspage in a separate guide.

Compare All Quiet vs Jira Service Management →

Path 2: Move to a dedicated on-call platform

Some teams use Opsgenie purely for alerting and on-call, so ITSM is completely irrelevant. They don't want it, either. They simply need a platform that focuses on alerting, routing and reliability.

Path 2 takes more effort upfront than Path 1. You'll need to evaluate tools, recreate your schedules, reconnect your integrations and run a parallel test window. In return, you get a setup built for alerting and on-call, without an ITSM suite attached.

But we're talking about the shutdown itself here, so let's not rank tools. If that's what you're after, see our guide to the best Opsgenie alternatives. If you've already ruled out JSM, our list of Opsgenie alternatives that aren't Jira Service Management might tickle your fancy instead. Or, if you want to see how All Quiet handles the move, start with the Opsgenie alternative page.

Path 3: Stay put (please don't)

No one ever admits to considering this one but let's be honest, we all do. You can continue to use Opsgenie until it beds down for the long nap and you can't use anything. That's always an option. There's no cost to doing nothing… financially, anyway.

But you are taking on a heavy operational cost. You'll be running a tool with a fixed shutdown date and compressing your migration window day by day. You're basically betting your incident response on a platform that will inevitably disappear, which isn't a great bet when you already know the outcome.

Doing nothing is always an option but a rarely wise one.

What Carries Over to JSM (and What Doesn't)

This is the bit your compliance team will highlight in yellow, so read carefully:

What's staying

Atlassian's migration tooling will move your core Opsgenie config into JSM, including:

• Alert rules
• Routing logic
• Schedules
• Escalation policies
• Heartbeats (Premium and Enterprise plans only; see the checklist)
• Most integrations (on-prem and ChatOps integrations need extra work; see below).

The goal is to preserve the basic shape of your workflows so responders don't feel like they're trying to learn a new language.

What's going

Here's where things get thorny. Opsgenie retains alert data indefinitely, whereas JSM doesn't. Instead, it applies tiered retention windows based on your chosen plan: one month for Free, one year for Standard, three years for Premium and five years for Enterprise. Once it's deleted from JSM, it can't be recovered.

On top of data flying away like a feather in the wind, some Opsgenie features don't carry over at all, and others need rework. Straight from Atlassian's list of feature changes and deprecations:

And two softer losses: Opsgenie-specific UI patterns and custom workflows that depend on Opsgenie's exact behaviour.

If you have compliance obligations, no matter how heavy, you should read this section twice.

The Pre-Migration Checklist

Now for the golden egg of your migration journey. Without a checklist, you'll hit a “we forgot that part” wall every 15 minutes, so sit down, pour yourself a cup of tea, and get your checklist sorted. Here's a good one to follow:

1. Export your Opsgenie data. Decide what you need to keep and export it before migration or risk losing it all. And don't forget to make sure it's readable or you'll create more problems than you solve.
2. Map on-call schedules. Pay attention to overrides, holidays, time zones and anything else that can add a spanner in the works. They rarely map perfectly on the first try.
3. Verify escalation policies. Test them! Escalation policies migrate to JSM but don't assume they behave the same there or on a new platform, because they seldom do.
4. Repoint integrations. Monitoring tools, chat platforms, ticketing systems: make a list, check it twice, update it so it stays nice.
5. Check your heartbeat monitoring. In JSM, heartbeats are only available on the Premium and Enterprise plans, where they sync automatically with two exceptions: email-based heartbeats need their email domain updated, while any old global (v1) heartbeats must be assigned to a team and switched to team-based heartbeats by hand, before or after migration. Check that every one of them fires and on a new platform, you can recreate them.
6. Validate alert routing parity. Run test alerts through both platforms and confirm that they land where they should.
7. Plan a parallel run. Migrating to JSM gives you 120 days of parallel access to Opsgenie, so don't cut over overnight. Run both systems for a while to see how they compare.
8. Confirm retention requirements. Sit down with compliance, check your JSM plan's alert retention against your obligations and pop the prosecco when everything falls into place thanks to your top-tier organization skills.
9. Update responder documentation. Runbooks, playbooks, on-call guides, training materials, information videos; update everything.
10. Port your phone numbers. If you use Atlassian-owned Opsgenie phone numbers, they'll need to be ported manually before migration, while Twilio-owned numbers sync automatically.
11. Schedule a shutdown rehearsal. No finale goes down smoothly without one or two test runs, so pretend Opsgenie is gone and see what breaks. Then fix it, rinse and repeat.

What teams forget until it's too late

Every migration has its hiccups. Every team wishes they had thought of that one thing they missed before it got overlooked, and Opsgenie's end of life is no exception. Watch out for things like:

1. JSM's plan-based alert retention
2. Heartbeats that JSM only offers on Premium and Enterprise
3. Schedules that rarely map perfectly
4. Escalations that need testing
5. That JSM isn't Opsgenie with a fresh lick of paint.

If you remember these five things, you're already ahead of most teams.

How to approach the subject with your team

Don't let something as big as a migration become background noise in the office. If you're in charge of making sure the migration actually happens, you'll need to do a few things first:

• Be clear about the dates
• Frame the change as a reliability decision
• Set expectations for a parallel run
• Involve responders early
• Give them a medium to ask questions and get support
• Update documentation before anything happens.

The main goal: don't create a panic.

A Sunset Is Not a Shutdown

Opsgenie's end of life is a pretty sunset with a schedule. You know when the sun reaches the horizon and you have plenty of time to get to the viewpoint, so don't panic. Atlassian gave clear dates, a migration path and a destination. You have time, you have options, and now you have a plan.

If you're planning the move with infrastructure as code, our Terraform-first Opsgenie migration guide walks through it step by step.

Or make the choice easy and start a free trial of All Quiet.

Sources checked

• Migrate from Opsgenie, Atlassian, checked 8 October 2026: end of sale June 4, 2025; shutdown and data deletion April 5, 2027; 120 days parallel access.
• Opsgenie pricing, Atlassian, checked 8 October 2026: March 4, 2025 announcement; Jira Service Management and Compass as destinations; renewal conditions.
• Support coverage after migration, Atlassian Support, checked 8 October 2026: chat support replaced April 5, 2025.
• Feature changes and deprecations in Jira Service Management, Atlassian Support, checked 8 October 2026: heartbeats, deprecated features, integrations, phone numbers.