Key takeaways
- Opsgenie stopped selling new licenses on June 4, 2025, and Atlassian shuts it down completely on April 5, 2027. Data left on the platform after that date is deleted.
- Atlassian's own migration path folds Opsgenie into Jira Service Management. If you don't want your on-call and alerting tied to the JSM suite, this is the point to move to a dedicated tool instead, and the clock is the same either way.
- FluidifyAI Regen has a 1-click migration path for Opsgenie schedules, escalation policies, and integrations. This walkthrough covers what it pulls in automatically, what still needs a manual pass, and a realistic timeline given the deadline.
The dates that matter
Opsgenie's end-of-sale was June 4, 2025: no new purchases, no new trials. Existing customers keep running until the full shutdown on April 5, 2027, when the platform becomes inaccessible and unmigrated data is permanently deleted. That's the real deadline, not the end-of-sale date, but planning as if the deadline were closer than it is buys you room for a slow rollout instead of a rushed one.
Independent estimates put a typical Opsgenie migration at six to sixteen weeks depending on integration count and how customized your escalation setup is. If you're reading this in 2026, that math still leaves time, but "still leaves time" is exactly the situation where migrations quietly slip for another two quarters. Pick a date now.
Two paths off Opsgenie
Atlassian's own answer is Jira Service Management: alerting and on-call features move into JSM's Premium and Enterprise tiers, with an automated migration tool that transfers schedules, escalation policies, and incident workflows, and Atlassian offers a 120-day window of parallel access to Opsgenie during the switch. If your team is already deep in the Jira ecosystem and wants to consolidate, that's the path of least resistance, and it's worth reading Atlassian's own migration documentation for the specifics of that offer, since the parallel-access window and automated tooling described there are Atlassian's, not something a third-party migration replicates.
The other path is moving to a dedicated on-call and incident tool instead of folding into JSM, either because you don't want on-call tied to a ticketing suite, you want to get off per-seat pricing, or you want a self-hosted option Atlassian doesn't offer. That's the path this walkthrough covers, using Regen as the destination. For a feature-by-feature look at how Regen and Opsgenie compare outside of the migration itself, see our Opsgenie alternatives comparison; if you want the destination platform in the context of other open-source options too, our open-source on-call tools rundown covers that ground.
Step-by-step: migrating to Regen
1. Stand up Regen alongside Opsgenie, don't cut over yet: Self-hosted (free, AGPLv3) or managed cloud, either way, run it in parallel with Opsgenie for the whole migration. Nothing gets decommissioned until the new setup is verified.
2. Connect your Opsgenie account for migration: Regen's Opsgenie migration path reads your existing configuration through Opsgenie's API using a read-only integration key you generate from Opsgenie's settings. Nothing is changed on the Opsgenie side at this step.
3. Review what gets pulled in: The migration brings across on-call schedules and rotations, escalation policies, and existing integrations (the alert sources pointing at Opsgenie). Review each one against what's actually live in Opsgenie today, teams accumulate stale schedules and abandoned escalation policies over years, and a migration is the natural point to prune them rather than faithfully reproduce five years of drift.
4. Rebuild anything that doesn't map cleanly: Not everything transfers as a clean one-to-one. Custom Opsgenie routing rules built on more advanced conditions, and any tightly-coupled Opsgenie-specific automations or scripts calling its API directly, will need to be rebuilt against Regen's equivalent (routing rules, or direct API calls) rather than assumed to carry over automatically. Budget real time for this step, it's usually the long pole in the migration, not the schedule import.
5. Point a subset of alert sources at Regen, in parallel: Don't switch every integration at once. Redirect a low-risk alert source first, a staging environment, a non-critical service, and confirm the full path works: alert fires, routes correctly, escalates on the policy you expect, notifies the right channel.
6. Run both systems in parallel for real incidents: For at least one full on-call rotation cycle, let Regen receive alerts alongside Opsgenie for your production services, without Opsgenie fully decommissioned. This is where you catch the escalation policy that behaves subtly differently, or the schedule override that didn't carry across correctly, before it matters during a real page.
7. Cut over integrations fully, one at a time: Once the parallel run has covered a full rotation without surprises, redirect each remaining alert source's webhook or integration to Regen. Keep Opsgenie read-accessible during this window in case you need to check historical data.
8. Decommission Opsgenie on your own schedule, ahead of April 5, 2027: Export anything you need for historical record (past incident data, old schedules) before the account goes inactive. Don't wait for the shutdown date to force this step.
This is also the natural point to stop editing escalation policies only through a UI. If schedules and escalation policies are getting rebuilt from scratch anyway, setting them up as version-controlled config from day one is less work than migrating them again later.
What doesn't migrate automatically
Be honest with your team about this list before you start, it prevents the migration from feeling like it broke something when really it just didn't carry over a thing that was never going to transfer cleanly:
- Historical incident and alert data. Regen's migration path brings over live configuration, not Opsgenie's incident history. If you need that history for compliance or reporting, export it from Opsgenie separately before decommissioning.
- Opsgenie-specific automations built on its own scripting or API that reference Opsgenie object IDs directly, these need to be rewritten against Regen's API, not translated automatically.
- Any custom integrations built against Opsgenie's specific webhook payload format. Most monitoring tools support a generic webhook format both platforms can consume, but a hand-built integration that assumes Opsgenie's exact JSON shape will need updating.
A realistic timeline
For a mid-sized team (a few dozen services, a handful of escalation policies, moderate integration count):
- Weeks 1 to 2: Stand up Regen, run the migration import, review schedules and escalation policies against what's live in Opsgenie.
- Weeks 3 to 4: Rebuild anything that didn't map cleanly, redirect the first low-risk integrations, verify end-to-end.
- Weeks 5 to 8: Parallel run across production services, covering at least one full on-call rotation.
- Weeks 9 to 10: Full cutover, integration by integration, keeping Opsgenie read-accessible.
- Week 11 onward: Export historical data, decommission Opsgenie.
That's on the faster end of the six-to-sixteen-week range other teams report for Opsgenie migrations generally, largely because the 1-click import removes the slowest part, manually recreating every schedule and escalation policy by hand.
Why teams choose Regen specifically over the JSM path
If you're evaluating whether to fold into Jira Service Management or move to a dedicated tool, the actual differences that matter: Regen has no per-seat pricing (free self-hosted under AGPLv3, unlimited users), where JSM's Premium/Enterprise tiers that carry the alerting features are priced per agent. Regen runs self-hosted, VPC, SaaS or air-gapped if that's a requirement, which JSM doesn't offer. And Regen includes AI-generated incident post-mortems, bring-your-own-key with OpenAI, Anthropic, or Ollama, which isn't part of what's moving into JSM. The tradeoff is the reverse of Opsgenie-to-JSM: you're not consolidating into a suite you may already be paying for, you're adding a dedicated tool, which is the right call if on-call and incident response deserve their own platform rather than a module inside your ticketing system.
FAQ
Do we have to migrate before April 5, 2027? Yes, in the sense that Opsgenie becomes inaccessible and your data is deleted on that date. You don't have to migrate today, but starting with enough runway for a parallel run, six to ten weeks at minimum, is what keeps this from becoming a scramble in early 2027.
Can we run Regen and Opsgenie at the same time during the transition? Yes, that's the recommended path in this walkthrough. Run both in parallel, redirect integrations gradually, and don't decommission Opsgenie until you've verified a full on-call rotation on the new setup.
Does the migration bring over our incident history? No. It migrates live configuration (schedules, escalation policies, integrations), not historical incident data. Export anything you need for records before decommissioning Opsgenie.
What if we have heavily customized Opsgenie routing rules? Those are the part most likely to need manual rebuilding rather than automatic migration. Budget time for this specifically, it's typically the longest step in the process, not the schedule or escalation policy import.
Getting started
Stand up FluidifyAI Regen self-hosted for free, or on Managed Cloud starting at $100/month, and run the migration against a read-only Opsgenie integration key to see what transfers before committing to anything. If your setup has enough custom routing or automation that you want a second pair of eyes on the plan, talk to us and we'll walk through it with you directly.