Opsgenie Migration: Deadline, Options and Cutover

What changed, and by when

Opsgenie is on a published end-of-life schedule. Three dates matter, each stated in Atlassian's own documentation.

The published lifecycle notice describes continued service for existing customers until end of support; check account-specific subscription and migration notices before relying on that date. You can still buy seats up to 2027-04-05, and still renew, but only if the term concludes before that date. The 2025-06-04 change removes the usual levers for buying time: no edition change to unlock a feature that would simplify the move, and no extra site to stage it on.

Which deadline applies to your account?

The product-wide end date and an account banner answer different questions. Atlassian documents automatic shutdown 120 days after migration, with the option for an administrator to turn Opsgenie off sooner. This can make your account deadline earlier than 2027-04-05. Record the actual data-migration date and the shutdown notice; do not treat the 120-day window as an extension beyond the product-wide end date. Atlassian migration lifecycle (opens in a new tab).

An earlier date in a screenshot or discussion could also concern a subscription or scheduled action. Determine which operation the notice affects before planning against it.

Collect the notice text, the affected site or account, its timezone, subscription end date and any migration already scheduled by an administrator. Keep the complete notice in your private migration record, including links to the action it requests. Do not post account identifiers or billing screenshots publicly to obtain a general answer.

If the dates conflict, ask support which operations stop at the earlier date: editing, receiving alerts, notifying responders, exporting data or accessing history. Ask whether an administrator scheduled the transition and what changes are available before it starts. Record the answer and ticket reference; a guessed interpretation should remain marked unconfirmed.

Work backwards from the earliest confirmed date that affects a required operation. Name the person who will recheck the banner and account status before cutover. Avoid cancelling or rescheduling a migration merely as a test of what a banner means; that can change the very plan you are investigating.

A useful readiness check is to have another team member reconstruct the deadline from the saved evidence, then identify which test or export would become impossible if the earlier date applies. If they cannot, the plan still depends on undocumented assumptions. Use the replacement workflow pilot and Terraform inventory to make the required work concrete.

Decision tree

One branch matters. The rest is consequence.

Are you staying inside the Atlassian ecosystem? If yes, the destination is Jira Service Management. The current migration-options documentation recommends a JSM plan based on your existing edition: Opsgenie Free to JSM Free or a paid plan, Essentials to Standard, Standard to Premium, and Enterprise to Premium or Enterprise according to the required features. These are recommendations; an existing JSM subscription can change the available recommendation. Confirm feature eligibility before accepting the destination plan. Atlassian migration options (opens in a new tab).

If no, you are running a replacement selection under a deadline. Inventory first, shortlist second. The failure mode is choosing from a feature page and finding the gap during the cutover test, when the calendar has stopped being flexible.

Is the second Atlassian destination viable? Atlassian's Opsgenie documentation has also directed teams to Compass for developer alerting, with Jira Service Management framed as the path for IT operations. Anyone who picked Compass on that basis needs this.

Set the internal target. Work backwards from your earliest applicable account or product deadline. Subtract a full rotation of parallel running, a cutover test, a repair window and any change freeze. Confirm that all of those activities fit before starting the migration window.

Inventory checklist

Do this before evaluating anything, Jira Service Management included. It is the one artefact that survives whichever way the decision goes. Record an owner beside each item.

• Schedules. Rotation shape and length, timezone, handoff time, and who is actually in it. Note where one person wears two hats.
• Escalation policies. Each step, its delay, target, channel and stop condition. Note which have never fired.
• Teams and groups. Membership, and specifically anything modelled as a Group rather than a team.
• Inbound integrations. Every alert source, its type, its key or endpoint, and the payload fields routing depends on.
• Outbound and bidirectional integrations. Ticketing, chat, status pages, anything receiving from Opsgenie or syncing state back.
• API and infrastructure-as-code dependencies. Terraform, scripts, CI jobs and internal tools holding a stored key. Grep your repositories for the API hostname; it finds more than asking people does.
• Contact methods and notification rules. Per person: numbers, devices, channel order, delays, quiet hours. This decides whether a page reaches a sleeping human, and it is most often reconstructed from memory.
• Heartbeats. What sends each one, its interval, and what should happen on expiry. Note which are V1.
• Routing rules. Global and team routing, time-based rules, and anything that suppresses, deduplicates or reshapes alerts. Note which are V1.
• Historical data and audit requirements. What you must retain, in what format, and who signs off that a copy suffices.
• Custom actions. Anything driven by the Edge Connector, custom scripts, or automation triggered from an alert.

What Atlassian migrates for you, and what it does not

Check the destination Jira Service Management plan for each dependency. The feature table below is a selection checklist; supported integration versions and post-migration tasks still need individual checks. A copied object is evidence of transfer, not evidence that its workflow works.

The distinction between core schedules and their global list pages follows the separate entries in Atlassian's feature matrix (opens in a new tab) and schedule migration guide (opens in a new tab). Confirm the actual navigation on a Free account before assuming it matches a paid-plan demonstration.

The integration migration guide (opens in a new tab) identifies older integrations that transfer with configuration restrictions and other versions that do not transfer. Its bidirectional restriction means a working incoming alert on Free or Standard does not establish outgoing parity. For phone numbers, porting alone is insufficient: the incoming-call guide (opens in a new tab) requires updated Twilio details in JSM before calls can be received.

Treat deprecated capabilities separately:

• Incident Command Center and incident configuration. ICC is retired. The feature matrix points conference rooms, templates and response roles toward Incident Configurations; the detailed incident guide says templates and responder-role configuration do not migrate. Validate your replacement workflow and selected plan. Incident migration details (opens in a new tab).
• Groups. Conversion to teams can happen before migration or automatically during it. Review call-routing behavior and membership maintenance; the resulting team is not a guarantee of identical group behavior.
• Deprecated notification policies. Convert them before migration so they synchronize, following the detailed policy migration instructions (opens in a new tab). Test suppression, delay and closure on the destination team.
• API authentication. API Key Management is replaced by Atlassian authentication. Inventory standalone configuration keys separately from integration keys; the Opsgenie settings list does not include every integration credential. Determine the destination endpoint and authentication for each client, then test before revoking its old credential. Opsgenie key types (opens in a new tab).
• Other legacy features. Inventory Edge Encryption, Heartbeats V1, MSP links, team activity streams and stakeholder SMS against the feature matrix. BYOK replaces Edge Encryption, but verify eligibility and setup for your account. Give each remaining dependency an owner and a confirmed replacement or retirement decision.

The general pre-migration checklist is not sufficient evidence that a dependency is safe to leave alone. Use its specific feature instructions, and record a successful controlled test before closing the item.

Export: what you can actually get out

Atlassian documents a schedule export: the request exports a schedule to a .ics file, at GET https://api.opsgenie.com/v2/schedules/:identifier.ics. The same Schedule API page documents List Schedules, Get Schedule, and Get Schedule Timeline, which together let you enumerate what exists and resolve who is on call across a window.

That is useful, and it is less than it sounds. An .ics file is a calendar: it says a named person covers a named window. It does not carry the escalation policy attached to that schedule, the timeout before step two, each person's channel order, the routing rule that sent the alert to this team, or the reasoning behind any of it. Get Schedule Timeline can check that a new system resolves the same on-call person as the old one, but it is not a way to recover intent.

This limitation belongs to the calendar export, not every export mechanism. For a JSM migration, Atlassian documents Terraform imports for teams, schedules, rotations, escalations, API integrations and email integrations. Supported entity IDs remain the same after that migration, while import declarations still require preparation from your existing state. This does not establish a portable import into an unrelated vendor. Atlassian Operations provider migration (opens in a new tab).

Document escalation intent alongside whichever supported transfer method you use. An imported timeout can be correct while the destination resolves a different responder. Use the Terraform migration checklist to review resource coverage and protect the state before changing providers.

Requirements matrix

Score every candidate, Jira Service Management included, against the same columns. Fill it in yourself; the weights are yours, not a vendor's.

Two rows get skipped in practice: failure of the pager itself, because it feels hypothetical, and exit cost, because it feels pessimistic mid-selection. The Opsgenie end-of-life argues for both.

Dual-run plan

Parallel running means both systems receive the same alerts while only one may reach a phone. That constraint is the design. If both can notify, you have built a double-paging machine, and responders start ignoring one source, usually the new one.

Avoiding double pages. Either the new system ingests everything with every notification rule resolving to in-app only, or it notifies one volunteer whose job is to compare. Never enable both escalation paths for the same service on the same day, and write down which system is authoritative where the on-call person sees it.

How long. At least one complete rotation, so the run covers a weekend, a handover and every person in the roster. Shorter runs test configuration but not people, devices or do-not-disturb settings.

What to watch, roughly in order of how often it goes wrong.

• Routing parity. For every alert in the old system, did the same one arrive in the new, on the same team?
• Occupant parity. At each handoff, do both resolve the same person? Check a DST transition and any schedule spanning timezones.
• Volume parity. Alerts per source per day, both sides. A quieter source in the new system is usually a broken integration, not an improvement.
• Deduplication. Does a flapping source produce one alert or forty on each side?
• Close and auto-resolve. When the source recovers, does the alert close, or linger for cleanup?
• Heartbeat expiry. Stop one deliberately and confirm the new system notices in the expected interval.

Keep a difference log: one row per discrepancy, its cause, its resolution. Move alert sources in severity order, lowest first, so early mistakes happen on alerts nobody is woken by.

Controlled cutover test

Do not cut over on the strength of a configuration review. A person must observe each step rather than infer it from a log.

1. Fire from a real source. An actual integration, not the test button, which verifies the notification service rather than the path.
2. Confirm arrival and routing. The alert carries the payload fields your routing depends on and lands on the intended team.
3. Confirm step one reaches a phone. At night, on a locked and silenced device, on cellular rather than office wifi.
4. Let it escalate. Do not acknowledge. Confirm the secondary is reached after the timeout, through their own channels.
5. Acknowledge, and confirm escalation stops. A policy that keeps paging after acknowledgement is one nobody trusts twice.
6. Resolve from the source. Confirm the alert closes without manual intervention.
7. Exercise an override. Hand a shift over at short notice and repeat step three against the new occupant.
8. Exercise a dead-man path. Stop a heartbeat and confirm the resulting page reaches a person.
9. Record the evidence. Who tested, on which device and network, when, and the delay at each step.

The pass criterion is that a named person observed every step. A step skipped because it was inconvenient to test at night has not been tested.

Rollback

Write the fallback procedure against the account's actual availability window. Returning traffic to an existing configuration and turning a permanently shut-down product back on are different operations.

Before data migration. Check the migration status, provisioning, billing approval and any configuration already changed. Preparation can have effects before the scheduled copy; do not assume cancellation restores every previous state or costs nothing.

During the parallel run. Keep the designated production paging system authoritative. If the new path fails a test, pause that path and confirm the old one still receives and delivers alerts. Record any source or automation changes that also need reversal.

After cutover, while Opsgenie remains available. A fallback can route sources to the old endpoints and restore its notification rules, provided the account, configuration and valid credentials still exist. Maintain only the credentials needed for the approved fallback window, and test the reversal. Rotating a credential changes that procedure; it does not by itself prove the entire system is unrecoverable.

After Opsgenie is turned off. Atlassian says shutdown is permanent, whether an administrator initiates it or the post-migration timer expires. Its separate statement that REST APIs continue until 2027-04-05 is not a promise that the old UI, mobile app or complete paging workflow can be restored. Finish client endpoint changes before shutdown. Shutdown behavior (opens in a new tab).

After 2027-04-05. There is no fallback to Opsgenie: product access ends and unmigrated data is deleted. Your contingency must use the destination or another already tested communication path.

Keep the fallback configured for your agreed validation period only while Opsgenie is still available. Complete a full rotation and controlled device-delivery tests with an empty difference log; do not wait indefinitely for a rare production incident. Decommission deliberately before the applicable shutdown, with required exports already verified and an owner assigned to the remaining contingency path.

Review dates

Each source below has its own check date. The lifecycle, plan, feature and API references used in this update were checked on 2026-09-12. The two Compass references retain their earlier 2026-09-02 check dates; this update does not claim they were checked again.

Source checking records what the documentation said. It does not certify that this migration procedure has been executed in a customer account. Independent technical verification is pending, as recorded in the page metadata. Recheck destination-plan behavior and account notices in your own controlled pilot.

Before committing budget, headcount or a contract, open the relevant primary sources and save their check dates beside the decision. Reconcile any discrepancy with Atlassian support before it becomes a cutover assumption.