What to do when Opsgenie sunsets in 2027

TL;DR: Atlassian is sunsetting Opsgenie in 2027. Engineering teams have three options: move to JSM, swap in a like-for-like paging tool, or use this as a forcing function to fix their entire incident response workflow. Which path is right depends on how much of your current setup is actually working — and most teams, when they're honest about it, have more to fix than just the pager.

What is happening to Opsgenie?

Atlassian is officially discontinuing Opsgenie in 2027. Every team currently running on Opsgenie will need to migrate to a new solution before that date. This isn't a gradual wind-down with parallel support — it's a hard end-of-life, which means the disruption is coming whether you plan for it or not.

Why the Opsgenie sunset matters more than most teams realize

Most engineering teams don't change their paging systems unless they're forced to — and for good reason. The disruption, the retraining, the trust your on-call engineers need to rebuild in a new system before they'll rely on it during a 2 AM incident: the migration cost is genuinely high.

That also means that when teams do switch, they tend to stick with whatever they land on for five or more years. The choice you make in response to the Opsgenie sunset will likely shape how your team manages incidents for a long time. It's worth more thought than most teams are giving it.

There's also something worth naming directly: change is now inevitable, regardless of what you decide. Every team on Opsgenie is getting disrupted. The only question is whether you minimize that disruption or use it to also fix the things that haven't been working.

What are my options when migrating from Opsgenie?

There are three realistic paths forward. Most teams land on one of them within the first few days of evaluating.

Option 1: Migrate to Jira Service Management (JSM)

This is the path of least resistance for teams already embedded in the Atlassian ecosystem — one vendor, a familiar login, consolidated tooling. For IT teams managing service desk workflows, it can make sense.

For engineering teams, the fit is weaker. JSM is a ticketing system. It wasn't designed for the real-time, high-pressure nature of incident response: rapid human coordination, live communication, getting context to responders fast. Engineers managing a SEV0 at 2 AM don't want to navigate a ticketing interface.

There's also a subtler risk: if you've been running Opsgenie for a few years, you almost certainly have technical debt baked in — alert rules set up and forgotten, escalation policies that no longer reflect your team structure, monitors that fire constantly but mean nothing. Migrating to JSM doesn't force any of that to change. You bring the debt with you, rebrand it, and end up in the same place with a different UI.

Option 2: Lift and shift to a new paging tool

Find something that works like Opsgenie, import your schedules and escalation policies, train your team, and move on. Low disruption, minimal change management required.

This has real appeal, especially under time pressure or with limited internal bandwidth. But it carries the same underlying risk as Option 1: you're solving the paging problem without touching the broader incident response workflow. Paging is roughly 10% of what happens when an incident occurs. The other 90% — triage, communication, coordination, learning — stays exactly as it is.

Option 3: Use this as a forcing function to fix the whole system

Instead of asking "what does the same thing as Opsgenie?" you zoom out and ask: "What does our entire incident response workflow look like end-to-end, and where are the real pain points?"

If paging is working fine, but everything after the page is messy — slow communication, scattered context, postmortems that never get done — a pager swap won't help. This option requires more upfront work, but delivers more value over time. It's also the only option that actually makes the migration worth something.

How do I know which migration path is right for my team?

The honest way to figure this out is to assess your current state before you evaluate any vendor. Here are the questions to work through:

About your on-call program:

• Is it growing in complexity without scaling?
• Is internal or external communication during incidents consistently poor?
• Are you learning from incidents, or just surviving them?
• Is everything manual, and is it cutting into your SLAs?

About your broader tooling:

• Are your alerting, paging, incident tracking, status pages, and communications running on separate disconnected systems?
• Is engineering time going toward maintaining the glue code between those systems rather than building your product?

About what your on-call engineers are actually saying:

• Too much noise, not enough signal?
• No clear ownership?
• No feedback loop that leads to fewer pages over time?
• A small group of knowledge experts holding the pager and burning out?

About what your managers are struggling with:

• No visibility into how much time the team spends on reactive work?
• Difficulty managing schedules, PTO, and holidays?
• Too much configuration overhead just to maintain coverage?

If several of these land, a like-for-like swap is unlikely to move the needle. The disruption cost is roughly the same either way — so you may as well use it to fix something.

What happens if I don't deal with Opsgenie technical debt before migrating?

This is one of the most underestimated risks in any paging migration. After a few years in any system, teams accumulate configurations that nobody owns — monitors that nobody reviews, alert rules set up by people who have long since left the company. If you've grown, reorganized, or moved to a more distributed engineering model, your Opsgenie setup likely reflects how your team was structured two or three years ago, not today.

You might have alerts routing to the wrong team, escalation paths pointing to former employees, and monitors configured so broadly that almost everything triggers them.

The migration is the opportunity to deal with this. Audit before you migrate. Cut aggressively. Only carry over what actually needs to exist.

When should I start planning my Opsgenie migration?

The Opsgenie end-of-life is 2027, which sounds like a lot of runway. For smaller teams, it may be. But there are two earlier forcing functions worth knowing about:

Your Opsgenie contract renewal. If your contract renews before 2027, that renewal is a natural decision point. You may not want to pay for another year if you're planning to leave anyway.

Your team size. If you have more than a few hundred users to migrate, start planning now, even if execution is months away. The planning phase — taking inventory, aligning stakeholders, deciding what you want to build — is not trivial. Doing it under pressure leads to shortcuts that create the same technical debt you were trying to clear.

A reasonable rule: if you have more than a few hundred users, don't wait.

What does a good Opsgenie migration actually look like?

If you're going with the full-system upgrade (Option 3), here's what you're signing up for — and why it's worth it:

Instead of migrating alert rules as-is, you do an audit, cut the noise, and build a routing and response model based on actual code and service ownership. You increase signal, reduce burnout, and set yourself up for scalability.

Instead of recreating escalation policies, you rationalize them. Fewer paths, clearer ownership, less configuration overhead.

Instead of just switching where pages come from, you connect paging to the rest of your incident workflow — so that when someone gets paged, the context, the communication channel, and the automated stakeholder updates are already there. Responders can focus on fixing rather than on process.

Instead of finding another alerting solution, you invest in an end-to-end platform that:

• Gives your business a holistic view of incident lifecycles — so incidents become a mechanism for improvement, not just fires to fight
• Gives managers visibility into how much time their engineers are actually spending on reactive work
• Gives incident commanders AI assistance during an incident, speeding up investigation, mitigation, and post-incident learning
• Gives leadership the confidence that they'll never have to ask "what's going on?" or "what happened?" or "how are we improving?"

The outcome isn't a migration that's done. It's a team that spends less time on reactive work, has better visibility into incidents, can build a feedback loop that makes future incidents shorter and less frequent, and ships a more resilient product as a result.

Where do I start with my Opsgenie migration?

If you're ready to plan: Start with an on-call migration best practices guide to structure your planning. incident.io has one you can use directly.

If you're still deciding: The first step isn't evaluating vendors — it's getting honest about your current state. Pull your list of schedules, escalation policies, and teams out of Opsgenie. Find out who owns what. Look at your alert volume from your monitoring sources and your acceptance rate. Understand where the manual work actually lives in your incident workflow.

That inventory will tell you more about which path is right for you than any product demo.

If you want to talk through what this looks like for your specific team — given your timeline, your size, and your current setup — reach out to us here.

Frequently asked questions about the Opsgenie sunset

When is Opsgenie shutting down? Atlassian is sunsetting Opsgenie in 2027. All Opsgenie customers will need to migrate to a new solution before the end-of-life date.

What is the best Opsgenie replacement for engineering teams? It depends on your current state. If paging is your only problem, a like-for-like alerting tool may be enough. If your broader incident response workflow is fragmented — slow communication, scattered context, no post-incident learning — a full incident management platform will deliver significantly more value.

Should I migrate from Opsgenie to JSM? JSM can work for IT and service desk teams embedded in the Atlassian ecosystem. For software engineering teams, JSM's ticketing-centric design is a poor fit for real-time incident response. You also risk migrating existing technical debt with no forcing function to clean it up.

How long does an Opsgenie migration take? For small teams (under 100 users), a focused migration can happen in weeks. For larger organizations with hundreds of users across multiple teams, you should plan for several months — especially if you include an audit and cleanup phase before migration.

What is the biggest mistake teams make when migrating from Opsgenie? Migrating technical debt. Most teams in Opsgenie have alert rules nobody owns, escalation policies pointing to former employees, and monitors configured so broadly that everything triggers them. Doing an audit before migration — and cutting aggressively — is the single most valuable thing you can do before you move.

Does incident.io replace Opsgenie? Yes. incident.io offers on-call scheduling, alerting, escalation policies, and the full incident response workflow in a single platform. Teams migrating from Opsgenie can run both systems in parallel during transition to ensure continuous coverage.

Eryn Carman is a Strategic Customer Success Manager at incident.io. She has spent the last two years helping engineering teams plan and execute migrations from legacy on-call systems, working with companies ranging from a few hundred to tens of thousands of users.