On September 18, Atlassian published the kind of postmortem that makes the Opsgenie end-of-life deadline feel a lot more daunting.
On September 14, Opsgenie, Jira Service Management, and Compass hit a disruption that left affected customers waiting an average of 22 minutes for alerts to be created and notifications delivered. Nothing was ultimately dropped. That sounds reassuring until you picture what 22 minutes means during a payment failure, contact center outage, or broken customer login.
Atlassian traced it to long-running transactions after a configuration change, with heavier US traffic exhausting a core service's thread pool. Automated monitoring caught the problem within a minute, yet alert and notification delivery still averaged a 22-minute delay.
Plenty of CX leaders spend a lot of time talking about detection. The nastier question is what happens after the signal exists and the people who need it still don't get enough information quickly enough.
The timing makes this especially awkward. On April 5, 2027, Opsgenie becomes inaccessible. Atlassian's wording is blunt:
“access to Opsgenie will be shut off”, with unmigrated data deleted.
So, as the six-month countdown begins, Opsgenie migration decisions have suddenly become part of a much bigger argument about CX observability on-call management in 2026: who owns the chain from “something broke” to “someone actually fixed it”?
What Happens to Opsgenie After April 5, 2027?
You’ve got until April 5, 2027. Atlassian says Opsgenie access will be shut off on that date, with unmigrated data deleted afterward. New sales already ended on June 4, 2025. Current customers can add more seats, although renewals can’t extend beyond end of life.
There’s another data issue worth mentioning. Opsgenie Enterprise allowed alert data to be retained indefinitely. After an Opsgenie migration, new JSM alert data expires according to plan: one month on Free, one year on Standard, three years on Premium, and five years on Enterprise. Atlassian specifically calls out investigations, compliance audits, reporting, and AI analysis as reasons customers may need that history. Once expired, it can’t be recovered.
That makes what happens to Opsgenie data after April 2027 a bigger question than “did the records transfer?” A company could move successfully and still discover later that the history its auditors or AI tools expected to use has aged out.
Six months is enough time to fix that. It’s also close enough that leaving the retention conversation until cutover feels reckless.
What Are the Opsgenie Migration Options Before April 2027?
For most customers staying with Atlassian, the Opsgenie migration route is now straightforward on paper: move into Jira Service Management using Atlassian’s automated migration tool. Alerts, schedules, and policies transfer automatically, and Atlassian recommends a JSM plan based on the customer’s existing Opsgenie setup.
There’s a sensible safety net for those worried about ongoing service management and connectivity. Customers can run a 14-day migration demo first, then keep Opsgenie available for 120 days in parallel after the move. That’s a good window to use for a live proving period, especially for teams with messy escalation chains or lots of custom integrations.
Still, there is a second deadline hidden in that safety net. Opsgenie shuts down automatically 120 days after the migration date unless a site admin turns it off sooner. Atlassian says that shutdown is permanent, so those 120 days are validation time, not spare capacity.
The big complication is Data Center. Atlassian’s current tooling doesn’t move Opsgenie data into Jira Service Management Data Center. Customers staying on JSM DC can’t bring that Opsgenie estate into the same environment; Atlassian’s answer is effectively Cloud.
That gives extra clout to Jimi Wikman’s earlier warning that “there does not seem to be a plan” for Data Center users. Atlassian has since clarified the path, but it still isn’t a like-for-like DC destination.
Is Jira Service Management a Full Replacement for Opsgenie?
For core alerting and on-call work, Jira Service Management covers most of what Opsgenie users need. The complications sit around those core functions.
Alerts and schedules migrate, but some familiar behavior changes. Slack incident integrations need rebuilding, Terraform users move to Atlassian’s Operations provider, and push notifications shift to Jira’s mobile app. Slack and Microsoft Teams connections also need reauthorizing, while bidirectional integrations require Premium or Enterprise. Around 24 older integration versions can’t be newly configured in JSM.
Notification rules need copying into Jira’s mobile app, where insistent notifications aren’t available. JSM Operations alerts don’t automatically become incidents either, so that workflow requires automation.
There are incident-migration gaps too. Atlassian says incident templates and responder roles don’t migrate. Stakeholder filters need manual handling, email templates must be rebuilt, and Opsgenie actions and incident rules need recreating in Jira Automation. Opsgenie SSO also doesn’t carry over, with Atlassian Guard required separately.
Atlassian is investing heavily in the destination. New circuit breakers are designed to keep alert creation, notifications, and on-call schedules running when search is degraded, while RovoOps is moving into Slack incident and alert channels.
Still, JSM needs pressure-testing. On October 1, an incident delayed email-to-ticket processing and notifications, disrupted schedules, and left some new support tickets without SLA components before recovery later that morning.