Most of the Opsgenie conversations we’ve had this year have started the same way. Someone got the Atlassian email, did the math on Jira Service Management Operations, and realized the math doesn’t work. Then they spent a week trying to convince themselves they were reading the pricing page wrong.
They weren’t.
Atlassian stopped selling Opsgenie on June 4, 2025. The platform turns off on April 5, 2027. That’s about twenty-two months from now, depending on when you read this, and the path Atlassian wants you to take (the JSM one) is the one that costs the most for most enterprise teams. That’s not a marketing position, it’s just how the per-seat math falls out once your responder list includes anyone who isn’t a Jira user.
So now you have a decision to make. The rest of this post is what we’ve learned about how to make it.
What happened
Atlassian retired Opsgenie as a standalone product. Existing customers can run on their current renewals until the cutoff, then they lose access to the API, support, integrations, and the mobile app.
The company called this a product consolidation; in practice, it’s a discontinuation. The standalone pricing is gone, the dedicated success function folded into JSM, and the engineering team isn’t building new Opsgenie features. Partners are quietly moving their marketplace listings over to JSM Operations or to other platforms. None of this is dramatic on day one, but it all adds up.
We’ve watched this playbook before. Trello followed roughly the same arc after acquisition, just stretched over a longer timeline. Opsgenie is the same thing on fast-forward.
Why Atlassian did this
The honest answer is portfolio simplification. Atlassian sells Jira and Confluence. Opsgenie sat next to those products with its own brand, its own pricing, and its own buyer relationship. From a portfolio standpoint, that’s two support stacks, two sales motions, and an on-call capability that only Opsgenie customers can reach. Rolling it into JSM Operations gets rid of the duplication.
That’s clean for Atlassian. It’s worse for customers, because the seat economics change shape when you move from per-responder Opsgenie pricing to per-agent JSM pricing.
A mid-market fintech in Edinburgh ran the numbers right after the announcement and put it bluntly to his team: “They’re basically replacing it with a new product, but they’re charging four times as much, so I can’t afford it.” He’s not wrong about his situation. He’s also not unusual. For a deployment at Footlocker scale (something like seven hundred users, a hundred and fifty teams, a couple hundred integrations), the gap between what Opsgenie cost and what JSM Operations costs isn’t a like-for-like swap. It’s a different conversation.
What end-of-life actually means
End-of-life isn’t a single date. It’s a slow degradation between end-of-sale and the cutoff, and the degradation matters more than the dates do.
Right now (early phase), the product works. Renewals continue, integrations fire, and support tickets get answered. What’s stopped is forward motion: new observability tools don’t get integration support, lower-priority bugs sit, and partners decide whether their Opsgenie listing is worth maintaining (a lot of them are deciding it isn’t).
In the middle phase, that drift accelerates. Custom integrations against the Opsgenie API still work, but you start to feel like the last user of a deprecated standard. Documentation goes stale because the writers moved to JSM. Customer success conversations route through Atlassian’s enterprise reps, who get compensated for JSM conversions, not Opsgenie retention. Support response times slip.
In the final phase, the API shuts down on the published schedule and support contracts end. Whoever hasn’t migrated faces a hard cutover with no fallback. The teams that wait this long migrate under deadline pressure, which produces worse vendor selection, worse pricing, and rushed cutovers that come back to haunt them in the first month after go-live.
The cost of waiting isn’t zero on day one. By twelve months in, it’s a lot more than zero.
The four paths forward
Every team migrating off Opsgenie picks between four options. The choice isn’t really about features. It’s about which operating model fits the way you actually respond.
Diagram of the four migration paths from Opsgenie: Atlassian JSM Operations (per-agent ITSM-ticket model), a peer incident response tool such as PagerDuty incident.io or Rootly (on-call sold separately at the latter two), an incident orchestration platform such as AlertOps (upstream correlation, multi-channel response, bidirectional ITSM), or an in-house build (Grafana Cloud IRM plus Twilio, with the maintenance burden that returns most teams to a commercial platform within two years).
Migrate to Atlassian JSM Operations. This is what your Atlassian rep will recommend. For teams that already live deep in the Atlassian stack (Jira for engineering work, Confluence for docs, Bitbucket for source), JSM Ops keeps the relationship simple. The trade-offs are real though: per-seat economics get worse at scale because of how JSM agent seats are priced, Opsgenie’s standalone focus is gone, and JSM is fundamentally a service management platform that absorbed an on-call feature. It wasn’t built as an incident response or orchestration platform from the ground up.
Move to a peer incident response tool. PagerDuty, incident.io, Rootly, and a handful of others sit at the same operational layer Opsgenie did. They’re purpose-built for on-call and incident response. The catches: each has its own assumptions about how teams work (chat-native versus on-call-first, opinionated workflows versus configurable ones), and pricing isn’t always what the sticker says. incident.io and Rootly both sell on-call as a separate paid module on top of their incident management plan. PagerDuty bundles on-call but sells AIOps as a separate consumption SKU starting at $699 a month annual. The “real” price shows up after you’ve added the modules you actually need. We walked through the full comparison in our ranked breakdown of Opsgenie alternatives.
Adopt an incident orchestration platform. Orchestration sits one layer up from incident response tooling. The platform ingests signals from observability before they hit a human, correlates and suppresses noise, then routes through policies that handle service ownership, severity, vendor handoffs, and channel preference at the same time. The category is smaller than incident response tooling. It fits when alert volume gets into the thousands per cascading incident and you need multi-tier NOC plus compliance-grade audit. AlertOps lives here. So do a few others, depending on how you draw the category lines.
Build it yourself. A few teams try to assemble their own on-call layer from open-source pieces. Usually some combination of Grafana OnCall (which Grafana archived as OSS in March 2026, leaving Grafana Cloud IRM as the only path forward), custom routing logic, and Twilio for delivery. The build is fine. The maintenance is brutal. Most teams that pick this path are back on a commercial platform within two years.
That’s the menu. Now we get to which path actually fits.
Why JSM doesn’t work for most enterprise teams
This is the question we get asked most. Atlassian sells JSM Operations hardest, so it gets evaluated first, and most enterprise teams end up ruling it out. Four reasons keep coming up.
The first is the responder pool. JSM agent seats are priced for the Jira-using engineering team. Operators, vendor contacts, on-call rotations, stakeholders who never touch a ticket – they all need seats too, and at JSM agent pricing the bill grows fast. One Fortune 500 platform operations lead described the dynamic during her evaluation: “we are still using OpsGenie, which is of course going away. So we’re looking at some alternatives. Of course, Atlassian really wants us to convert to their JSM.” Her rep was selling JSM hard. Her math kept pointing elsewhere.
The second is ITSM standardization. A lot of enterprise teams run ServiceNow as their system of record. JSM also wants to be the system of record. When the on-call platform lives inside JSM, you end up running two ITSM-adjacent stacks side by side, with reconciliation work in between. One Footlocker-scale operations lead summed up the conversation she kept having with her internal team: “our ServiceNow team tells us that, oh, well, ServiceNow does all that on-call stuff.” You can probably guess how that ends.
The third is the data model. JSM treats incidents as ticket types. That works for service requests. It doesn’t match how mature incident orchestration is architected, where the incident is a structured object that carries correlation context, channel preferences, escalation state, and audit history independent of whatever ticket system happens to be attached.
The fourth is the tier gate. Basic on-call lives in JSM Standard at about $20 per agent per month annual. The features enterprise teams actually use (advanced alert integrations, incident investigation, major incident management, CMDB integration) sit in JSM Premium at about $48 per agent per month. The per-agent economics at Premium scale frequently push TCO past purpose-built alternatives, even ones with more capability.
None of this means JSM is bad. JSM is a fine service management platform for what it was built to be. JSM Operations is the on-call feature inside that platform, and it isn’t a standalone Opsgenie replacement for most of the post-Opsgenie market. If you want the longer version, we wrote a full teardown of why JSM isn’t a 1:1 Opsgenie replacement.
See how AlertOps is architected for enterprise incident orchestration at alertops.com/demo.
How to think about the decision
A feature comparison isn’t where this decision lives. Three dimensions matter more.
First, operating model. What does response actually look like at peak incident load? A five-person platform team in a Slack workspace is a different problem from a multi-tier NOC with follow-the-sun coverage and vendor handoffs – incident response tools handle the first, orchestration platforms handle the second. Picking the wrong layer doesn’t show up the day you sign the contract; it shows up nine months later, when the platform won’t bend the way the team needs it to.
Second, commercial structure. Pricing has to match the responder population, not the engineering org chart. Opsgenie’s per-responder seat scaled across the full population, JSM’s per-agent seat scales differently, incident.io and Rootly sell on-call separately, and PagerDuty sells AIOps separately. The cheapest sticker price usually turns into the most expensive contract once you’ve added everything you actually need.
Third, compliance posture. What audit artifact do you need to produce? For unregulated teams, an auto-generated postmortem is fine. For financial services, healthcare, telecom, and anyone with regulatory reporting or vendor risk review obligations, you need a structured, timestamped, defensible record of every alert, every escalation, and every responder action. Agent Chronicle in AlertOps generates this as an automated postmortem with the full audit trail attached. Most incident response tools don’t produce this class of artifact as a standard output.
Walk through those three before you start shortlisting vendors. The list narrows on its own.
How much time you actually have
Less than it feels like.
The deadline sounds far away. It isn’t. Enterprise migrations of this scope rarely take less than six months from decision to clean cutover, and a lot take twelve to eighteen. If you’re starting evaluation in the second half of 2026, you’re already inside a compressed window.
There’s also a second deadline that nobody puts on slides: your renewal date. For most teams, the Opsgenie renewal lands before April 2027, and that renewal is the actual forcing function. One Fortune 500 operations team was timing the math during their evaluation: “we’re looking at the end of July. I know that, Danny, we’ve got a renewal in September. Is that right with OpsGenie?” September was the cutover date that mattered, not April 2027. (If your renewal is coming up, we wrote a separate piece on how the EOS timeline actually plays out.)
Waiting costs you in three ways. Negotiating leverage with destination vendors drops as the deadline gets closer. Migration risk goes up because cutover windows compress. And you’re running production response on a deprecating platform with declining support quality the whole time. Starting now buys back the leverage that the deadline will otherwise take from you.
What it actually costs
The number people check first is per-seat pricing. That’s also the number that tells you the least.
Five-year cost depends on which modules you actually end up adding. JSM looks cheap until you price the responders who aren’t Jira users at agent rates; Rootly and incident.io look cheap until you add on-call; PagerDuty looks cheap until you add AIOps. The cheapest sticker on the shortlist usually isn’t the cheapest contract.
The bigger cost is downtime. IBM’s Cost of a Data Breach Report puts the average breach at $4.44 million globally and $10.22 million in the United States, with average savings of $2.66 million when an organization has a tested incident response plan plus AI automation in place. A 25 to 35% MTTR reduction (the range AlertOps deployments produce, along with up to 68% noise reduction through OpsIQ) isn’t a UX win. It changes the breach math by enough to make the per-seat comparison feel small.
The last cost is the one that doesn’t make it onto anyone’s spreadsheet until they’re already inside it: picking wrong the first time. Eighteen months running a platform that doesn’t fit, then doing the whole migration again. That’s the first migration, plus the second migration, plus the operational drag in between. It’s the biggest financial decision in this entire process.
Where AlertOps fits
If your evaluation points at orchestration, this is what we do.
OpsIQ correlates signals from observability before they reach a responder. The engine uses similarity modeling, NLP, and configurable thresholds tuned to your environment. AlertOps platform data shows up to 68% noise reduction in enterprise deployments. Agent Chronicle generates the automated postmortem and the audit trail underneath, which is the artifact regulated industries need. Multi-channel response runs across Slack, Microsoft Teams, email, SMS, phone, and mobile through one policy engine. ServiceNow and Jira integrate bidirectionally, not as one-way webhooks.
Three things about how we sell it that matter at enterprise scale. AlertOps Enterprise bundles responsive support and AI capability. We ship continuously as an independent company, which means the roadmap is driven by what customers ask for rather than what fits a parent organization’s portfolio strategy.
The Opsgenie migration is included with the plan, run by our Solution Engineering team. We replicate your schedules, escalation rules, and integrations, validate alert routing and incident grouping while both platforms run in parallel, then cut you over cleanly. We’ve done this for hundreds of teams in the last year. It’s not a self-serve tool. It’s an assisted program, which is how it works at scale.
Book a demo at alertops.com/demo and we can walk through what your specific migration looks like.
What to do next
Atlassian made the decision for you. The only question left is whether you pick the destination on purpose, with twelve months to evaluate properly, or you take whatever the late-stage market offers because the deadline got there first.
The good news is you still have runway. Most teams won’t get another shot at a five-year platform decision for a long time. Use the time you have to pick on architecture and commercial fit, not on whichever vendor email landed first.
Frequently asked questions about Opsgenie end-of-life
Is Opsgenie really being discontinued?
Yes. Atlassian ended new Opsgenie sales on June 4, 2025. Full support ends April 5, 2027. Existing customers retain access through their current renewal cycles, but every Opsgenie tenant has to be off the platform by the support cutoff, either onto JSM Operations or onto a third-party platform.
What is replacing Opsgenie?
Atlassian’s recommended replacement is Jira Service Management Operations. Most enterprise teams also evaluate dedicated alternatives like AlertOps, PagerDuty, incident.io, and Rootly, because JSM Ops carries different per-seat economics, gates advanced operations capability behind the Premium tier, and isn’t architected as a standalone incident orchestration platform.
Is Atlassian still supporting Opsgenie?
Through the deprecation window, yes. Existing renewals are honored, the API continues to function, and support tickets are answered. What has stopped is feature investment, marketplace integration expansion, and dedicated Opsgenie roadmap development. Support quality degrades across the deprecation window as resources move toward JSM Operations.
How long do I have to migrate from Opsgenie?
The hard deadline is April 5, 2027. Enterprise migrations of this scope take six to eighteen months from decision to cutover. If you haven’t started evaluation by mid-2026, you’re inside a compressed timeline.
Will my Opsgenie integrations keep working during the migration window?
Existing integrations continue to function through the deprecation period. New integration development by marketplace partners has slowed as they move engineering attention to JSM Ops or alternative platforms. Custom integrations built against the Opsgenie API will work until the API shuts down on the published schedule.
Is JSM Operations a 1:1 replacement for Opsgenie?
No. JSM Operations absorbs Opsgenie’s on-call and alerting capabilities into the JSM product surface, with different pricing, a different data model (incidents as ticket types), and a different architectural assumption (the responder team is also the Jira-using engineering team). Advanced operations capability gates at the Premium tier (about $48 per agent per month). For teams whose responder population extends beyond Jira users, or whose ITSM standard is ServiceNow, JSM Operations isn’t the architectural fit.
What is the difference between an incident response tool and an incident orchestration platform?
Incident response tools coordinate the human workflow after an alert becomes an incident: chat channels, role assignments, status pages, post-incident retros. Incident orchestration platforms sit upstream and across the stack, ingesting signals from observability, correlating and suppressing alert noise, routing through multi-dimensional policies, coordinating multi-channel response, and integrating bidirectionally with ITSM. AlertOps is built at the orchestration layer.
Does AlertOps offer a free migration from Opsgenie?
Yes. The Opsgenie migration is included in AlertOps Enterprise as an assisted Solution Engineering engagement. We replicate your schedules, escalation rules, and integrations, validate alert routing and incident grouping in parallel, then cut you over cleanly.
