The Opsgenie migration moves your schedules. It does not move your integrations.

Atlassian's automated migration takes across schedules, escalation policies and incident workflows. Everything else in this page is the part it leaves behind — and the part teams find out about at 3am on the far side of cutover, not before it.

The dates that make this urgent

• End of sale: 2025-06-04.
• End of support: 2027-04-05. After that there is no supported Opsgenie to fall back to.

The deadline is the easy part. The hard part is that the migration reports success while a meaningful share of your alerting path is quietly not there any more.

What is actually lost, and where that comes from

Two source classes, and this page never blurs them. Atlassian's own docs are authoritative. Community reports from community.atlassian.com are real, dated and linked — but not vendor-confirmed, and they are labelled as such every single time they appear.

From Atlassian's published docs

• Chat integrations are not automatically migrated. Slack, Microsoft Teams and other ChatOps connections must be re-authenticated — and Slack integrations for Incidents do not sync with Jira Service Management at all.
• GitLab will not be auto-synced.
• OEC must be reconfigured as JEC. Every Opsgenie Edge Connector action script has to be ported to the Jira Edge Connector and re-tested. This is the most under-estimated line item on most migration plans.
• Heartbeats need manual updating, and Heartbeats V1 is being phased out.
• Global notification policies need manual conversion; Policies V1 is being phased out.
• API Key Management is replaced by Atlassian Authentication — every script and integration authenticating with an Opsgenie API key needs new credentials.
• Groups are replaced by teams.
• Incident Command Center is deprecated — there is nothing to migrate it into.
• MSP Opsgenie-to-Opsgenie routing is no longer supported.
• Turning Opsgenie off removes access to all unsynced data, including unsynced alerts, on-call schedules and integrations.

The plan trap

Opsgenie Standard maps to JSM Premium. Choosing Standard to control the cost increase is a pricing decision that silently removes features:

• Bidirectional integrations are Premium and Enterprise only.
• Users migrating to Free and Standard may lose the outgoing part of their integrations.
• Stakeholders are not migrated to Standard or Free.

Reported by users, not confirmed by Atlassian

• Historic incidents and postmortems were not migrated — reported 2024-10-22, and the thread sat at zero answers.
• All Zabbix integrations for all teams stopped working after a migration — webhooks had to be repointed through JEC, and the available docs addressed Opsgenie rather than Operations.
• Alerts reached Opsgenie but never reached Teams for roughly two weeks in August 2026 — "Application with identifier ... was not found in the directory". The eventual fix was updating the Opsgenie app in Teams and clearing the Teams cache.

Check your own setup

Zero dependencies. It never asks for, stores or transmits a credential — you produce the export yourself, with your own key, in your own shell, and nothing leaves your machine.

curl -H "Authorization: GenieKey $OPSGENIE_KEY" \
     https://api.opsgenie.com/v2/integrations > integrations.json

node check.js integrations.json --plan standard
node check.js --demo          # see the shape of the answer with no data at all

The part nobody checks

Every team plans the cutover. Almost nobody verifies delivery afterwards — they confirm the integration row exists in the new console and call it migrated. That is the same mistake as trusting a health endpoint: a green status proves the thing is running, never that it is still delivering. The August 2026 Teams case is exactly this shape — Opsgenie had the alerts, the integration looked configured, and the on-call phone stayed silent for two weeks.

After cutover, fire a real event through every path and prove a human received it. That is the acceptance test, and it is the one usually skipped.

Get the code

If you would rather not do it yourself

We take this on as fixed scope, and we will say plainly that you would be our first customer for this particular engagement — what we are bringing is the breakage map above and a hard discipline about proving delivery rather than assuming it.

• Pre-cutover breakage audit — $900 fixed. We run the checker against your real export, and hand back a per-integration rebuild plan with owners and effort, plus the account-level items that apply to your target plan.
• Rebuild and verification — $6,000–10,000 fixed, two weeks. We port the OEC actions to JEC, re-create what does not migrate, and build the post-cutover verification suite that fires a real event through every alerting path and proves it arrived on a human's phone. Delivery, not liveness.