Opsgenie end of life: exporting incident and on-call history

What is happening to Opsgenie?#

Atlassian has announced the end of Opsgenie as a standalone product: new sales have stopped, and support ends on a later date set out in Atlassian's notice. Atlassian's stated path for existing customers is to move alerting and on-call work into Jira Service Management or Compass.

Dates and migration terms can differ by plan, so check the official notice and your own subscription before planning. The practical point for a CTO is simpler than the timeline: once support ends, history held in Opsgenie becomes harder to reach, and a migration focused on keeping paging running will not necessarily carry that history with it.

Configuration versus history: what each object needs#

Opsgenie objects split into configuration, which keeps on-call working in the next tool, and history, which records what happened. Configuration can be rebuilt or migrated; history can only be exported.

Most teams spend their migration effort on the top half of this table, because broken paging is visible the same night. The bottom half fails quietly, and nobody notices until an auditor or a customer asks about a past outage.

Export checklist for alerts, incidents and postmortems#

The export checklist covers every history object with its IDs, in an order that gets the irreplaceable records out first. Assign one engineer as owner and a second to verify the results.

• 1Confirm dates, plan terms and API access, and record them in the export log.
• 2Pull alerts by period with IDs, priority, source, tags and created, acknowledged and closed times.
• 3Pull the log and notes for each alert, keyed by alert ID.
• 4Pull incidents with impacted services, responders, status history and linked alerts.
• 5Export postmortems, including those kept in Confluence, shared documents or a repository.
• 6Export schedule history and overrides so on-call coverage can be reconstructed.
• 7Record links from incidents to Jira issues, pull requests and releases.
• 8Reconcile counts by period against Opsgenie's own reporting, then sign the log.

Why raw API output beats CSV for incident history#

Raw API output keeps incident history intact because it preserves the nested structure of an alert or incident: its timeline, notes, responders and actions in order. A CSV flattens that structure into one row, which suits counting alerts but loses the sequence of what responders actually did.

Keep both. Store raw JSON per alert and per incident, keyed by ID, and build flattened tables for analysis. Large histories take time to pull through any rate-limited API, so start early, run by period and keep the scripts so a failed pull can be rerun without starting over.

What to scrub before anyone else sees the archive#

An Opsgenie archive needs scrubbing because alert payloads and notes carry more than incident facts. Hostnames, IP addresses, customer identifiers, email addresses and phone numbers appear routinely, and responders sometimes paste tokens or connection strings into notes in the middle of an incident.

Scan the archive with secret detection before it is shared inside or outside engineering. Open-source scanners such as Gitleaks detect passwords, API keys and tokens in files; note that its maintainer has declared it feature complete, with future releases limited to security patches. TruffleHog says it scans sources including chats, wikis and logs and can test whether a found secret is still live. That test sends real login attempts, so run it with care. Rotate anything live, then mask or remove the rest.

What the incident archive answers after the switch#

An incident archive answers questions that arrive long after the tool is gone: a customer asking for the root cause of an old outage, an auditor testing incident response, a new engineering leader looking for recurring failure patterns. Each question needs a different slice of the export, which is why partial pulls disappoint.

Organize the archive by year and by service, with a readme that explains IDs, fields, time zones and the export date. Store it where engineering leadership and security can reach it, read-only, with access logged.

Illustrative: a warehouse software company retires Opsgenie#

Illustrative: a fictional SaaS company selling warehouse management software has used Opsgenie for platform on-call since its early years. The CTO decides to move on-call to Jira Service Management, where the support team already works.

An SRE lead owns the export. Alerts and incidents are pulled by quarter through the API as raw JSON, with notes and logs keyed by ID; postmortems in Confluence are exported with their incident IDs; schedule history is saved so on-call coverage can be shown for any past incident. A security engineer runs a secret scan, finds old tokens in alert notes, and has them rotated and masked.

After the switch, the team can still answer an auditor's question about a past outage. A later review of the company's engineering records finds incidents linked to the tickets, pull requests and releases that fixed them.

How SourceX looks at incident and on-call history#

Incident history is one of the record types SourceX assesses for software companies, because a linked chain from alert to response, fix and postmortem shows how real systems fail and recover. The first fit check describes that chain in metadata; no exports are shared.

If a package proceeds through the SourceX five-step transaction, Preparation removes personal details, customer identifiers and secrets, and the SourceX Evidence Packet sets out each record set's origin, your right to license it, what the licensee may do with it, the privacy steps taken and your sign-off on release.