Opsgenie Migration Guide and Checklist

Cross-posted from the Fluidify blog.

Every team still running Opsgenie has to move before April 5, 2027, when Atlassian shuts the product down and deletes data that hasn't been migrated. This Opsgenie migration guide is tool-neutral: the same checklist works whether you're doing the Opsgenie to Jira Service Management migration Atlassian offers or moving to a different on-call tool. It covers what to inventory, what to export, what usually doesn't carry over, and how to cut over without a gap in paging.

Key takeaways

• An Opsgenie migration is really five jobs: inventory, export, rebuild, parallel run, and cutover. Schedules are rarely the slow part. Custom routing, automation, and integrations that assume Opsgenie's payload format are.
• Atlassian's automated move to Jira Service Management doesn't carry everything. Chat integrations need reconnecting, action policies become Jira Automation rules, bidirectional integrations need JSM Premium or Enterprise, and some outdated integration versions can't be recreated.
• Whatever the destination, don't cut over until both systems have received the same alerts for at least one full on-call rotation.

Before you start: decide the destination

You can't plan a migration without knowing where it ends, so settle this first. The two realistic paths:

Jira Service Management: Atlassian's automated move syncs Opsgenie data into JSM on a date you schedule, with a 14-day migration demo and 120 days of parallel Opsgenie access afterward, per Atlassian's migration page. Parallel access can't continue past the April 5, 2027 shutdown, so by our own count (Atlassian doesn't state this), moves scheduled after December 6, 2026 get a shorter overlap. Ask Atlassian for your exact end date when you book. Our post on Opsgenie shutdown dates covers that timeline in detail.

Another on-call tool: PagerDuty, incident.io, Grafana Cloud IRM, an open-source tool you host yourself, or something else. Most of these offer some kind of Opsgenie importer, but what they import varies a lot. Ask each vendor for the exact list of objects their importer reads and run it against a copy of your setup before you sign anything. The Opsgenie alternatives comparison lists what each major option imports.

Step 1: inventory your Opsgenie setup

Most Opsgenie accounts have grown for years. Before moving anything, get a full list, and mark each item as keep, rebuild, or retire. Retiring stale objects now is cheaper than migrating them faithfully.

Teams and users: every team, its members, team admins, and any users who only exist as stakeholders. Note custom roles, since Atlassian says custom Opsgenie roles may be downgraded to JSM's standard User role during the move.

On-call schedules and rotations: each schedule's timezone, rotations, rotation length, participants, time restrictions (for example, "weekday business hours only"), and active overrides.

Escalation policies: each rule's condition (alert not acknowledged vs. not closed), delay, and recipients, plus repeat settings. Recipient types like "next user in schedule" or "random team member" may not exist in the destination tool. Our Opsgenie escalation policies and notification rules guide explains each setting so you can map it.

Routing rules: team routing rules decide which escalation or schedule an alert goes to based on conditions and time of day. These are often the most customized part of an account and the least likely to map one-to-one.

Integrations: every inbound integration (monitoring, cloud, CI/CD, email), every outbound or bidirectional one (ticketing, chat), and which team owns each. Record each integration's API key and which systems use it.

Alert and action policies: policies that modify, suppress, or enrich alerts, plus any actions that trigger scripts. These are logic, not data, and almost always need rebuilding.

Heartbeats: each heartbeat's name, interval, and the system that pings it. Atlassian notes that older heartbeats without an assigned team are not moved to JSM.

API keys and automation: every script, Lambda, Terraform workspace, or internal tool that calls the Opsgenie API. Search your repos for api.opsgenie.com, api.eu.opsgenie.com, and GenieKey. If you manage Opsgenie with Terraform, list every opsgenie_ resource in state.

Notification rules and contact methods: each user's personal notification rules, phone numbers, and SMS numbers. These belong to individual people and are easy to forget until someone's phone stops ringing.

Step 2: export what you need to keep

Atlassian says Opsgenie data that hasn't been moved is deleted on April 5, 2027. Even if you're using an automated migration, export independently first. A migration tool moves configuration, and it may not move everything you'll later wish you'd kept.

• Schedules: each schedule can be exported as an iCalendar file through the Schedule API (GET /v2/schedules/:identifier.ics) or the UI's export button. The .ics file has the resulting shifts, not the rotation rules, so also export the schedule and rotation definitions as JSON through the API. Our guide to Opsgenie schedule export and sync covers both.
• Alert and incident history: export what you need for compliance, SLA reporting, and postmortems. One Atlassian community thread reports that incidents and postmortems didn't come across in a JSM move even though alerts and rotations did, so check this yourself rather than assuming.
• Configuration as JSON: pull teams, escalations, routing rules, integrations, and heartbeats through the REST API so you have a reference copy to rebuild from. The Opsgenie API guide covers keys, endpoints, and rate limits.

Step 3: rebuild what won't map automatically

Plan for this to be the long part of the project. Common gaps, whichever destination you pick:

Chat integrations: Atlassian says Slack and Microsoft Teams integrations aren't migrated automatically to JSM. You reconnect and reauthenticate them, then copy chat tools over from the migration guide. Expect the same with any other tool.

Action policies and automation: Atlassian says action policies aren't moved to JSM and asks admins to recreate each one as a Jira Automation rule. With a non-Atlassian tool, these become routing rules, workflows, or scripts.

Bidirectional integrations: Atlassian says these only work on JSM Premium and Enterprise, and teams moving to JSM Free or Standard may lose the outgoing half.

Outdated integrations: about two dozen outdated integration versions can be moved to JSM but can't be created new there. Check whether any of yours are on that list in the migration guide inside your site.

Advanced escalation recipients: "next or previous on-call user," "random team member," and escalation repeats are Opsgenie Standard and Enterprise features. Confirm the destination supports an equivalent, or decide how you'll simplify.

Custom payloads: any integration built against Opsgenie's exact JSON shape, or scripts that reference Opsgenie object IDs, need to be rewritten for the destination's API.

Step 4: run both systems in parallel

This is the step that catches problems before they become missed pages.

1. Point one low-risk alert source (staging, an internal tool) at the new system in addition to Opsgenie. Most monitoring tools can send to two receivers at once.
2. Trigger a test alert and confirm the whole path: the alert arrives, routes to the right team, escalates on the right delay, and reaches the right person on the right channel.
3. Add production alert sources one at a time, still sending to both.
4. Leave both running for at least one full rotation cycle. Watch for schedule handoffs at odd hours, overrides that didn't carry over, and escalation timeouts that differ.
5. Make sure on-call engineers know which system is authoritative during the overlap, so nobody acknowledges in one and ignores the other.

Step 5: cut over and decommission

• Switch each alert source so it sends only to the new tool, one at a time, and confirm a test alert after each.
• Update Terraform, scripts, and runbooks that reference Opsgenie.
• Ask every on-call engineer to install the new tool's mobile app, verify contact methods, and turn off Opsgenie notifications so they don't get paged twice or not at all.
• Do a final export of anything you need for records.
• Decommission Opsgenie on your own date, ahead of April 5, 2027.

The Opsgenie migration checklist

Phase	Task	Done when
Decide	Pick destination (JSM or another tool)	Decision written down with an owner
Inventory	List teams, users, roles	Every team has an owner and a keep, rebuild, or retire tag
Inventory	List schedules, rotations, overrides	Every schedule tagged
Inventory	List escalation policies and routing rules	Every rule's conditions recorded
Inventory	List integrations, heartbeats, API keys	Every key mapped to the systems using it
Export	Export schedules (.ics and JSON)	Files stored outside Opsgenie
Export	Export alert and incident history	Covers your compliance window
Export	Export configuration as JSON	Reference copy stored
Rebuild	Reconnect chat tools	Test message posted
Rebuild	Recreate action policies and automation	Each policy has a replacement
Rebuild	Rewrite scripts and Terraform	No code references Opsgenie
Parallel	Dual-send a low-risk source	End-to-end test passes
Parallel	Dual-send production sources	One full rotation without surprises
Cutover	Switch each source to the new tool only	Test alert after each switch
Cutover	Move on-call engineers' phones over	Everyone confirmed on the new app
Close	Final export and decommission	Opsgenie off before April 5, 2027

FAQ

How long does an Opsgenie migration take? It depends mostly on integration count and how customized your routing is. A small team with a few schedules can finish in a couple of weeks. A larger account with many teams and custom automation should plan for a couple of months including the parallel run.

Does Atlassian's migration to Jira Service Management move everything? No. Atlassian's own documentation lists items that need manual work, including chat integrations, action policies, bidirectional integrations on lower JSM tiers, and outdated integration versions. Review the migration guide inside your site, which lists the unsupported items for your account.

Can I migrate Opsgenie to Jira Service Management Data Center? Atlassian's migration page says Data Center customers need to reach JSM Cloud: either move JSM Data Center to Cloud and then move Opsgenie, or move Opsgenie into a new JSM Cloud site.

Do I need to migrate Opsgenie alert history? Only if you need it, but export it either way. Many tools import configuration but not history, and Atlassian says data left in Opsgenie is deleted on April 5, 2027.

What's the riskiest part of an Opsgenie migration? Cutting over without a parallel run. A schedule that imported with the wrong timezone or an escalation delay that changed will only show up when someone doesn't get paged.

Can I move to a tool other than Jira Service Management? Yes. Any on-call tool that can receive your alerts and model your schedules works. Check what its Opsgenie importer actually reads, and budget time for whatever it doesn't.

A note on where we fit

We build FluidifyAI Regen, an on-call tool ($100 a month flat), and its Opsgenie importer reads schedules, rotations, and escalation policies through the Opsgenie API with a dry-run mode, but not teams, overrides, or integrations, which is the same "rebuild" list as above. If you want to see that path specifically, it's in our Opsgenie-to-Regen walkthrough. The checklist above applies whichever tool you choose.