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
We hear this question constantly: Why are so many enterprise teams ditching Atlassian’s JSM Operations?
The answer usually isn’t that JSM is bad it’s that enterprise teams have fundamentally different needs than what JSM was built to solve. Here are the four reasons we hear most.
First: The Responder Pool Problem
Here’s the math that keeps coming up during evaluations.
JSM agent seats are priced for your engineering team. But on-call platforms need more than that. Your operators, vendor contacts, on-call rotations, stakeholders who never touch a ticket they all need seats too.
At JSM agent pricing ($20-$48/month per seat), that bill grows fast.
We talked to a Fortune 500 platform ops lead mid-evaluation: “We’re still on OpsGenie, which is going away. So we’re looking at alternatives. Of course, Atlassian really wants us to convert.”
She ran the numbers. The responder pool costs made JSM a non-starter. Her team moved on.
Second: You’re Running Two Systems
A lot of enterprise teams already have ServiceNow. It’s their system of record.
JSM also wants to be the system of record.
When your on-call platform lives inside JSM and your ITSM lives in ServiceNow, you end up maintaining both, reconciling data between them, and managing duplicate processes. That’s not a solution that’s extra work.
One Footlocker-scale operations lead put it this way: “Our ServiceNow team told us ServiceNow does all that on-call stuff anyway.”
And there it ends.
Third: The Data Model Mismatch
JSM treats incidents as ticket types. That works fine for service requests.
But mature incident orchestration isn’t architected that way. A real incident is a structured object that carries:
- Correlation context
- Channel preferences
- Escalation state
- Audit history
None of this fits cleanly inside a ticket type. The mismatch creates friction every time you need advanced incident features.
Fourth: Enterprise Features Cost Extra
Basic on-call lives in JSM Standard (about $20/agent/month annually).
The features your enterprise team actually needs advanced alert integrations, incident investigation, major incident management, CMDB integration live in JSM Premium (about $48/agent/month).
When you multiply that across a responder pool of 50+ people, the per-agent cost frequently pushes your total cost of ownership past purpose-built alternatives that do more.
The Bottom Line
JSM is a solid service management platform. It does what it was built for, really well.
But JSM Operations isn’t Opsgenie 2.0. For most of the post-Opsgenie market especially enterprise teams it solves the wrong problem.
Want to see how enterprise incident orchestration should actually work?
Schedule a personalized AlertOps demo and see how our AI-powered platform reduces alert noise, automates escalations, and speeds up incident resolution.
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.
