Software companies

Opsgenie end of support: how to keep your alert and incident history

By SourceX Editorial · Updated October 9, 2026

Short answer

To keep your alert and incident history through Opsgenie end of support, export it yourself before the shutdown date instead of relying on migration tooling to carry everything. Pull alerts with their notes and activity, incidents, postmortems, schedules and escalation policies as raw JSON, verify counts, and store them with links to your Jira and code history.

Key takeaways

Treat end of support as a deadline for your own export, not only for choosing a new on-call tool.
Migration tools focus on keeping paging working; confirm whether they also carry full alert and incident history.
Export raw records with stable identifiers so alerts can later be joined to Jira issues and commits.
Postmortems and responder notes are the hardest records to recreate, so export them first.
Incident history keeps its value for reliability reviews, audits and, potentially, licensing as linked engineering records.

What does Opsgenie end of support mean for your history?#

Opsgenie end of support means the history inside it has an expiry date unless you move it somewhere you control. Atlassian has announced end of sale and end of support for Opsgenie and published migration guidance for existing customers. The exact dates, and what happens to stored data, are set out in Atlassian's notices and may differ by plan, so read the current notice for your subscription rather than a secondhand summary.

Most migration planning looks forward: which tool takes over paging, how schedules and escalation policies are rebuilt, and how integrations are rewired. The past gets less attention. Years of alerts, acknowledgments, notes, incidents and postmortems record how your team detected and recovered from failures, and they are the part least likely to survive a rushed cutover.

Which Opsgenie records should you export?#

The Opsgenie records worth exporting are the ones that explain what happened and why people acted as they did. Configuration matters for the cutover, but the historical record is what you cannot get back.

If you can only export part of this, put incidents, postmortems and alert notes first. Configuration can be rebuilt in the new tool; decisions people wrote down in the middle of an outage cannot.

Which Opsgenie records should you export?
Record	Why keep it	Export note
Alerts	Show what fired, when, at what priority and from which integration	Include tags, source, priority, acknowledgment and close times
Alert notes and activity	Record who did what during a response, in their own words	Often held separately from the alert itself; export both
Incidents	Group related alerts and record impact and status changes	Keep incident to alert relationships and responder lists
Postmortems	Explain causes, decisions and follow-up actions	Export the text and any linked Jira issue keys; if no export route covers them on your plan, copy them out manually and note it in the readme
Schedules and overrides	Show who was on call when each alert fired	Needed to read response times fairly
Escalation policies and routing rules	Explain why a particular person was paged	Keep earlier versions if the rules changed
Teams, users and integrations	Map identifiers in other records to people and systems	Replace contact details with stable internal IDs

How to export and verify the history#

Exporting Opsgenie history is safest as a separate project with its own owner, finished before the migration cutover rather than after it. The steps assume API access and an engineer who can write a short export script; adjust them to the routes Atlassian documents for your plan.

Expect gaps. Rate limits, retention settings and integrations retired long ago can leave holes in older periods. Write them into the readme instead of trying to fill them, so anyone using the archive later knows where it is thin.

Step 1: read Atlassian's current end-of-support notice and note the last date you can sign in and call the API.
Step 2: inventory teams, integrations and the oldest alerts you can still see.
Step 3: export raw JSON for alerts, notes, activity, incidents and postmortems, paging through by date.
Step 4: export schedules, overrides and escalation policies, including earlier versions where available.
Step 5: record counts per month and per team as you go, and compare them with the product's own reports.
Step 6: hash the export files and store them in your own encrypted storage with an access list.
Step 7: write a short readme covering fields, gaps, identifiers and the export date.

Does the migration tool carry your history?#

A migration tool may not carry your full history, so confirm what it moves before relying on it. Tools built to move a team onto a new platform usually prioritize users, schedules, escalation policies and integrations, because those keep paging working on day one. Historical alerts, notes and postmortems may move partially, move without their relationships, or not move at all.

Put the same questions to whichever path you choose, whether another Atlassian product or a third-party on-call tool. Does historical alert data move, and from what date? Do notes, activity entries and incident relationships move with it? Do identifiers stay stable, so a moved alert can still be matched to the Jira issue that referenced it? If any answer is no or unclear, run your own export as well.

Why incident history keeps its value#

Incident history keeps its value long after the paging tool is gone, because it is one of the few records that captures operational decisions under time pressure. Engineering leaders use it to find recurring failure patterns and review on-call load. Auditors assessing controls for frameworks such as SOC 2 may ask for evidence of incident response. Postmortems feed onboarding and architecture decisions.

Incident records can also be relevant to AI developers building agents for IT operations and reliability work, particularly when an alert links to the incident, the postmortem, the Jira follow-up and the commit that fixed the cause. Those chains are only possible if alert history and its identifiers survive the migration. Whether a particular archive can be licensed depends on rights, privacy preparation and buyer interest, all assessed case by case.

Illustrative: a telematics software company keeps its on-call history#

Illustrative: a fictional fleet telematics software company has paged through Opsgenie for years, with alerts from its monitoring tools and incidents linked to Jira postmortem tickets. When the team selects a new on-call tool, the CTO assigns one engineer to export history separately from the cutover.

The engineer exports alerts, notes, activity and incidents month by month, keeps incident to alert relationships, and checks counts against the product's reports. Alerts from a retired integration turn out to have no notes, and the readme says so. On-call phone numbers are replaced with internal user IDs. Later, when the company runs a reliability review and a data licensing fit check, both start from the same archive.

What to do with the archive after cutover#

An exported Opsgenie archive needs an owner and a few decisions after cutover, or it becomes another unlabeled folder nobody trusts. The work is small, and it is easiest while the engineer who ran the export still remembers the gaps.

Joining alerts to engineering records is the step that adds the most later value. Many postmortems and alert notes already mention Jira issue keys, so a simple pass that extracts those keys turns an isolated paging history into the start of a linked incident record.

Name an owner for the archive and record who may access it.
Extract Jira issue keys from postmortems, notes and alert descriptions into a separate link file.
Set a retention rule for the archive that matches your audit and legal hold policies.
Keep a copy of the readme and the file hashes beside the archive itself.
Record the new tool's first alert date, so the two histories can be joined later without overlap or gaps.

How SourceX approaches retired incident tools#

SourceX treats a tool retirement as a reason to preserve records first and decide later. In the Supply step of the SourceX five-step transaction, an exported incident archive is described by metadata only: systems, date ranges, record types and links to issues and code. Nothing is shared during that assessment.

If a package proceeds, the SourceX Evidence Packet records the export date, the gaps listed in the readme and how responder details were removed, so the archive's limits are stated before anyone relies on it.

Frequently asked questions

Will Atlassian delete our Opsgenie data at end of support?

Check Atlassian's current notice for your plan, which describes what happens to stored data and when. The safe planning assumption is that anything you have not exported may become inaccessible after the end-of-support date, so finish your own export before then rather than counting on later access.

Do we need to export alerts nobody acted on?

Low-priority alerts that closed automatically matter less one by one, but together they show noise levels and alert fatigue over time. If effort allows, export everything and filter later. If not, keep every alert linked to an incident, plus monthly counts by source for the rest.

What personal data sits in on-call records?

On-call records usually hold names, email addresses, phone numbers and notification preferences, plus responders' notes written in their own words. Replace contact details with stable internal IDs in the archive, restrict access to it, and review notes before any wider use.

Should we keep the raw JSON or convert it?

Keep the raw JSON, with hashes, as the record of what the system held, and build any tables or spreadsheets from it. Converted formats are easier to read but often drop nested fields such as activity entries and responder lists that turn out to matter later.

Can we still export after switching to the new tool?

Only while your Opsgenie access lasts, and access may narrow as end-of-support dates pass. Running both tools in parallel for a short period gives time to finish and verify the export, but treat the cutover as the moment to confirm the archive is complete rather than a reason to postpone it.

Related resources

See if your company qualifies

A short company assessment. No data uploads are needed.

Inventory your incident and engineering records Talk to SourceX