Opsgenie end of life is 5 April 2027. Atlassian announced it in March 2025 and closed the product to new customers on 4 June 2025, so anyone still running it has been on a product with a published expiry date for well over a year.
That is unusually generous notice for a shutdown. It is also why so many teams have not started, and why the deadline will still surprise people.
The dates
| March 2025 | Announced |
| 4 June 2025 | End of sale. No new customers or trials. Existing customers can still add seats. |
| 5 April 2027 | End of life. Data not migrated by this date is permanently deleted. |
Note the shape of that last one. This is not a case where access ends and the data sits in cold storage while you sort yourself out. The published position is deletion at shutdown.
Where Atlassian wants you to go
Into Jira Service Management, with alerting folded into the Premium and Enterprise tiers, and Compass for service cataloguing. Opsgenie is not being replaced by one thing so much as absorbed into two.
Two consequences worth pricing before you assume the in-house path is the easy one.
The alerting capability lands in higher JSM tiers, so the migration may carry a tier upgrade with it. If you are on a lower tier today, the cost of staying with Atlassian is not zero, and it is worth getting that number early rather than at renewal, when it becomes a different conversation. That is a familiar pattern, and we wrote about the general version in legacy plan sunsets.
The second is a scope question. Opsgenie was a focused on-call and alerting product. If the replacement is a service management platform plus a service catalogue, you are adopting more surface area than you retired, and adoption of surface area you did not ask for is where migration timelines go wrong.
How long it actually takes
Longer than a feature comparison suggests, and this is the number to plan around.
Teams that have done it report six to sixteen weeks depending on integration count. Straightforward setups still land at six to eight. On-call tooling is unusually entangled: escalation policies, rotation schedules, overrides, holiday handling, and an integration for every monitoring system you run. Each of those is small and none of them are optional.
The approach that consistently works is a parallel run. Configure the new platform, page both systems for two to four weeks, verify that the new one fires correctly for real incidents, then cut over. Nobody wants to double-page their on-call engineers. Everybody who skipped it has a story about the alert that did not arrive.
Rotations and escalation policies are also the part that does not export cleanly. Expect to rebuild rather than import, and budget for someone who understands why the current policies are shaped the way they are, because half of that logic exists because of an incident nobody wrote down.
Reading the alternatives
Search this and you will find a large number of migration guides published by incident management vendors. Several are genuinely good, particularly on export mechanics and on the parts of the migration that bite, because these companies have run the process many times.
They also all conclude that you should move to them. Use them for the mechanics and build your own shortlist. CopperFeed does not rank tools, so this page will not hand you one either.
If you have not started
You have roughly twenty months at the time of writing, which sounds comfortable and is not once you subtract a procurement cycle, a parallel run, and the fact that nobody will prioritise this until it is urgent.
- Export the configuration now. Schedules, escalation policies, integration list, team structure. Not because you are migrating today, but because that export is the requirements document for whatever you choose.
- Price the JSM path properly. Including any tier change. It is the baseline every alternative gets compared against, and you cannot compare without it.
- Count your integrations. This single number predicts your timeline better than anything else.
- Book the parallel run in the calendar. Working backward from April 2027, not forward from whenever the project starts.
The general version of this is in Your Vendor Is Shutting Down. CopperFeed records retirements as they are announced.
Dates and migration timings here come from Atlassian’s published announcements and from practitioner and vendor accounts, attributed where linked. Verify current dates against Atlassian directly before planning against them.