Opsgenie Migration Guide (2026): How to Export Your Data Before Deletion, and What JSM Does and Doesn't Carry

If you are still on Opsgenie, this Opsgenie migration guide exists because the clock is now the whole story. On 5 April 2027, Atlassian shuts Opsgenie off and deletes any data that has not been migrated. That is not a soft deadline with a grace period afterwards. When it passes, your schedules, escalation policies, alert history and integration configuration are gone.

Most guides treat this as one decision: move to Jira Service Management, run the assistant, done. For an MSP it is really two decisions, and they are separate. First, where you land. Second, and more urgently, what you rescue before deletion regardless of where you land. This guide covers the mechanics of both: how to export everything Opsgenie holds, exactly what the JSM migration assistant carries and quietly leaves behind, the one MSP-specific feature that does not survive at all, and the iCal path if you decide to move somewhere other than Atlassian.

For the strategic picture, the timeline and why MSPs face a harder migration than SaaS teams, start with our Opsgenie shutdown guide for MSPs. This post is the hands-on companion: the actual steps.

The three dates that govern your migration

Two of these have already passed. The third is the one that deletes your data. And there is a fourth window, the parallel-access period, that most people do not realise starts the day they run the assistant, not the day Opsgenie shuts down.

The verbatim line from Atlassian's pricing page is that "Opsgenie's alerting and on-call features are now available in Jira Service Management," and that any un-migrated data is deleted at end of support. The 120-day figure matters for planning: once you kick off the JSM migration, you keep read access to Opsgenie for 120 days to validate the new setup before the old one goes away. You can turn Opsgenie off sooner when you are confident. What you cannot do is get anything back after 5 April 2027.

Step 1: Export everything while you still can

Do this first, before you touch the migration assistant and before you have settled on a destination. The goal is a complete, portable archive of your Opsgenie configuration and history that does not depend on Atlassian keeping anything alive.

On-call schedules

Every Opsgenie schedule can be exported as an iCal (.ics) feed. This is the single most portable artefact you have, because iCal is a standard calendar format that most on-call tools can import directly. Pull the iCal URL for each schedule from its settings and save the exported files. If you are moving to a tool that supports iCal import, these become your starting rotations on day one rather than something you rebuild by hand.

Escalation policies and routing rules

This is the part MSPs cannot afford to lose. Document every escalation policy and routing rule: which client, which severity, who gets paged first, the wait before it escalates, and the fallback. Opsgenie exposes most configuration objects through its API, so you can pull policies and routing rules as JSON. If you would rather not script it, screenshot every policy. It is tedious and it is also the difference between rebuilding from a reference and rebuilding from memory at 2am.

Integration inventory

List every integration wired into Opsgenie: RMM tools, monitoring, your PSA, and any custom webhooks or middleware. For each one, note what it sends in and what Opsgenie does with it, especially anything that creates or updates a PSA ticket. You will rebuild these connections in whatever you migrate to, and the inventory is your checklist for verifying nothing was silently dropped.

Alert and incident history

Historical alert and incident data can be exported through Opsgenie's reporting API. MSPs often need this for after-hours billing reconciliation, SLA disputes and compliance evidence long after the tool itself is gone. Archive it to storage you control. Once 5 April 2027 passes, this data does not exist anywhere.

Step 2: What the JSM migration assistant does and doesn't carry

Atlassian provides an automated assistant that moves your Opsgenie setup into Jira Service Management, and for the core objects it genuinely works: alerts, on-call schedules, escalation policies and most integrations carry across and keep functioning. Credit where it is due, this is a real migration tool, not a spreadsheet export.

The trouble is what happens at the edges. Several things change shape, several need manual work, and a few are gone entirely. If you assume the assistant is lossless, you find the gaps in production. Here is the field-level reality, verified against Atlassian's own feature-changes documentation in August 2026.

None of this makes JSM a bad tool. It means the migration is not the one-click event the marketing implies, and the manual items cluster exactly where MSPs live: routing, call handling, notification policy and the integrations that touch your PSA. Budget real time for the manual column and test each item against a client that will tell you politely if their pages stop arriving.

The MSP landmine most migration guides miss

Here is the one that does not appear in the generic guides, because generic guides are not written for MSPs. Opsgenie's MSP feature, the Opsgenie-to-Opsgenie model where a parent account manages separate child accounts per client, is deprecated. It is not carried into JSM in the same shape. Per Atlassian's documentation, the Opsgenie-to-Opsgenie integration is no longer supported and child accounts convert to the free tier.

If you built your multi-tenant structure on that model, one client per child account with its own isolated configuration, the migration does not preserve it. You are rebuilding multi-tenant separation by hand in whatever you move to, using teams and routing rather than account boundaries. Factor that into your timeline as its own workstream, not a line item. It is often the single largest piece of MSP-specific rework in the whole move.

Step 3: JSM, or export and move elsewhere

Once your data is safely exported, the destination decision is lower-stakes, because you can no longer lose anything by taking your time. Two honest paths:

Stay with Atlassian and migrate to JSM if you are already deep in Jira and Confluence, your primary need is ITSM ticketing with on-call attached, and the manual rework above is acceptable. The assistant does most of the heavy lifting and you keep one vendor.

Export and move to a tool built for your shape of work if your value is in per-client routing, PSA ticket sync and clean shift handovers. The JSM assistant will happily carry you into a platform that, like Opsgenie, still reaches ConnectWise, Autotask and HaloPSA through middleware rather than native two-way sync. If that was already a friction point, the migration is the natural moment to fix it rather than reproduce it. For the full comparison of what to buy instead, the PagerDuty alternatives hub and the MSP-specific shortlist both score the candidates honestly, Shiftctl included, with its limitations stated.

Step 4: The iCal import path if you move to Shiftctl

If you decide to move rather than migrate to JSM, the schedules you exported in Step 1 are already in the right format. Shiftctl imports Opsgenie and PagerDuty schedules over iCal, so your rotations come across without a manual rebuild. That gets the calendar side done in minutes; you then reconnect your integrations from the inventory you made and rebuild escalation policies from your exported reference.

Where this earns its place for MSPs is what happens after import. On Enterprise, Shiftctl ingests RMM and monitoring alerts, routes each one to whoever the rotation says is on call, escalates over SMS, voice call with press-1 acknowledgement, Slack, Teams, email and push until someone answers, syncs the resulting ticket back to ConnectWise, Autotask or HaloPSA with native two-way status, and carries anything still open at shift end into the next engineer's handover brief. For an MSP paging over SMS and chat, that is the full loop Opsgenie covered, in one system, with the PSA sync and handover that Opsgenie never did natively.

The honest caveat, the same one we state everywhere: Shiftctl does not yet take inbound calls, so if a client contract requires a number people can dial into, keep a dialer-based tool for that one step and run Shiftctl alongside it. Everything else, alert in through routed, escalated, ticketed and handed over, lives in one place. See the docs for the iCal import steps, or the Opsgenie comparison for a side-by-side.

Opsgenie migration checklist

Work this in order. The first block is the urgent one and does not depend on your destination decision, so start it today regardless of where you plan to land.

Preserve your data (do this now)

• Export every on-call schedule as iCal (.ics) and save the files
• Export escalation policies and routing rules as JSON via the API, or screenshot every one if you are not scripting it
• Build an integration inventory: every RMM, monitoring, PSA and webhook connection, and what each one does with an alert
• Export historical alert and incident data through the reporting API and archive it to storage you control
• Confirm you can reproduce any after-hours billing figures from the archive, not just from the live tool

Plan the move

• Decide destination: JSM if you are all-in on Atlassian, or a purpose-built tool if PSA sync and handover are the priority
• Flag the manual-work items early: heartbeats, global notification policies, Atlassian-owned call numbers, custom incident roles, and any unsupported integrations
• Scope the multi-tenant rebuild separately if you relied on the deprecated Opsgenie MSP child-account model

Execute and validate

• Run the migration and use the 120-day parallel-access window to validate, do not turn Opsgenie off on day one
• Re-authenticate every script or integration that used an Opsgenie API key, now Atlassian authentication tokens
• Test PSA ticket creation and routing end-to-end against a real client before you trust it
• Only decommission Opsgenie once you have confirmed the new system is handling production load correctly, and well before 5 April 2027

Frequently asked questions