Why Rootly · Part three of four
How a migration to Rootly runs
Importing your schedules takes an afternoon. The harder work comes after, and our team does it with you.
How a migration to Rootly runs
On this page
We start by showing you what we found
Before anything moves, you share a read-only key and we run a full assessment of your current tenant: schedules, escalation policies, orchestration, automated actions, integrations, and the things nobody remembers configuring. What comes back is a findings report, not a pitch, and you keep it whether or not you go any further. What a good on-call migration looks like walks through what that report covers and how we run the rest.
Which tool are you leaving?
This works the same way from PagerDuty, Opsgenie, incident.io, or a process held together by a spreadsheet and a shared calendar. The audit adapts to what it finds rather than assuming a shape.
One timing note if you are on Opsgenie: Atlassian closed new sales in June 2025 and has set end-of-life for April 2027, after which the platform becomes inaccessible and anything not exported is deleted. We are sharing the date so you can plan, not to rush you. The Opsgenie comparison has the full timeline.
“We started with incident response, but then we replaced Opsgenie with Rootly On-Call because of the vast feature set and integrations.”
“The Opsgenie-to-Rootly on-call migration in particular removed a seam between "who gets paged" and "how the incident gets managed," which used to be two disconnected systems.”
Each tool has its own guide. How to leave PagerDuty without missing a page verifies the chain link by link, from alert sources to the phone in the on-call engineer's pocket. The Opsgenie migration guide covers what transfers, how to run both in parallel, and how to cut over before April 2027.
“PagerDuty was the first paging-service app I used, so when we switched to Rootly, it was really easy for me to get comfortable with it and start using it right away.”
Importing is easy. The hard part is everything around it.
Schedules and policies move cleanly. The work that needs judgment is everything around them: the escalation step leaning on a webhook nobody owns, the routing rule written for a team that no longer exists, the integration somebody built in a hurry three years ago. That is the part our team works through with you, rather than handing you a script.
We have seen what breaks migrations at large companies, and we plan for each of those problems before the work starts.
- 10,000+
- responders in the largest tenants we have migrated
- Thousands
- of schedules and escalation policies moved, including some very complicated setups
- Under an hour
- per team to switch over, in scheduled batches, with training included
A plan built from your environment, not a template
The audit produces a migration plan with real complexity and real dates, running six workstreams in parallel: account setup, alerting sources, routing, integrations, onboarding, and go-live.
- We scan and audit your environment.You share a read-only API key.We automatically audit everything from schedules, escalation policies, orchestration, automated actions, integrations, and unknown unknowns that have long been forgotten about.You get a full assessment and findings report to make informed decisions with the inventory in front of you.
- You get a tailored plan that starts with a trial.Based on the audit, we create a tailored migration plan, complete with complexity, timelines, and phases that run in parallel: account setup, alerting sources, routing, integrations, onboarding, and final go-live.
- We migrate you.We work side-by-side with two or three teams of mixed complexity first. We test everything with live traffic in a trial, then go live.We work with you to cut over the remaining teams in scheduled batches, under an hour each, fully trained end-to-end.Your old tool gets turned off when your teams trust the page.
“Terraform is the core of how we operate, and it's why we moved so fast. With Rootly, we Terraformed every integration, schedule, and escalation policy in less than two weeks. Now when a new team comes on, it takes minutes to sync and stand up their whole structure automatically.”
Phased, and reversible at every point
Your current tool stays live in parallel the entire time. There is no single moment where everything depends on Rootly being perfect, and each team turns off the old setup when it is ready, not when a date forces it.
That is how it runs at scale. These teams moved off tools that had years of configuration, custom code, and habit built around them.
Larger teams that moved to Rootly.
| Team | Replaced | What the move involved |
|---|---|---|
| DoorDash (~7,000 people) | PagerDuty, and its internal incident bot and paging bot | PagerDuty fully displaced, with no specialized tool knowledge required. |
| SoFi (~3,000 people) | Opsgenie (end of life April 2027) | A phased rollout, IT teams first as canaries, then each business unit in turn. |
| KnowBe4 (~2,500 people) | PagerDuty | Incident response standardized in Slack; 40% reduction in time to resolve, 90% of retrospectives completed. |
| SailPoint (~1,500 people) | Opsgenie (end of life April 2027) | More than 500 alert routing rules, moved with migration scripts built for their setup. |
| Webflow (~1,500 people) | PagerDuty | Incident response standardized, with trends visible across teams and services. |
| Motive (~700 people) | Opsgenie | Incident setup cut from 15–60+ minutes to seconds; 99.99% reliability at scale. |
| PandaDoc (~700 people) | Opsgenie, and five years of custom tooling built around it | Rebuilt in a few weeks; 200 hours of engineering time returned every month. |
“Rootly fit how our engineers already work. We started using it in real incidents, and it immediately brought structure and order: one channel, the right responders automatically, clear roles, and tracking by default.”
Getting your people ready matters as much as the data
The thing we watch most closely has nothing to do with data: whether every responder has installed the app and confirmed how they will be reached before cutover. Migrations rarely fail because of the import. They fail because someone's phone was never set up to ring.
“One of the main differentiators of Rootly is its team; they are always available for help and made the migration easy by providing comprehensive training sessions.”
“Setting up Rootly was smooth. The support was very clear and transparent, and also quick. It was as smooth as it can be.”
“Onboarding was extremely smooth, and the support team helped us get everything configured quickly.”
What we cannot promise
No migration of any real size is risk-free, and pretending otherwise would be the fastest way to lose your trust before we have earned it. Something eventually turns up that nobody documented: a phone-routing setup the API will not export, a maintenance window scheduled two years ago and forgotten, an escalation step firing into an internal endpoint with no owner.
What we can control is when these problems show up and that we are there to help when they do. The trial phase is designed to find them early, with a few teams and real alerts, while your current tool is still handling everything.
Two reviewers on G2 named where it took them longer:
“Although setting up basic shift rotations is straightforward, configuring non-standard, highly complex shift overrides or handling multi-timezone handoffs required some fine-tuning during the initial onboarding.”
“Our migration from other tools had a bit of a learning curve in order to match our existing IaC.”
Both describe setup that reflects years of your own decisions, which is why the plan sets aside time for it rather than promising a one-click import.
Bring your history and connect your tools
Two things belong in the migration plan rather than a later project. Connect your code host and your observability provider, because they show what changed and what is broken, and they are why the AI is useful in the first week rather than months later. And import your past incidents, because the AI learns from them from day one; without them it starts with nothing.
What does a migration actually cost you?
Two things need your own people, because nobody can do them on your behalf. Everything else on this page — moving the schedules and escalation policies, mapping alert sources to services, carrying over contact details and notification preferences, connecting single sign-on, rebuilding your team structure, reconnecting integrations, onboarding at first login — is done by our team. So the only two costs worth counting are these.
The estimate is two rates: 20 minutes per engineer to install the app and confirm how they will be paged, and one hour per team to check its rotation before cutover. Those are the only two the migration asks of your people.
The other cost is paying two vendors during the overlap. If you are leaving PagerDuty mid-contract, that is covered too. Rootly buys out up to 12 months of a remaining PagerDuty contract, so you do not pay for both tools while you move. The PagerDuty migration guide explains how it works, so a recent renewal does not decide when you get to move.
What “done” means
A migration is not done when the import finishes. The import is an afternoon. It is done when an engineer gets paged at 3 a.m., acknowledges from the Rootly app, asks the agent in Slack what changed in the last hour, and never thinks about the old tool again.
When your teams stop checking the old tool out of habit, turn it off. Not before.
The audit costs nothing and the findings report is yours either way.
The switching guide
- The caseWhy teams switch to RootlyWhat you get, what teams who switched say changed, and how Rootly compares.
- Part twoHow to run a pilot that gives a real answerScope, length, the exit criteria to write down first, and the questions to ask every vendor, us included.
- Part threeHow a migration to Rootly runsThe audit, the phased rollout, what we cannot promise, and what it costs your team.
- Part fourMaking the case inside your companySeven conversations a champion has to win, and how to answer each one.