Opsgenie End of Support April 2027: Migration Guide

Opsgenie End of Support April 2027: Migration Guide

Opsgenie reaches end of support on April 5, 2027. On that date, platform access ends and Atlassian permanently deletes any data that hasn't been migrated. New sales stopped on June 4, 2025 (atlassian.com). If your team runs on-call schedules, alert routing, or incident response through Opsgenie, you have a fixed window to move that data — and a set of decisions that are easier to make now than in Q1 2027.

This guide covers the timeline, what Atlassian's automated migration tool actually moves (and what it quietly leaves behind), how to export data independently of the migration path, the technical mapping challenges between Opsgenie and JSM, JSM ingest constraints during bulk migration, and how to plan the work so you're not scrambling with five months left.

What are the key Opsgenie end-of-support dates?

Atlassian stops supporting Opsgenie on April 5, 2027. New sales ended on June 4, 2025, and data left in the platform after the support date is permanently deleted.

After you migrate, Atlassian gives you 120 days before it permanently shuts down your Opsgenie account, and you can turn it off sooner (support.atlassian.com). Renewals remain possible only for subscription terms that end before the end-of-support date. Edition upgrades and downgrades stopped on June 4, 2025 (atlassian.com).

This is not a gradual deprecation. If you have not migrated by April 5, 2027, you lose everything: on-call rotations, alert rules, integration configs, and all accumulated historical data. Atlassian says Opsgenie APIs keep working while you move to JSM (support.atlassian.com), so exports you start now are valid.

What Opsgenie data is at risk?

Opsgenie data encompasses the complete set of operational configuration and history your team has built over time:

• Alerts and alert history — every P1 through P5 alert, with tags, custom fields, notes, and full activity logs
• On-call schedules and rotations — schedule layers, overrides, time zones, and team membership
• Escalation policies — escalation steps, timing rules, and routing logic
• Incidents and post-incident reviews (PIRs)
• Teams and user configuration — roles, notification rules, forwarding rules
• Integrations — connections to monitoring tools (Datadog, Prometheus, Grafana, CloudWatch, etc.), chat tools, and webhooks
• Heartbeats — health-check configurations and intervals
• Routing rules and alert policies

Everything left in Opsgenie after April 5, 2027 — alert history, schedules, escalation policies, integration configs — is deleted permanently with no recovery path.

Where can Opsgenie data go?

Jira Service Management (JSM) Cloud is Atlassian's primary migration target. Atlassian is moving Opsgenie's alerting and on-call features into JSM.

Atlassian's Opsgenie documentation previously listed Compass as a destination, but in April 2026 Atlassian announced that it would stop selling Compass on May 13, 2026 (developer.atlassian.com). Compass support is planned to end on December 31, 2027, and Compass alerts and on-call continue in Jira Service Management (support.atlassian.com). A move to Compass now means a second migration to JSM within approximately one year.

Three hard constraints shape your options:

1. No Data Center path. Data Center customers cannot move Opsgenie data into Jira Service Management Data Center (support.atlassian.com). You can only migrate to an existing JSM Cloud site or create a new one. If you currently run Atlassian Data Center products and use standalone Opsgenie for alerting, you must either migrate alerting to JSM Cloud or move to a third-party incident response platform (PagerDuty, incident.io, Grafana Cloud IRM, Splunk On-Call) that supports your architecture.

2. Compass is a dead end. Compass itself reaches end of support December 31, 2027. Migrating there now guarantees a second migration within a year.

3. No Atlassian bridge to third-party platforms. Atlassian's tool moves data only into Atlassian products. If you're moving to a non-Atlassian platform, you'll rely on the destination's own importer where one exists, or export via the Opsgenie REST API and import with scripts.

Choosing a destination: JSM vs. third-party platforms

If your team is data-center-only or evaluating non-Atlassian alternatives, the following comparison covers the platforms most commonly targeted in Opsgenie migrations.

Decision logic:

• If you are already on JSM Cloud or Atlassian Cloud broadly → JSM is the lowest-friction path.
• If you require Data Center deployment → JSM is not an option for Opsgenie data; evaluate a third-party platform.
• If Terraform/IaC management of on-call config is a hard requirement → JSM supports it through Atlassian's Operations Terraform provider (support.atlassian.com); compare its resource coverage with your current config.
• If you use Grafana for observability already → Grafana Cloud IRM may reduce webhook configuration overhead.

What does Atlassian's migration tool actually transfer?

When you start the migration, your Opsgenie data and settings remain intact in Opsgenie — they are copied into JSM rather than moved destructively. Opsgenie APIs continue to function during the migration window, so your team is not forced to cut over immediately (support.atlassian.com).

Here is what the automated tool handles — and what it does not.

Transfers automatically

• Teams and users
• On-call schedules and rotations
• Escalation policies
• Alert rules and integrations (repointed to JSM's alerting endpoints)
• Existing incidents, linked alerts, and post-incident reviews (into a JSM service project called "Opsgenie Migrated Incidents") (support.atlassian.com)

Requires manual rebuild

• Actions and incident rules. Opsgenie actions and incident rules are not automatically moved to JSM. You must recreate them using Jira Automation (support.atlassian.com).
• Chat integrations. Slack and Microsoft Teams integrations must be manually reconnected.
• SSO. Opsgenie SSO isn't available after migration (support.atlassian.com). If your security team requires SSO, this becomes a parallel project requiring Atlassian Guard — not a migration checkbox.
• Incident fields. Responder roles, stakeholder filters, and incident templates do not carry over.
• Phone numbers. Atlassian-owned numbers must be ported manually before migration; Twilio-owned numbers sync automatically.
• Global notification policies. In JSM, notification policies are scoped to the operations/team level only. Any global policies configured in Opsgenie must be converted manually before shutdown.
• Heartbeats. Heartbeats are only available on JSM Premium and Enterprise tiers. If you're on a lower tier, heartbeat configurations do not transfer at all.
• Complex schedule restrictions. The editing experience differs between platforms, and complex restriction rules are the most commonly reported mapping gap.
• Opsgenie reporting. Nine Opsgenie reports do not carry over, and neither does their historical reporting data (support.atlassian.com).
• Terraform/IaC configs. If your escalation policies and schedules are Terraform-managed with the Opsgenie provider, you must move that code to Atlassian's Operations Terraform provider (support.atlassian.com). Check that it covers every resource you manage today.
• Outdated integrations. Legacy integrations (e.g., Pingdom Server Monitor, Crashlytics) will not migrate.

Post-migration incidents don't sync. Incidents created in Opsgenie after the migration date do not sync automatically and require a one-time manual transfer. Plan your cutover so your team starts creating incidents directly in JSM on migration day.

How does JSM alert data retention differ from Opsgenie?

JSM alert data retention is the period after which alert records are automatically deleted, based on your subscription tier. This is one of the most operationally significant — and easily overlooked — differences between the two platforms.

Opsgenie Enterprise allowed alert data to be retained indefinitely. After migration, new JSM alert data expires according to plan tier (support.atlassian.com):

Once alert data is deleted from JSM, it cannot be recovered.

If your compliance, audit, or analytics workflows depend on multi-year alert history, this change demands immediate action. A team can migrate successfully and discover months later that the MTTA/MTTR history its auditors or ML tools expected to query has already aged out. Export historical alert data to storage you control — S3, GCS, or Azure Blob — before migration, regardless of your destination platform.

How to export Opsgenie data via the REST API

Exporting a portable copy of your Opsgenie data is the first action you should take — even if you plan to use Atlassian's automated migration tool. Do this before you touch the migration assistant and before you have settled on a destination. The goal is a complete, portable archive of configuration and history that does not depend on Atlassian keeping anything alive.

Configuration data

Export schedules via GET /v2/schedules, users via GET /v2/users, teams via GET /v2/teams, and escalation policies via GET /v2/escalations. All endpoints are part of the Opsgenie REST API v2.

When exporting schedules, use the expand=rotation flag. Without it, the list response omits the rotation data needed to rebuild the schedule.

# Export schedules with rotation details
curl -s 'https://api.opsgenie.com/v2/schedules?expand=rotation' \
  -H 'Authorization: GenieKey YOUR_API_KEY' > schedules.json
 
# Export escalation policies
curl -s 'https://api.opsgenie.com/v2/escalations' \
  -H 'Authorization: GenieKey YOUR_API_KEY' > escalations.json
 
# Export users
curl -s 'https://api.opsgenie.com/v2/users' \
  -H 'Authorization: GenieKey YOUR_API_KEY' > users.json
 
# Export teams
curl -s 'https://api.opsgenie.com/v2/teams' \
  -H 'Authorization: GenieKey YOUR_API_KEY' > teams.json

Alert history

The /v2/alerts endpoint returns at most 100 alerts per page, and the sum of offset and limit must stay below 20,000 (docs.opsgenie.com). For datasets larger than 20,000 alerts, you must window by createdAt with a search query and paginate within each window.

If you have 500,000 historical alerts, that requires at minimum 5,000 API calls to read alert summaries — before fetching individual alert logs, notes, or attachments.

The search query takes createdAt as a Unix timestamp in milliseconds, with >= and < operators combined by AND (docs.opsgenie.com):

# Paginate alerts within a date window (Q1 2024, UTC, epoch milliseconds)
curl -s -G 'https://api.opsgenie.com/v2/alerts' \
  --data-urlencode 'query=createdAt >= 1704067200000 AND createdAt < 1711929600000' \
  --data-urlencode 'limit=100' \
  --data-urlencode 'offset=0' \
  -H 'Authorization: GenieKey YOUR_API_KEY' > alerts_q1_2024_page1.json

Rate limits vary by plan and domain. Opsgenie uses a token bucket algorithm with limits checked per minute and per second. Limits vary by subscription plan (Enterprise highest, Free lowest) and by request domain. The User API and Team API fall under the Configuration domain, which carries lower limits than the other three domains (docs.opsgenie.com). Always read the X-RateLimit-State response header and back off when the state is THROTTLED, which comes with HTTP 429. Migration scripts must implement exponential backoff and retry logic. Without this, bulk exports fail silently on high-volume accounts.

JSM ingest rate limits

The Opsgenie export rate limit section is only half the constraint picture. JSM imposes its own ingest rate limits that become a bottleneck during bulk migrations.

Jira Cloud's REST API enforces an hourly points quota, per-second burst limits, and per-issue write limits. When you exceed one, it returns HTTP 429 with a Retry-After header (developer.atlassian.com). Atlassian does not publish a simple per-minute figure, so measure your own throughput on a sample run.

In practice, bulk migrations writing thousands of historical alerts to JSM must implement the same exponential backoff logic used on the Opsgenie export side, and honor Retry-After. Run the bulk historical import during the working days before go-live, while Opsgenie keeps paging your team.

Additionally, neither write path lets you backdate a record. JSM's create-alert endpoint (POST https://api.atlassian.com/jsm/ops/api/{cloudId}/v1/alerts) has no field for the original creation time (developer.atlassian.com). The Jira issue creation API (POST /rest/api/3/issue) sets created itself, and Atlassian's request to allow setting it is still open (jira.atlassian.com). To preserve MTTA/MTTR history, write the original createdAt, acknowledgement, and close times into extra properties on the alert or into custom date fields on a Jira issue, and keep the raw export as the record of truth. This requires mapping Opsgenie alert fields to your JSM schema — a one-time configuration step, but a non-trivial one.

The Opsgenie configuration backup tool

Opsgenie marks its open-source configuration backup tool as deprecated and no longer supported, so test it before you rely on it (github.com). It exports: custom user roles, users and notification rules, forwarding rules, teams, escalations, schedules and schedule overrides, alert policies, integrations and integration actions, and policies.

It has a significant documented gap: exporting dynamic data like alerts, incidents, alert and customer logs, and notifications is not possible and will not be implemented. Use the REST API directly for alert and incident history.

Mapping Opsgenie data to JSM

Migrating from Opsgenie to JSM Cloud is not a one-to-one transfer. Opsgenie was built as a flat, alert-centric application. JSM is a relational ITIL service management platform built on Jira. Every technical decision in this migration flows from that architectural mismatch.

Users and Atlassian Account IDs

In standalone Opsgenie, users are identified by email address. In JSM Cloud, users are identified by their Atlassian Account ID (AAID). Before you can migrate a single alert or schedule, every Opsgenie user must map to an active AAID in your Atlassian organization.

If an alert is assigned to an Opsgenie user who doesn't exist in Atlassian Cloud, the assignment fails. During migration, extract the Opsgenie user list via GET /v2/users, match email addresses against your Atlassian directory with Jira's Find users endpoint (GET /rest/api/3/user/search?query=<email>), and use the resulting AAIDs as the primary key for all relational mapping. Privacy controls can hide a user's email address in that response, so plan a manual fallback for unmatched users (developer.atlassian.com).

Schedules and timezone alignment

Opsgenie stores rotations as JSON payloads defining startDate, endDate, timezone offsets, and participant arrays. JSM absorbs these, but timezone data must be perfectly aligned during the API POST. A mismatched timezone offset means a 9:00 AM on-call shift could trigger at 2:00 AM local time. This is one of the highest-risk mapping errors and the hardest to catch without firing explicit test alerts against each schedule post-migration.

Escalation policy reconstruction

Opsgenie allows highly granular escalation rules — for example, "if not acknowledged in 15 minutes, page the next user; if not acknowledged in 30 minutes, page the entire team." Atlassian's migration tool syncs escalation policies for you. If you rebuild them yourself, or for a different JSM site, each Opsgenie escalation becomes a JSM escalation created through the JSM Operations REST API (POST /v1/teams/{teamId}/escalations), and a routing rule (POST /v1/teams/{teamId}/routing-rules) sends the team's alerts to it (developer.atlassian.com). Check each multi-step rule after the rebuild, because the timing logic must be re-expressed step by step.

Preserving alert history timestamps

When migrating historical alerts to JSM yourself, the central challenge is preserving chronological integrity. If you push old alerts via the JSM create-alert endpoint, JSM records them as new alerts at the time of receipt — destroying your historical MTTA and MTTR metrics. The Jira issue creation API cannot backdate created either (see above).

To preserve original timestamps: carry them as data rather than as system timestamps. This requires:

1. Creating a dedicated JSM project (or alert extra properties) to hold historical alert data
2. Mapping Opsgenie alert fields (priority, tags, details, createdAt, closedAt) to Jira custom fields and system fields
3. Writing the original Opsgenie timestamps into custom date fields such as "Original created" and "Original closed", and reporting MTTA/MTTR from those fields

Incidents and postmortems

Opsgenie Incidents map to JSM Incident issue types. Because JSM is built on Jira, an incident is fundamentally a Jira issue. Opsgenie incident timelines, responder notes, and tags must be converted into Jira issue comments, custom fields, and labels. Attachments must be downloaded from Opsgenie via GET /v2/alerts/{identifier}/attachments/{attachmentId}, temporarily buffered, and uploaded to JSM via the Jira attachment API (POST /rest/api/3/issue/{issueIdOrKey}/attachments) using multipart form-data.

How to plan an Opsgenie migration timeline

The migration has two distinct clocks. The data migration — moving configuration and history from Opsgenie to JSM or another platform — is the part ClonePartner performs, and it can run in days once scoping is complete. The operational transition — validating schedules, rebuilding integrations, retraining responders, running parallel alerting — is your team's own work, and its length depends on team size and configuration complexity.

Begin scoping the migration at least 3–4 months before your internal deadline. For most teams, that means starting no later than December 2026.

For the data migration itself, timelines depend on data volume, complexity, and API rate limits:

• Small datasets (under 10,000 records): under 24 hours
• Most migrations: 1–5 business days, including bulk migration and delta syncs
• Very large alert histories: a custom engagement, with a timeline given after scoping. Duration is primarily governed by JSM write rate limits (see above), escalation policy complexity, and team availability for validation.

Alert export throughput: at 100 alerts per page, exporting 10,000 alerts requires 100 API calls, plus any backoff the Opsgenie rate limits impose. Historical imports at scale are usually bound by the write side, not the export side.

Working-backward timeline

Validation must include a tabletop exercise using a realistic scenario — an unavailable customer-facing service or a failing integration. Include technical responders, service owners, support leads, and communications stakeholders. Confirm that alerting reaches the correct people, respects quiet hours and escalation timing, opens or links the right JSM record, and surfaces useful context.

Freeze config before export. Freeze configuration changes in Opsgenie at the point of export so data does not drift during the migration window. Timestamp your export files and diff against a second export closer to cutover to identify any schedule or policy changes that need to be re-exported.

Opsgenie to JSM migration: step-by-step

This section covers the Atlassian-to-Atlassian path. If you're moving to a third-party platform, the export steps above still apply, but the import side is platform-specific.

1. Export a portable archive first

Schedules (with expand=rotation), escalations, users, teams, alert history (windowed by date), integration config — all via the Opsgenie REST API v2. Store output outside Atlassian before proceeding.

2. Map user identities

Extract all Opsgenie user email addresses via GET /v2/users. Match each against active Atlassian Account IDs (AAID) using Jira's Find users endpoint. Any user that doesn't resolve to an AAID will cause assignment failures during migration. Resolve gaps before initiating the tool.

3. Start the migration from your JSM site

From your JSM site, go to Settings → Products → Move from Opsgenie (support.atlassian.com). This initiates the sync of teams, users, integrations, and alerts into JSM.

You must be an Opsgenie Owner and a site admin to schedule the migration, and the migration date must be at least seven days in the future (support.atlassian.com).

4. Validate user roles and permissions

All Opsgenie users and roles are synced, but role mapping is not exact. Opsgenie admins who don't get the JSM product admin role are listed so you can assign it after the move. Users whose custom Opsgenie role isn't supported get the User role unless you assign another (support.atlassian.com). Audit the role mapping before granting production access.

5. Verify schedules and fire test alerts

Complex schedule restrictions and some notification configurations are known to map imperfectly. Verify every rotation by firing real test alerts — not by visually inspecting the schedule UI — and confirm the right person gets paged at the right time, in the correct time zone.

6. Rebuild actions, incident rules, and integrations

Opsgenie's alert actions and incident rules don't move automatically. Use Jira Automation to recreate them, then delete old Opsgenie actions post-migration to prevent conflicts.

Slack and Microsoft Teams integrations require manual setup. Any script or integration using an Opsgenie API key needs re-authentication against JSM endpoints.

7. Repoint monitoring integrations and heartbeats

Your engineering team must generate new integration URLs in JSM Cloud and update the outbound webhook configuration in every source monitoring tool — Datadog, New Relic, AWS CloudWatch, Prometheus, and anything else currently firing payloads at Opsgenie webhook URLs.

Heartbeats are available in JSM on Premium and Enterprise only, and you must update your heartbeat settings by hand after the move (support.atlassian.com). There is no API method to update a third-party system's outbound webhook destination automatically. Audit all inbound integrations and update them manually or via Infrastructure as Code.

8. Switch mobile apps

The Opsgenie mobile app retires with the product. Contact methods sync automatically, but responders need to install the Jira mobile app (support.atlassian.com). Test it with your actual on-call responders during the parallel-run window, so usability issues surface before cutover, not after.

9. Run parallel, then cut over

Both platforms can run simultaneously for up to 120 days after the migration date (support.atlassian.com). Use that window for genuine end-to-end validation, not as a passive safety net.

Common migration mistakes

Assuming the automated tool is lossless. It isn't. Actions, incident rules, SSO, Atlassian-owned phone numbers, global notification policies, heartbeats (on sub-Premium plans), nine categories of Opsgenie reports, and outdated integrations all require manual work.

Ignoring JSM write rate limits. Teams that plan only for Opsgenie export speed are caught off-guard by Jira Cloud's throttling. Measure throughput on a sample run, and start the bulk import early enough to finish before go-live.

Ignoring alert data retention. Moving from indefinite Opsgenie Enterprise retention to JSM Standard (1 year) silently schedules deletion of data your compliance or analytics teams may need. Export and archive before migration.

Letting timestamps get overwritten. Neither the JSM alert API nor the Jira issue API can backdate a record. Store original Opsgenie timestamps in custom fields or extra properties, or MTTA/MTTR history is lost.

Waiting until Q1 2027. Nobody wants to switch pagers during a bad week — and there's never a good week. Starting late compresses your parallel-run window and turns validation into a checkbox.

Not testing the full alert path. Verifying that schedules transferred is not the same as verifying that a Datadog alert fires, reaches JSM, routes to the right schedule, pages the right responder's phone at 3 AM, and creates the correct Jira issue. Test the entire chain.

Treating Compass as a safe intermediate step. Compass reaches end of support December 31, 2027. A move there now means a second migration within a year.

Moving to a non-Atlassian platform

You can use the Opsgenie REST API to export users, schedules, escalation policies, and integrations regardless of your destination. The API endpoints are the same whether your target is PagerDuty, incident.io, Grafana Cloud IRM, or anything else.

The import side varies by platform. Most modern on-call tools accept schedule data as JSON or provide their own REST APIs for schedule creation. PagerDuty exposes a Schedules API (POST /schedules) that accepts on-call layer configurations directly comparable to Opsgenie's rotation schema. incident.io imports Opsgenie schedules and escalation paths directly (docs.incident.io), and Grafana's IRM migrator tool reads from Opsgenie (grafana.com). Check what each importer marks as incompatible, and script the rest.

The non-transferable items — webhook URLs, API keys, Slack app connections — must be rebuilt in any destination, not just JSM.

Export your schedules first, then decide your destination separately. There is no reason to couple the two decisions.

Migration validation and cutover strategy

Because IT operations run 24/7, you cannot freeze alerting while data moves. A rigorous validation and cutover process is essential.

Validation

A migration is only as trustworthy as its verification method. Effective validation requires:

1. Record-count parity — verifying the total number of extracted Opsgenie records matches the total successfully created in JSM (or the target platform).
2. Field-level sampling — spot-checking records to confirm priorities, tags, and custom fields mapped correctly. Sample at minimum 5% of records, or 500 records, whichever is larger.
3. Referential integrity checks — confirming that an alert assigned to a specific schedule in Opsgenie is assigned to the corresponding schedule in JSM, with the correct AAID as assignee.
4. Attachment checksums — validating that files downloaded from Opsgenie match the byte size and SHA-256 hash of files uploaded to JSM.
5. Timestamp spot-checks — for historical alerts you wrote yourself, verify that the original-timestamp fields match Opsgenie createdAt values on a sample of records.
6. End-to-end alert firing — trigger real test alerts against each team's schedule and confirm the correct responder is paged at the correct time.

The cutover

Cutover is a multi-stage process, not a single switch:

1. Bulk historical migration: Export and import all Opsgenie data older than 30 days into JSM while your team continues using Opsgenie in production. Run validation against this bulk import.
2. Delta syncs: Once bulk import is verified, run repeated delta syncs to capture alerts created since the bulk export. Use Opsgenie's createdAt field as the high-water mark for each delta window.
3. Webhook repoint: Go live on a Monday morning, when the whole team is at work to watch the first alerts. Freeze Opsgenie configuration before the working day starts, then update monitoring tool outbound webhooks from Opsgenie to JSM endpoints. This is the only action that is irreversible mid-migration.
4. Final delta sync: Run one final delta sync of changed records only, which typically takes about 30 minutes, to capture any alerts that fired during the webhook propagation window. Responders then work from JSM that morning.
5. Verification: Confirm alert counts and referential integrity in JSM against Opsgenie's final state.

The dual-run window (up to 120 days) gives you time to catch gaps without production risk — but only if you use it for active testing rather than passive coexistence.

Where ClonePartner fits

The Opsgenie shutdown is a forcing event: your data must move, and the clock is fixed. We handle data migrations like this routinely.

For Opsgenie, the data-migration work we perform covers: exporting your full configuration and alert history via the API, mapping it to your target platform's data model, running sample migrations until every schedule, escalation policy, and alert record lands correctly, and completing the full migration with the multi-stage validation described above — including original timestamps carried in custom fields, AAID mapping, and attachment checksum verification.

What we don't do: we don't rebuild your Jira Automation rules, reconnect your Slack integrations, or retrain your on-call responders. That is your team's operational transition work, running on a separate timeline. We move the data; you rebuild the workflows.

Security and process

ClonePartner holds SOC 2 Type II and ISO 27001 certifications (independently audited), alongside GDPR, CCPA, and HIPAA safeguards. Data is encrypted via AES-256 at rest and TLS 1.2+ in transit. A dedicated migration engineer owns your project from scoping to cutover. Only that engineer can access your staging environment, and staging databases auto-purge no later than 30 days after project close. We sign NDAs and DPAs on request and execute a BAA before handling any PHI.

Pricing

One fixed price per project, starting at $500. No hourly billing, no hidden fees, no change orders, and no per-record metering. Your fixed-price proposal is generated after a free 30-minute scoping call.