Atlassian has confirmed that Opsgenie will reach end-of-life in April 2027. New signups are already blocked, and existing customers are being guided toward Jira Service Management (JSM) Cloud as the replacement. If your team relies on Opsgenie for on-call scheduling, alert routing, or escalation policies, you have roughly ten months to plan and execute a migration.
This article covers what's happening, why, and what your options look like.
What happened
Atlassian announced that Opsgenie — acquired in 2018 as a standalone incident alerting and on-call product — will be fully deprecated. The core capabilities (alert routing, on-call schedules, escalation policies, and incident timelines) have been rebuilt inside Jira Service Management Cloud, and Atlassian no longer sees a reason to maintain a separate product.
Existing Opsgenie customers received migration notices starting in early 2026. The Opsgenie web console now displays a banner pointing to migration documentation, and the API will continue functioning until the shutdown date — but no new features will ship.
Timeline
| Date | Event |
|---|---|
| Q1 2026 | New Opsgenie signups blocked |
| Q2 2026 | Migration tooling available in JSM |
| April 2027 | Opsgenie reaches end-of-life — APIs, web console, and mobile app stop functioning |
Atlassian is providing roughly 12–14 months of overlap between the announcement and the hard cutoff. That sounds generous, but migrations that involve on-call schedules, hundreds of integrations, and team-specific escalation logic rarely go smoothly in a single sprint.
Why Atlassian is doing this
The strategic logic is straightforward: Atlassian wants one incident management surface, not two. Maintaining a standalone product that overlaps with JSM's built-in incident features creates engineering duplication, confuses the sales motion, and splits the user base.
JSM Cloud now includes:
- Alert routing and deduplication (ported from Opsgenie's engine)
- On-call scheduling with rotation rules
- Escalation policies with multi-channel notification
- Incident timelines and postmortem workflows
- A mobile app for on-call acknowledgment
For teams already paying for JSM, this consolidation removes a separate line item. For teams that used Opsgenie standalone (without Jira), it forces a platform decision.
What changes for existing users
If you do nothing, your on-call system stops working in April 2027. Specifically:
Integrations break. Every monitoring tool, CI pipeline, or custom webhook that currently POSTs to Opsgenie's API will need a new destination. If you route alerts from Datadog, Prometheus, Grafana, CloudWatch, or any other source through Opsgenie, those integrations require rewiring.
On-call schedules need recreation. While Atlassian provides migration tooling, the schedule model in JSM differs from Opsgenie's. Complex rotations with overrides, restrictions, and multi-team handoffs may not map 1:1.
Mobile app changes. The Opsgenie mobile app will stop receiving alerts after shutdown. JSM uses the Jira Cloud mobile app (or the Jira Ops companion app) for on-call notifications.
Data export. Atlassian provides export tooling for historical alert and incident data. If you need audit trails or postmortem archives, export before the cutoff.
Migration options
You have three paths, and the right one depends on your existing Atlassian footprint.
Option A: Move to JSM Cloud
This is the path of least resistance if your team already uses Jira for ticketing. The migration tooling handles:
- On-call schedules and rotations
- Escalation policies
- Integration configurations (partial — some require manual reconnection)
- Team structures
Considerations: JSM pricing is per-agent, which can be significantly more expensive than Opsgenie's per-user model for large teams. JSM also requires Jira Cloud — if you're on Jira Server or Data Center, this migration includes a platform migration too.
Option B: Evaluate alternatives
If you were already unhappy with Opsgenie — pricing, mobile app reliability, or integration depth — this is a natural breakpoint to evaluate the market. The on-call and alerting alternatives space has matured since 2018, with several strong options in PagerDuty, Rootly, incident.io, Grafana OnCall, and others.
When this makes sense: your team doesn't use Jira, you want to avoid JSM's per-agent pricing, or you need capabilities Opsgenie never had (AI-powered triage, native Slack workflows, or deeper runbook automation).
Option C: Hybrid migration
Some teams separate concerns: move on-call scheduling to a dedicated tool while keeping Jira for ticket tracking and postmortems. This avoids JSM lock-in for the real-time alerting path while preserving the Jira integration for retrospective workflows.
Timeline recommendations
Regardless of which path you choose:
- Now (Q2 2026): Audit your current Opsgenie configuration. Document every integration, escalation policy, and schedule. Identify which are actively used vs. legacy.
- Q3 2026: Run a proof-of-concept migration in a staging environment. Test alert routing, escalation timing, and mobile notifications.
- Q4 2026: Execute production migration with a parallel-run period. Keep Opsgenie active as a fallback while validating the new system handles real incidents correctly.
- Q1 2027: Decommission Opsgenie integrations and export historical data.
What to evaluate in any migration
Whether you're moving to JSM or a third-party tool, these are the dimensions that matter for on-call rotation setup:
On-call scheduling flexibility. Can you model your actual rotation? Multi-team handoffs, timezone-aware shifts, holiday overrides, temporary swaps. Simple round-robin is table stakes — the complexity lives in the exceptions.
Escalation policies. How many escalation layers? Can you escalate to a different team after N minutes? Do escalations respect business hours vs. 24/7? Can you route by incident severity level?
Integration breadth. Count your current Opsgenie integrations. Verify that the destination tool supports each one natively or via webhook. Pay special attention to bidirectional integrations (where the on-call tool writes back to the source).
Pricing model. Opsgenie charged per-user with a generous free tier. JSM charges per-agent. PagerDuty charges per-user with add-on costs. Some newer tools offer flat-rate pricing. Model your actual team size and growth.
Mobile experience. On-call is a mobile-first workflow. Test the actual notification reliability, acknowledgment flow, and override UX on both iOS and Android. Unreliable push notifications during an outage are worse than no tool at all.
Start planning now
Ten months feels like plenty of time until you factor in procurement cycles, security reviews, integration testing, and the reality that on-call migrations can only be validated during actual incidents. Teams that start evaluating in Q2 2026 will have time for a proper parallel-run period. Teams that wait until Q1 2027 will be scrambling.
Document your current state, pick a direction, and get a proof-of-concept running before summer ends.
For the monitoring and alerting layer that feeds your on-call tool — multi-region checks, notification policies, and a status page — start at app.devhelm.io.
Originally published on DevHelm.
Top comments (0)