# How a migration to Rootly runs

URL: https://rootly.com/why-rootly/migrations

> How a migration to Rootly runs: a free, read-only audit first, then a phased rollout with your current tool live throughout, the work our team does for you, and what we cannot promise.

Why Rootly · Part three of four

Importing your schedules takes an afternoon. The harder work comes after, and our team does it with you.

[Book a demo](https://rootly.com/demo)

How a migration to Rootly runs

1. We start by showing you what we found
2. Which tool are you leaving?
3. The hard part comes after the import
4. A plan built from your environment
5. Phased, and reversible at every point
6. Getting your people ready
7. What we cannot promise
8. Bring your history and connect your tools
9. What a migration costs you
10. What “done” means
11. The switching guide

### On this page

1. We start by showing you what we found
2. Which tool are you leaving?
3. The hard part comes after the import
4. A plan built from your environment
5. Phased, and reversible at every point
6. Getting your people ready
7. What we cannot promise
8. Bring your history and connect your tools
9. What a migration costs you
10. What “done” means
11. The switching guide

## 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](https://rootly.com/blog/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](https://rootly.com/alternatives/rootly-vs-opsgenie) 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.”

Paul van Liew, Director of Platform Engineering, [Motive](https://rootly.com/customers/motive)

> “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.”

[Verified review on G2](https://www.g2.com/products/rootly/reviews/rootly-review-13144978), July 2026

Each tool has its own guide. [How to leave PagerDuty without missing a page](https://rootly.com/blog/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](https://rootly.com/blog/opsgenie-migration-to-rootly-complete-step-by-step-guide-for-a-smooth-transition-2026) 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.”

[Verified review on G2](https://www.g2.com/products/rootly/reviews/rootly-review-13329014), August 2026

## 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.

1. **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.
2. **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.
3. **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.”

Pedro Espindula, SRE, [Cora](https://rootly.com/customers/cora)

## 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](https://rootly.com/alternatives/rootly-vs-pagerduty) (~7,000 people) | PagerDuty, and its internal incident bot and paging bot | PagerDuty fully displaced, with no specialized tool knowledge required. |
| [SoFi](https://rootly.com/alternatives/rootly-vs-opsgenie) (~3,000 people) | Opsgenie (end of life April 2027) | A phased rollout, IT teams first as canaries, then each business unit in turn. |
| [KnowBe4](https://rootly.com/customers/knowbe4) (~2,500 people) | PagerDuty | Incident response standardized in Slack; 40% reduction in time to resolve, 90% of retrospectives completed. |
| [SailPoint](https://rootly.com/alternatives/rootly-vs-opsgenie) (~1,500 people) | Opsgenie (end of life April 2027) | More than 500 alert routing rules, moved with migration scripts built for their setup. |
| [Webflow](https://rootly.com/customers/webflow) (~1,500 people) | PagerDuty | Incident response standardized, with trends visible across teams and services. |
| [Motive](https://rootly.com/customers/motive) (~700 people) | Opsgenie | Incident setup cut from 15–60+ minutes to seconds; 99.99% reliability at scale. |
| [PandaDoc](https://rootly.com/customers/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.”

Matthew Duren, VP of Engineering, [KnowBe4](https://rootly.com/customers/knowbe4) · switched from PagerDuty

## 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.”

[Verified review on G2](https://www.g2.com/products/rootly/reviews/rootly-review-12924137), June 2026

> “Setting up Rootly was smooth. The support was very clear and transparent, and also quick. It was as smooth as it can be.”

Usama Blavins, Senior Platform Engineer, [UNiDAYS](https://rootly.com/customers/unidays)

> “Onboarding was extremely smooth, and the support team helped us get everything configured quickly.”

[Verified review on G2](https://www.g2.com/products/rootly/reviews/rootly-review-13677213), October 2026

## 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.”

[Verified review on G2](https://www.g2.com/products/rootly/reviews/rootly-review-13647268), September 2026

> “Our migration from other tools had a bit of a learning curve in order to match our existing IaC.”

[Verified review on G2](https://www.g2.com/products/rootly/reviews/rootly-review-13341021), August 2026

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](https://rootly.com/blog/how-to-leave-pagerduty-without-missing-a-page) 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

1. The case [Why teams switch to Rootly](https://rootly.com/why-rootly) What you get, what teams who switched say changed, and how Rootly compares.
2. Part two [How to run a pilot that gives a real answer](https://rootly.com/why-rootly/pilot) Scope, length, the exit criteria to write down first, and the questions to ask every vendor, us included.
3. Part three **How a migration to Rootly runs** The audit, the phased rollout, what we cannot promise, and what it costs your team.
4. Part four [Making the case inside your company](https://rootly.com/why-rootly/pitch) Seven conversations a champion has to win, and how to answer each one.

[Book a demo](https://rootly.com/demo) · [Next: making the case inside your company](https://rootly.com/why-rootly/pitch)