Migrating From PagerDuty

​

Overview

Migrating from PagerDuty to Rootly On-Call is an API-driven import process that recreates your paging configuration in Rootly so you can cut over with confidence. The migration is designed to preserve the structure your responders rely on—who is on-call, how alerts escalate, and how responders are notified—while also applying Rootly’s operational guardrails (for example, preventing schedule dependency loops and ensuring notification rules remain actionable). A typical migration has two goals:

1. Parity at cutover: responders can acknowledge and resolve alerts in Rootly with familiar routing and escalation behavior.
2. Clean operational ownership: once you cut over, schedules and escalation policies in Rootly become your new source of truth going forward.

Rootly migrations are performed using read-only PagerDuty API access, meaning Rootly does not modify or delete any resources in PagerDuty. Your PagerDuty instance remains intact and can be kept running in parallel during a transition window if you want an added safety net. To get started, contact Rootly. Your onboarding or customer success representative will walk you through scope, timing, and required access, then coordinate and execute the migration for you.

---

​

How PagerDuty Concepts Map To Rootly

This table answers two distinct questions at once:

• Does Rootly have an equivalent concept for this PagerDuty resource? — the Rootly column.
• Will the on-call migration import this for me, or do I configure it natively in Rootly? — the Imported by migration? column.

Most paging primitives are imported automatically; most everything else has a Rootly equivalent that you set up natively. For full import scope and the exhaustive out-of-scope list, see What You Can Migrate and What’s Not Migrated below. If a PagerDuty concept you depend on isn’t in this table, ask your Rootly onboarding rep — many edge cases are supported but not always under the same name.

---

​

What You Can Migrate

Rootly can migrate the core building blocks of on-call operations. Each section below explains what is migrated, how Rootly maps it, and where you should expect differences.

​

Users

Rootly imports users in a way that prioritizes safe, deterministic matching. How users are matched

• Rootly matches PagerDuty users to Rootly users using email address.
• If a Rootly user with that email already exists (including soft-deleted users), Rootly will reuse that user rather than creating a duplicate.
• If no Rootly user exists for the email, Rootly creates a new Rootly user automatically.

Team membership and on-call access

• Imported users are added to the target Rootly Team.
• Your Team’s defaults (and any relevant workspace configuration) may apply to newly created memberships, including default on-call role assignment.
• If your workspace uses on-call seat limits, users without an available on-call seat cannot be added into schedule rotations until seats are available.

Contact methods that are migrated Rootly migrates user contact information used for paging, including:

• Email address(es)
• SMS-capable phone number(s)
• Call-capable phone number(s)

How notification rules are migrated PagerDuty notification rules are translated to Rootly’s notification rule model where compatible:

• PagerDuty urgency = low maps to Rootly quiet notification rules.
• PagerDuty urgency ≠ low maps to Rootly audible notification rules.
• PagerDuty notification start delays map to Rootly rule delays when possible.
• Contact method types are mapped into Rootly’s supported contact methods, which include:
  • Email
  • SMS
  • Phone call
  • Critical mobile push (bypasses device Do Not Disturb when configured)
  • Non-critical mobile push (respects device Do Not Disturb when configured)

What happens when a rule cannot be mapped

• If a PagerDuty rule uses a configuration that does not translate cleanly, Rootly skips that rule rather than importing a partial or misleading configuration.
• After import, Rootly can also seed defaults (if needed) so every responder has a safe baseline configuration (for example, an email-based quiet rule).

Important behavioral expectations

• Rootly enforces practical paging constraints in the UI for audible notification rules. For example, initial audible steps typically must include an immediately actionable path (critical push or call) so responders cannot accidentally configure an audible chain that can never reach them.
• Where your PagerDuty rules include escalations or multi-step paging, validate your Rootly notification rules post-import to ensure the “audible” versus “quiet” intent matches your team’s reality.

​

Schedules

Rootly imports schedules with the intent of preserving rotation logic and future coverage. What schedule data is migrated

• Schedule definitions (name, description where applicable)
• Rotations and rotation membership
• Overrides
• Shift generation behavior (Rootly will generate future shifts based on imported rotation configuration)

Supported schedule membership types Rootly schedules support rotation members that are:

• Individual users
• Other schedules (nested schedules), with safeguards to prevent circular dependencies

If your PagerDuty design effectively represents a team as a “target,” Rootly typically models that as a schedule rather than embedding a “team” directly inside a schedule rotation. Schedule validation and skip behavior Some schedules may be intentionally skipped for safety or compatibility. A notable case:

• Schedules with rotation turn lengths shorter than 24 hours may be skipped during migration.

If schedules are skipped, the migration should record them as skipped resources so you can review and decide whether to recreate them manually using Rootly-native patterns. Syncing schedules vs. creating schedules Depending on migration settings:

• You can import schedules into a clean workspace (create-only), or
• You can synchronize against existing Rootly schedules (sync mode). In sync mode, Rootly may rebuild base shifts and clean up removed overrides to match the source.

Because schedule sync can rebuild future shifts, migrations often support a configurable delay between shift recreation steps to prevent racing or partial computations.

​

Escalation Policies

Escalation policies are imported to preserve “who is notified, when, and in what order.” What escalation policy data is migrated

• Escalation policy definitions and levels
• Targets within each level (where compatible)
• Ordering and delays

Audible vs. quiet escalation paths Rootly can optionally create separate escalation paths to mirror PagerDuty urgency behavior, such as:

• A quiet path designed for low urgency routing
• An audible path designed for urgent paging

Whether you enable this depends on how strictly you separate low urgency vs. high urgency in your operational model. Target types you can expect Escalation levels in Rootly can target combinations of:

• Users
• Schedules
• Teams
• Slack channels
• Services (depending on configuration)

Rootly also supports paging strategies and targeting modes (including round robin strategies) that you can layer on top after migration if you want more control than your original PagerDuty setup provided.

​

Services and Teams (Optional)

Depending on migration settings, Rootly can also import:

• PagerDuty teams into Rootly Teams
• PagerDuty services into Rootly services

If enabled, Rootly can optionally set owning Teams for services to preserve operational ownership and improve reporting and routing downstream.

---

​

What’s Not Migrated

The on-call import covers paging configuration — users, schedules, escalation policies, and optionally services and teams. Everything below is out of scope and either has to be reconfigured natively in Rootly or migrated by a separate process. Knowing this list upfront prevents the “I assumed X would come over” surprise during cutover. If something you depend on isn’t listed, flag it to your onboarding rep during scope review — many edge cases are handled but not always under the same name.

---

​

Configuration Options You May Be Asked To Choose

PagerDuty migrations often include a small number of explicit choices so the resulting Rootly configuration matches your intent. Common migration options include:

• PagerDuty region: US or EU
• Import scope controls:
  • Import all escalation policies, or only specific escalation policy IDs
  • Exclude certain schedule IDs
  • Import all users, or restrict to users referenced by migrated schedules/policies
• Resource strategy:
  • Create-only import
  • Synchronize existing Rootly resources
• Escalation policy behavior:
  • Create separate quiet and audible escalation paths
• Operational hygiene options:
  • Disable shift reminders for imported users (helpful if you want responders to opt in later)
• Timing controls:
  • Delay between escalation policy imports and schedule imports
  • Delay before schedule shift recreation in sync mode
• Dry run mode:
  • Validate and produce a report of what would be imported (including validation errors) without writing resources into Rootly

If you are unsure which options to select, a good default is to start with a dry run, then run a create-only import into a staging workspace (or a safe test team) before importing into production.

---

​

Typical Timeline

Most PagerDuty migrations land inside a 2–4 week window from kickoff to full cutover. The actual import is fast — the time goes into scoping, dry-run review, and the parallel-validation period. Smaller environments (one or two teams, no services/teams import) can compress this to roughly a week. Larger or more complex environments — many policies with custom urgency rules, heavy parallel validation, multi-region cutover — typically take the full 4 weeks.

---

​

Migration Process

​

Step 1: Define Scope and Success Criteria

Before any technical setup, define what “success” means for your organization. This reduces rework and prevents ambiguous expectations. Recommended scoping questions:

• Are you migrating one team or multiple teams?
• Are you migrating only schedules and escalation policies, or also services and teams?
• Do you need parity for low-urgency workflows (quiet routing), or only urgent paging?
• Do you need to preserve existing Rootly resources, or can this be a clean import?

Common “success criteria” examples:

• Every responder can be paged in Rootly via at least one reliable channel.
• Every critical service has an escalation policy attached and can page an on-call responder.
• The most important schedules generate correct upcoming shifts for the next 2–4 weeks.
• Escalation policies correctly notify schedules/users in the intended order with expected delays.

​

Step 2: Create a Read-Only PagerDuty API Key

Rootly migrations use the PagerDuty API to read configuration. In PagerDuty:

1. Navigate to Integrations → Developer Tools → API Access Keys
2. Create a new API key
3. Name the key clearly (example: “Rootly Migration – Read Only”)
4. Ensure the key is read-only
5. Copy the key securely and share it with the Rootly onboarding team using your approved secure channel

​

Step 3: Run a Dry Run (Strongly Recommended)

A dry run validates what Rootly can import and highlights any resources that will be skipped or require attention. This is especially valuable if your PagerDuty instance contains edge cases (complex layers, unusual rotation lengths, legacy artifacts). A dry run typically surfaces:

• Users that cannot be matched cleanly (missing emails, invalid data)
• Schedules that will be skipped (for example, short turn lengths)
• Policies that reference unsupported patterns
• Any validation errors that would prevent import

If you are migrating a large environment, a dry run is the safest way to avoid surprises.

​

Step 4: Execute the Migration

After dry run validation, Rootly runs the migration asynchronously. Imports are typically staged so dependencies resolve correctly (for example, users exist before schedules reference them). At a high level, a migration commonly progresses through:

• Users (and optional Teams)
• Services (optional)
• Schedules (and overrides, then shift generation)
• Escalation policies

Because the migration runs in the background, you can continue normal work while it completes, and then validate the results after completion.

​

Step 5: Validate in Rootly Before Cutover

After import, treat validation as an explicit step—not an afterthought. You should validate both configuration correctness and real paging behavior before you flip any alert sources. The On-Call Readiness report in Rootly is your fastest path to a tenant-wide view of paging readiness — it surfaces missing escalation policy attachments, unverified contact methods, and responders not installed on the mobile app in one place. Use it as the dashboard you walk through before sign-off. Schedules

• Each core schedule shows the correct “currently on-call” responder and the next 2–4 weeks of upcoming shifts.
• Overrides imported from PagerDuty are visible on the On-Call Shifts page and labeled correctly.
• No schedules show a Gaps Detected badge unexpectedly (or, if they do, the Schedule Owner fallback is intentional).
• Nested schedules (schedules used as rotation members in other schedules) resolve to the correct on-call user.

Escalation Policies

• Each escalation policy references the intended schedules, users, or targets at each level.
• Level delays match what PagerDuty had (or the agreed-upon override).
• If you opted into separate quiet/audible paths, both are present and target the right groups.

Users And Notification Rules

• Every responder has at least one audible notification rule that reaches them within the expected delay.
• Phone numbers are verified (a phone number on the user record without verification will not receive SMS or calls).
• Responders intended for low-urgency routing have quiet rules configured.
• Sample 3–5 responders across teams and confirm their per-user notification rule chain matches expectations.

Mobile App Readiness

• Responders intended to receive critical mobile push have the mobile app installed and logged in.
• Critical push permissions are granted (the mobile app prompts for this — verify it was accepted, not deferred).

Routing And Services

• Test alert sources route into Rootly’s Alerts page without errors.
• For each critical service, confirm the alert routing rule maps to the correct escalation policy.

Real-Paging Validation

• Send a test notification from at least one schedule per team. Confirm the on-call user receives it on every channel they’re configured for (push, SMS, call, email).
• For services with the highest production importance, simulate a real alert (using the source tool’s test webhook) and confirm the page reaches the on-call responder end-to-end.

Skipped Resources

• Review the dry-run report’s skipped resources list. For each: decide whether to recreate manually in Rootly using a native pattern, or accept that it stays in PagerDuty until decommissioned.

​

Step 6: Cut Over and Monitor

When you are ready, shift your alert sources to route into Rootly On-Call, then actively monitor the first hours/days of production usage. During cutover, the most common issues are not configuration problems—they are deliverability or responder readiness issues (for example, a responder never installed the mobile app or has not verified a phone number). Use Rootly’s readiness tooling and test notifications proactively.

---

​

Running PagerDuty And Rootly In Parallel

Because Rootly imports from PagerDuty using a read-only API key, PagerDuty stays fully untouched and operational throughout the migration. That gives you a real safety net: you can keep PagerDuty live during validation and cut over without committing burned bridges. Two parallel-running patterns are common, depending on how much risk tolerance your team has during cutover.

​

Pattern A: Mirror Mode (Lower Risk)

PagerDuty stays primary. Alert sources continue routing to PagerDuty. In parallel, you configure the same alert sources to also send to Rootly as a second destination. Pages fire in both systems; responders acknowledge in PagerDuty as usual. The goal is to observe, not act. Compare what Rootly does to what PagerDuty does for the same incoming alert. Did the right responder get paged? At the right delay? With the right urgency? Discrepancies caught here are cheap to fix — no production responders are relying on Rootly yet. This pattern works best when:

• Your sending tools (Datadog, AWS, Sentry, etc.) support multiple webhook destinations or fan-out via a forwarder
• You have a defined validation period (typically 1–2 weeks) before committing
• Stakeholders are nervous about a hard cutover

​

Pattern B: Cutover With Warm Fallback

Flip alert sources from PagerDuty to Rootly on a planned date. PagerDuty stays configured (escalation policies, schedules intact) but no longer receives alerts. If something serious breaks in the first 1–2 weeks, you can re-point alert sources back to PagerDuty in under an hour and operate normally while the issue is diagnosed. The goal is to commit, but keep an undo path. Most teams find that after a week of clean operation, PagerDuty can be decommissioned with confidence. This pattern works best when:

• You’ve completed thorough Step 5 validation and have high confidence in the import
• Your alert sources don’t easily support sending to two destinations
• Your team has a clear rollback runbook (who flips the switch, how the call is made)

​

What To Avoid

• Don’t pay for both indefinitely without a decision date. Set a cutover deadline. Parallel-running is a transitional state, not a destination.
• Don’t disconnect PagerDuty the same day you cut over. Keep it configured for at least a week. Configuration is free; rebuilding it from scratch on day-three because of a deliverability issue is expensive.
• Don’t skip the parallel period because validation looks clean. Real-world paging surfaces edge cases that no checklist catches — a misconfigured phone country code, a Slack workspace install issue, a responder who set Do Not Disturb. The parallel window catches these cheaply.

---

​

Best Practices

These practices reduce risk and make the migration easier to validate and operate.

• Start with a dry run. Dry runs catch incompatible schedules and policy edge cases early, when changes are easiest.
• Migrate in a controlled window. Even if Rootly doesn’t require downtime, you want your team mentally prepared for validation and quick fixes.
• Plan a staged cutover. Many organizations keep PagerDuty live briefly while they validate Rootly paging reliability, then fully cut over.
• Validate paging with real test notifications. It’s not enough for rules to exist; verify that responders actually receive calls/SMS/push.
• Decide your urgency model up front. If you rely heavily on low urgency workflows, enable separate quiet and audible escalation paths. If you don’t, keep it simple.
• Communicate responder expectations early. Tell responders what to install (mobile app), what to verify (phone numbers), and what to expect during the transition.
• Document “skipped resources.” If something is skipped (such as a schedule layer with short rotation length), write down why and your replacement approach in Rootly.

​

Frequently Asked Questions

---

Need help planning or executing a migration? Contact your Rootly onboarding representative or email support@rootly.com.