Migrating from PagerDuty: a step-by-step playbook

Why migrations stall

Most PagerDuty migrations stall at step three — not because the new tool is missing something, but because the team can't see what they're cutting over yet. The instinct is to build a perfect spreadsheet of "services to migrate" and then realize the spreadsheet is the project. So skip the spreadsheet.

The shortest path that doesn't lose alerts:

1. Mirror — don't migrate. Send the same webhook to both PagerDuty and WardenPoint. For two weeks, both fire. You see the new tool work on real traffic without committing yet.
2. Cut services over in order of noise volume — least noisy first. A service that fires once a quarter is a safe cut. A service that fires every deploy is a battlefield. Start with quiet ones; build muscle memory.
3. Mute PagerDuty only after one rotation has passed under the new tool. One full week of normal traffic on the new tool, including a weekend, before silencing the old one.

The dual-fire window

While both tools fire, you'll hear about every alert twice. That's the point. Two weeks of "I got woken up by both" is intentional discomfort — it forces the team to compare which one routed correctly, which one had the better runbook link, which one paged the wrong person.

Use the dual-fire window to:

• Verify on-call schedules match between tools (people you forgot are still in PagerDuty rotations they don't remember signing up for)
• Sanity-check that webhook payloads land in the right WardenPoint integration (Grafana vs Alertmanager vs Sentry produce different schemas)
• Tune escalation chains: the WardenPoint policy you start with WILL be wrong; the dual-fire window is where you correct it before going single-source

Schedules

Schedules are the only thing that REALLY hurts in a migration. Everyone's calendar lives in PagerDuty:

• iCal exports go back two years
• Overrides are a mess of "Joe couldn't take Tuesday, swapped with Aleks, then Aleks had a baby"
• The "follow the sun" assumption is baked into who-pages-whom logic in 14 different places

The pragmatic move: re-create only the active rotation pattern. Don't backport history. Note the cutover date and treat all historic on-call records as "in the old system." Forward, it's WardenPoint.

Integrations

Bring integrations over in this order:

1. Alertmanager (highest signal)
2. Grafana
3. Sentry / Rollbar / error trackers
4. Synthetic monitoring (Pingdom, Better Stack)
5. Custom webhooks
6. Everything else

Each integration has a "verify with one fake alert" step before you trust it. WardenPoint exposes an /api/v1/notifications/test endpoint for exactly this — it routes through the full pipeline (escalation chain, recipient resolution, channel dispatch) but flags the message as a test so it doesn't ack a real incident.

Recipient drift

The thing nobody warns you about: when you mirror two paging systems for two weeks, you also surface every "stale recipient" in PagerDuty — people who left, people who changed phone numbers, people whose Slack ID no longer matches their email. They show up because the dual-fire makes failures noticeable that the team had silently routed around in PagerDuty for years («Mariusz isn't answering anymore, just call Anna directly»).

That's good. Clean them up while migrating, not after.

Cutover day

Single change: disable the PagerDuty webhook on every alerting source. WardenPoint keeps running. Don't disable the PagerDuty rotation immediately — leave it as a safety net for one more week. After that, you can cancel.

The post-mortem trick: file an "imaginary outage" exercise in the first week single-source. Pretend something broke at 03:00 UTC, walk through what alerts SHOULD fire, what's missing. That surfaces the holes before a real incident does.

What can stay in PagerDuty

You don't have to migrate everything. We've seen teams keep PagerDuty for ITSM-style customer support tickets that don't need wake-up paging. WardenPoint handles the noisy real-time alerting; PagerDuty owns the slower-cadence ticket flow. The dual-stack works because the cost structure is different — flat fee on one side, per-seat on the other, you optimize each for what it's actually good at.

If you want the migration in one weekend, that's possible too — but the dual-fire approach is safer and the calendar cost is small.