Atlassian will delete unmigrated Opsgenie data when the service shuts down in April 2027

Atlassian will shut down Opsgenie, its on-call alerting service, on April 5, 2027, and will delete any data that has not been migrated by that date. A migration guide published on dev.to, cross-posted from the Fluidify blog, walks teams through the exit and warns that even Atlassian's automated path to Jira Service Management leaves a notable amount of configuration behind.

The guide frames the work as five phases — inventory, export, rebuild, parallel run and cutover — and argues that the genuinely slow parts are custom routing, automation and integrations built around Opsgenie's payload format, not the on-call schedules themselves.

What the automated Jira move leaves behind

According to Atlassian's migration page, as described in the guide, the automated move syncs Opsgenie data into Jira Service Management on a date the customer schedules, preceded by a 14-day demo migration and followed by 120 days of parallel Opsgenie access.

But the guide, citing Atlassian, lists what does not transfer: Slack and Microsoft Teams integrations must be reconnected and reauthenticated manually; action policies are not carried over and have to be rebuilt as Jira Automation rules; bidirectional integrations only function on JSM Premium or Enterprise, so teams on Free or Standard lose the outgoing direction; roughly two dozen outdated integration versions can be moved but cannot be created anew in JSM; older heartbeats without an assigned team stay behind; and custom Opsgenie roles may be downgraded to JSM's standard User role.

History is another soft spot. One Atlassian community thread cited in the guide reports that incidents and postmortems failed to transfer in a JSM migration even though alerts and rotations did, so the guide recommends exporting anything needed for compliance or postmortem records rather than assuming the tool covers it.

A shrinking overlap window

Because parallel access cannot run past the April 5, 2027 shutdown, the guide's author calculates that migrations scheduled after December 6, 2026 will receive a shorter overlap than the advertised 120 days. The author is explicit that Atlassian does not publish this figure, and advises teams to request their exact end date when booking the migration.

Five phases, and the slow ones are not the schedules

Inventory comes first: teams and custom roles, schedules with their rotations and active overrides, escalation policies, team routing rules, integrations and their API keys, heartbeats, and every script or Terraform workspace that calls the Opsgenie API — the guide suggests searching repositories for api.opsgenie.com and GenieKey. Each object should be marked to keep, rebuild, or retire.

Export follows, independently of any automated migration. Schedules can be pulled as iCalendar files, but those contain the resulting shifts rather than the rotation rules, so the guide advises also fetching the schedule definitions as JSON via the API, along with alert and incident history and full configuration as a reference for rebuilding.

The rebuild is where most of the effort goes: chat integrations, automation rewritten for the destination, advanced escalation recipients such as 'next or previous on-call user' — an Opsgenie Standard and Enterprise feature that may need simplifying elsewhere — and any integration built against Opsgenie's exact JSON shape or object IDs.

For teams not staying with Atlassian, the guide names PagerDuty, incident.io, Grafana Cloud IRM and self-hosted open-source options as destinations. Most competitors offer some kind of Opsgenie importer, but what each one reads varies considerably, so the guide suggests asking vendors for an exact list of imported objects and testing the importer against a copy of your setup before signing anything.

Parallel run before cutover

The guide's safety net is running both systems at once. Start by pointing one low-risk alert source, such as staging or an internal tool, at the new system while Opsgenie keeps receiving, and verify the full path: the alert arrives, routes to the right team, escalates on the right delay, and reaches the right person on the right channel. Then add production sources one at a time, keep both running for at least one full on-call rotation, and watch for handoffs at awkward hours, overrides that did not survive the move, and escalation timeouts that differ. Engineers also need clarity on which system is authoritative during the overlap, so an alert acknowledged in one is not ignored in the other.

Why it matters

Opsgenie is the layer that pages people when production breaks, so a migration that drops a routing rule or an escalation path fails silently until an incident exposes it. The deadline is unforgiving: unmigrated data is deleted in April 2027, which rules out leaving a dormant account behind as a fallback. And the automated Jira migration, while real, is narrower than its name suggests — chat integrations, action policies, bidirectional sync and role mappings all require manual work. The guide's practical message is to treat the shutdown as a project with a scheduled parallel run, not a one-click transfer, and to start early enough that a full rotation cycle can catch what the checklist missed.