The moment that defines a migration
Every on-call migration comes down to a single moment you cannot rehearse: the first real page after cutover. Either it reaches the right engineer on the new system, or it does not. Everything that happens before that moment exists to make sure it does.
Rootly has run that moment thousands of times, across tenants as large as 10,000+ responders. The teams that come through it in good shape do three things, and the teams that struggle skip one of them. They get the data right; they handle the edge cases an importer skips; they get their people ready.
Most of the attention goes to the first. The trouble almost always lives in the other two. Rootly treats all three as real work. The rest of this guide walks through how.
Key dates
Opsgenie set patterns for on-call scheduling and alerting that became industry standards. After Atlassian acquired it in 2018, development stalled, and the platform is now sunsetting.
- June 2025: New Opsgenie sales closed.
- April 2027: End-of-life. The platform becomes inaccessible. Any data not exported or migrated by then will be deleted.
That gives you about a year of practical runway. The right way to use it is not to wait.
What we find when we look at your tenant
Before anything moves, Rootly runs a read-only audit of your Opsgenie tenant and hands you a findings report, not a pitch. A clear map of what you have, so the decisions that follow get made with the same picture in view, and so you can set expectations with your own leadership without guessing.
Here is what one looked like on a recent enterprise migration:
Migration audit: enterprise tenant, Q3 2026
Responders: 2,800+
Contact methods and notification rules: 30,000+ (>5 paging touchpoints per responder)
Schedules: 1,247
↳ 49 with sub-24-hour rotation frequencies, flagged for special handling
Services: 805
↳ 318 with business-hours or timezone-dependent urgency, mapped service-by-service
Integrations: 90
↳ 32 with non-standard formats, mapped individually
Legacy rulesets named "test", "old", or similar: 27 (dead code, recommend deprecation)
Duplicate policy names: 0
Custom event-routing rules: 0
Day-one importable footprint: 95.4%
Estimated trial-to-cutover timeline: 6 weeks
The two numbers that told us how clean the job would be are at the bottom. Duplicate policy names mean rename work before anything can import. Custom event-routing rules are the single largest source of migration risk at this scale. This tenant had neither.
A clean tenant gets a short report. A messy one gets a longer one. Either way, we collectively commit to a date with the inventory in front of you.
The work that needs judgment is the long tail
The bulk import is rarely where migrations get hard. The long tail is.
Look back at the audit. Those 49 schedules with sub-24-hour rotation frequencies are >1% of the total, and they are the kind of detail that slips through and resurfaces as a dropped page three weeks later. The 318 services with timezone-dependent urgency get mapped to dynamic escalation paths and checked service by service with the team that owns them. Timezone logic does not go through a standard import and hope. The 32 integrations with non-standard formats each get mapped to the new schema and confirmed with you after import. The 27 legacy rulesets named "test" are dead code, and the right move is to keep what actually matters and let the rest go.
None of this surprises us. The edge cases have names, counts, and a plan before the migration begins. That is what experience buys you. Not the absence of hard parts, but the absence of nasty ones.
What Rootly migrates
The migration is API-driven and read-only. Rootly never modifies or deletes anything in your Opsgenie account, which means both systems can run in parallel for as long as you want during the transition, or at least until April 2027.
Users: Matched by email. Existing Rootly users (including soft-deleted) are reused. New users are created automatically with name and timezone populated from Opsgenie.
Teams: Become Rootly groups. Membership preserved. Routing rules import alongside.
Schedules: Definitions, rotations, overrides, and future shift generation transfer. Overlapping rotations can import as one schedule or split per rotation, depending on which model is clearer.
Services(optional): Match by ID first, then by name. If a name collides, the Opsgenie service ID is appended so you can tell them apart.
A few pieces need explanation:
Notification rules. Each Opsgenie notification rule step translates into a Rootly notification rule. Email, SMS, and voice contact methods map cleanly, and step delays preserve the original timing so responders are paged at the intended offset. After import, Rootly seeds any missing default rules so no responder ends up with a partial configuration.
Slack integration. Conditional. Imported only when Slack is in scope, your Rootly workspace already has a Slack integration connected, and you specify which Opsgenie teams should have their Slack configuration imported. Otherwise it is skipped, which keeps the resulting setup deterministic rather than half-configured.
How the rollout actually runs
Phased and reversible. Both matter as much to the person signing off as to the engineer carrying the pager. Opsgenie stays live in parallel the whole time until we all trust the page.
- Read-only audit. You provide a read-only Opsgenie API key. Rootly scans schedules, escalation policies, integrations, automated actions, and the long tail of forgotten configuration. You get a full assessment and findings report.
- Tailored migration plan. Based on the audit, Rootly produces a plan with complexity, timelines, and phases: account setup, alerting sources, routing, integrations, onboarding, and go-live.
- Trial with two or three teams first. Mixed complexity, real traffic, both systems live. The unknowns surface here, on a small surface, while Opsgenie is still carrying the load. When something appears, it is ours to solve with you. Not a ticket you file and wait on.
- Phased cutover. Remaining teams cut over in scheduled batches, typically under an hour each, fully trained end-to-end. By this stage the hard parts are already solved, so this phase stays boring on purpose.
- Opsgenie gets turned off when your teams trust the new pager. Not when a date forces it.
A dedicated implementation engineer and a CSM stay with you through cutover and beyond, with a shared Slack channel and an urgent escalation path.
"All our users had to do was link their Slack and download the mobile app. That's it. We didn't miss a beat." -Paul Van Liew, Director of Platform Engineering, Motive
What we cannot promise
No on-call migration is risk-free, and pretending otherwise is the fastest way to lose your trust before we have earned it.
On a tenant of any real size, something eventually turns up that nobody documented. A phone-routing setup the Opsgenie API will not export, so it has to be rebuilt by hand. A maintenance window someone scheduled two years ago and forgot. An escalation step that quietly leans on a webhook firing into an internal endpoint nobody owns anymore.
What Rootly controls is when those things surface, and who is standing next to you when they do. The trial phase exists to bring the unknowns out on a small surface, on real traffic, while Opsgenie is still carrying the load. When one appears, it is ours to solve with you.
Getting your people ready matters as much as getting the data right
Here is the part with nothing to do with data fidelity, and it is the one we watch most closely: whether your responders installed the new app and confirmed how they will be reached before cutover.
It is the most common issue across every migration we run. Schedules can be perfect and escalation paths flawless, and a page still goes nowhere because the on-call engineer never opened the app, so it waits in a notification tray they will not check until morning. That is not a data problem. It is a human one, and it does not solve itself.
Rootly treats responder readiness as a real workstream:
- Two communication waves before cutover.
- In-product nudges so responders do not have to remember to set up their targets.
- A 30-minute responder training that respects people's time.
- An admin dashboard that tracks install and verification per person, so the person signing off knows exactly who is covered before you switch.
The mobile app is its own piece of this. Rootly is the only on-call mobile app with AI built in. Responders can ask questions, get incident context, and triage from the app itself, not just receive a notification and then alt-tab to a laptop. Custom ringtones make sure pages get attention. The point is not the feature list. The point is that responders have a reason to actually open the app, which is what makes the first real page reach the right person.
What you get the day after cutover
Opsgenie's footprint ends at alerting and on-call. Rootly's does not. Once you are on the new system, the same platform handles incidents, retrospectives, and analytics. Most teams find that the operational value compounds quickly, because the same context that triggered a page carries through to the retrospective two days later.
A few capabilities worth knowing about:
@Rootly agent in Slack. Declare incidents, page responders, assign roles, update status pages, and ask questions about your environment from a conversational agent inside the channel where your team already works. Opsgenie gave you chat notifications. The Rootly agent gives you an operator.
AI in retrospectives. Customer AI Blocks pull summaries, timelines, contributing factors, and action items directly into the retrospective document, so writing them stops being the bottleneck it usually is. And the prompts are transparent and editable so you’re not stuck dealing with a blackbox.
Alerts and incidents, separated by design. Opsgenie treated the two as largely synonymous. Rootly keeps them distinct. Alerts represent signals from your monitoring tools. Only the alerts that meet defined criteria escalate into incidents. That reduces noise and keeps responders focused on situations that actually need a human.
The takeaway is replacing on-call is a forcing function. You can replace it with another paging tool, or you can replace it with a platform that handles the rest of the incident lifecycle too. The cost of doing both at once is roughly the cost of doing the first.
A note on Atlassian's proposed alternatives
Atlassian suggests migrating to Jira Service Management or Compass. Neither was built for engineering incident response.
JSM is an IT service desk with bolt-on alerting. Per-agent pricing starts at $22/month, and the alerting features sit behind the Premium tier at $49/agent/month. Compass is a developer portal and service catalog with limited alerting and minimal Slack functionality. Both are part of Atlassian's ITSM suite. Neither was designed for the people carrying the pager.
If you are evaluating either, the question worth asking is whether you want to replace Opsgenie with the same company that let it go end-of-life, or with a platform built specifically for the work your responders do.
Who runs on Rootly
Hundreds of organizations rely on Rootly for on-call and incident response, from fast-moving startups to Fortune 500 enterprises. Cisco, NVIDIA, Figma, Canva, SoFi, DoorDash, Squarespace, LinkedIn, Dropbox, Superhuman, Elastic, and TripAdvisor are just some on the list.
"Rootly has been our best investment in terms of ROI." -Geoff Powell, Senior Technical Manager for SRE, Tripadvisor
What to do next
If your evaluation is already underway, book a free migration assessment. Rootly will scan your tenant and show you what is in it, then walk through the findings with you. That is the same audit the rest of the migration runs on, and the findings are yours regardless of whether you move forward.
We do not call the migration done when the data lands. We call it done when your team trusts the pager. And we stay with you well past that.
