Opsgenie end of life: preserve alert and incident history before you migrate

Why the Opsgenie retirement is a records moment

Atlassian has announced that Opsgenie is being retired and is steering customers toward the alerting and on-call features in Jira Service Management and Compass. This page does not quote dates or migration terms. Take the current end-of-support date and migration paths from Atlassian's own Opsgenie announcement and your admin console, because vendors adjust them.

Most migration plans focus on configuration: teams, schedules, rotations, escalation policies, routing rules and integrations. History is the part that gets lost. Alert timelines, acknowledgment and escalation records, responder notes, incident timelines and postmortems may not come across in full, depending on the edition and the migration route. Treat history as at risk until a test migration shows exactly what moved.

For many companies that history covers years of real incident response: what fired, who was paged, who acknowledged, what they tried, how long it took and what the postmortem concluded. That chain of signals, decisions and outcomes is the kind of multi-step work record AI developers want for training and evaluating agents, much like the PagerDuty incident timelines and postmortems other companies keep.

The migration timeline: what to do and when

Count backward from the planned cutover date, which should sit comfortably ahead of the end-of-support date.

What to preserve before Opsgenie is switched off

Preservation is ordinary IT housekeeping the client would want whether or not a license ever happens. The export goes to storage the client owns, under the client's own controls, and stays there.

• Alert history: creation, acknowledgment and close times, priority, source integration, tags and the alert activity log
• Notes and comments responders added to alerts and incidents
• Incident records: timelines, responders, affected services, status updates and resolution times
• Postmortems and post-incident reviews, with their action items
• On-call schedules, rotations and overrides, with change history where available
• Escalation policies and routing rules, saved as configuration documents
• The list of integrations that fed alerts, so history can be matched to monitoring tools later
• Heartbeat and maintenance-window records, which explain gaps and suppressed alerts

Check Opsgenie's current API documentation for alert, log, note and incident endpoints, since a script-based pull is usually the practical route for multi-year history; UI exports are better for spot checks. Plan for paging and rate limits on large accounts. Personal phone numbers and other contact details in notification logs should stay internal and have no place in any later license.

Keep the two jobs separate. If the company later licenses incident history through SourceX, the delivery export happens only after an executed agreement and the company's authorization, under de-identification rules settled before any work begins. The MSP's role in that is the introduction, not the data.

Who to talk to at the client

What to say

Raise preservation first and the licensing idea second, in the same meeting if the relationship allows.

Which clients are worth an introduction

Use a simple rule: introduce when depth, ownership and a sponsor line up.

• If the client has 50+ full-time employees at peak (contractors excluded), several years of Opsgenie use alongside ticketing and chat records, and an owner open to an exclusive license, then introduce them.
• If an MSP ran one Opsgenie account across several clients, then only each client's own records can be considered, and only by that client.
• If the client used Opsgenie for a year or two with few notes, then preserve it anyway, but the referral case rests on other systems.
• If earlier tools' archives were already deleted, then check where incident discussion also lives, such as Slack channels, Jira issues and email.

The same records-first thinking applies to a ConnectWise to HaloPSA migration, and the ServiceNow archive and retention guide covers instances where purge rules, not a vendor retirement, are the risk.

How the introduction works for an MSP

1. You register, then send the client your referral link or submit them through the referral form with basic fit details.
2. SourceX checks headcount, operating history, breadth of systems and rights with the client's sponsor.
3. The client lists its systems and years of history in a data inventory; the data inventory builder is a good starting point.
4. Price and terms are agreed with the client before buyers see anything, and buyers then review.
5. When a deal closes, the client delivers the agreed data and is paid, and your reward follows once SourceX receives its fee.

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company. Rewards are paid only after the buyer pays and SourceX receives its fee, and no reward is guaranteed. More MSP-specific guidance sits on the managed service providers page.

Next step

Put the Opsgenie history question on the agenda for each affected client's next quarterly business review. Where a client fits the who qualifies baseline, register as a partner and introduce them, or let the sponsor apply directly at sourcex.si/apply.