Cross-posted from the Fluidify blog. Disclosure: I work on FluidifyAI Regen.
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. If you're still on it, here's a concrete migration path, what transfers automatically, and what doesn't.
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.
Independent estimates put a typical Opsgenie migration at six to sixteen weeks depending on integration count and how customized your escalation setup is. That still leaves time if you're reading this in 2026, but "still leaves time" is exactly the situation where migrations quietly slip for another two quarters.
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 and a 120-day window of parallel access to Opsgenie. If your team is already deep in the Jira ecosystem, that's the path of least resistance, read Atlassian's own migration documentation for the specifics.
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, want off per-seat pricing, or want a self-hosted option Atlassian doesn't offer. That's the path this covers, using Regen as the destination.
Step-by-step: migrating to Regen
1. Stand up Regen alongside Opsgenie, don't cut over yet: Self-hosted (free, AGPLv3) or managed cloud, run it in parallel with Opsgenie for the whole migration.
2. Connect your Opsgenie account for migration: Regen's migration path reads your existing config through Opsgenie's API using a read-only integration key. Nothing changes on the Opsgenie side.
3. Review what gets pulled in: Schedules, rotations, escalation policies, and existing integrations. Review each against what's actually live, migrations are the natural point to prune years of drift.
4. Rebuild anything that doesn't map cleanly: Custom Opsgenie routing rules and any tightly-coupled scripts calling its API directly need rebuilding against Regen's equivalent. Budget real time here, it's usually the long pole, not the schedule import.
5. Point a subset of alert sources at Regen, in parallel: Redirect a low-risk source first (staging, a non-critical service), confirm the full path: fires, routes, escalates, notifies correctly.
6. Run both systems in parallel for real incidents: For at least one full on-call rotation, let Regen receive alerts alongside Opsgenie without decommissioning it. This is where subtle escalation-policy differences surface.
7. Cut over integrations fully, one at a time: Once a full rotation runs clean, redirect each remaining integration. Keep Opsgenie read-accessible for historical data.
8. Decommission Opsgenie on your own schedule, ahead of April 5, 2027: Export anything you need for historical record first.
What doesn't migrate automatically
- Historical incident and alert data. Export it from Opsgenie separately if you need it for compliance or reporting.
- Opsgenie-specific automations referencing Opsgenie object IDs directly, rewrite against Regen's API.
- Custom integrations built against Opsgenie's exact webhook payload shape. Most monitoring tools support a generic webhook format both platforms consume.
A realistic timeline
For a mid-sized team: weeks 1-2 stand up + review, weeks 3-4 rebuild + first low-risk integrations, weeks 5-8 parallel run across production, weeks 9-10 full cutover, week 11+ export and decommission. That's on the faster end of the six-to-sixteen-week range other teams report generally, largely because the 1-click import removes the slowest part.
Why teams choose Regen over the JSM path
Regen has no per-seat pricing (free self-hosted, unlimited users), where JSM's tiers carrying the alerting features are priced per agent. Regen runs self-hosted, VPC, or air-gapped, which JSM doesn't offer. Regen includes AI-generated incident post-mortems (BYOK: OpenAI, Anthropic, Ollama), which isn't part of what's moving into JSM.
FAQ
Do we have to migrate before April 5, 2027? Yes, in the sense that data is deleted on that date. Start with enough runway for a parallel run, six to ten weeks minimum.
Can we run Regen and Opsgenie at the same time? Yes, that's the recommended path here.
Does the migration bring over incident history? No, live configuration only. Export history separately.
What if we have heavily customized routing rules? Budget time to rebuild those manually, typically the longest step.
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. Talk to us if you want a second pair of eyes on the plan.
Top comments (0)