Move your on-call setup out of PagerDuty — people, teams, schedules, rotations, and escalation policies — without rebuilding it by hand.
The importer works in two steps. First a check that reads your PagerDuty account and writes nothing, and produces a full report of what would be created. Then, if the report looks right, an Import that creates it.
Your API key is never stored. It's used for the requests in that one check, then discarded. Because of that, pressing Import reads PagerDuty again rather than acting on a saved copy — so it always writes current data, and the report shown afterwards tells you if anything changed in between.
Start at Import from PagerDuty.
What you'll need
A REST API key with read access to the account. In PagerDuty: Integrations → API Access Keys → Create New API Key. Read-only is enough, and read-only is what we recommend.
Not a service integration key. The 32-character key on a service (sometimes called a routing or integration key) looks like an API key and is not one. If you paste one, we say so up front rather than passing PagerDuty's rejection along.
A key scoped to a single user can't list schedules. If the check comes back with "PagerDuty refused access", the key needs account-level ("General Access") scope.
You'll also need to be an admin here, and you should know how many spare seats your plan has — see Seats below.
PagerDuty has two kinds of schedule, and we read both
This is worth knowing because it explains a count that might otherwise look wrong.
PagerDuty has an older layer-based schedule (its own UI badges these "Legacy") and a newer shift-based one. They're genuinely different underneath, and PagerDuty's main schedule list only returns the layer-based ones — with no error, no flag, and no hint that anything is missing.
We read both, so the report covers your whole account. If you've been comparing schedule counts through PagerDuty's own API and getting a smaller number, that's why.
What comes across
| Thing | Becomes | Notes |
|---|---|---|
| People | Users | Email is the matching key — anyone already here is matched, never duplicated. Phone numbers come across from their contact methods. |
| Teams | Team Groups | One group per team, not one bucket for everything. This matters: a schedule's groups decide who is eligible for it. |
| Schedules | Schedules + Rotations | Both kinds. Coverage hours, turn lengths, and handoff times included. |
| Escalation policies | Escalation Policies | Levels, delays, targets, and the repeat count. See Escalation policies. |
| Overrides | Overrides | One-off cover — "Alex takes Kevin's Tuesday". Read for the next 14 days only, see below. |
What doesn't come across
- Services and integrations are reported, not created. The report lists what currently fires alerts into PagerDuty so you know what to point here. We don't create the flows, because which channels to use, who to notify, and what cooldown to set are decisions rather than translations. Build them from New Alert Flow, or let the AI Helper draft them.
- Alert and incident history. Only configuration is imported.
- Anything we can't represent faithfully. A rotation whose recurrence has no equivalent here is reported as skipped, never approximated. A schedule that looks right but pages the wrong person is worse than one you know you have to rebuild.
Nobody is contacted by an import
Importing people does not email, text, or call anyone. There's no option to make it — the capability isn't there to switch on.
Imported users exist but can't sign in yet. When you're ready to cut over, invite them individually from Users. That's deliberate: it means you can import, check everything, and sit on it for a week before anyone knows, and it means re-running the import is never a surprise for your team.
SMS opt-in is not imported either. Someone giving PagerDuty their mobile number isn't consent to receive texts from us. Numbers come across, and SMS stays switched off until each person opts in themselves.
Seats
New people occupy seats the moment they're created — before anyone is invited.
The check adds up what the import needs (seats in use or already invited, plus new people) and compares it to your plan. If it doesn't fit, the Import button is disabled and tells you how many more you need. Two ways forward:
- Buy the seats. See Plans & Billing.
- Untick "Create people who don't exist here yet". The import then creates nobody and fits within your current seats — but those people's places in their rotations are left empty, so this is a way to review the structure, not to finish a migration.
Re-running an import that creates nobody never needs a seat.
Running it again
Leave Replace the last PagerDuty import switched on while you're testing. Each run then removes what the previous run created before writing again, instead of adding another copy.
It only ever deletes rows that import recorded creating — never anything else, and never people. If someone has signed in or joined another rotation since, they're matched by email and kept.
Things worth checking in the report
The report is not a formality; these are the items that decide whether the import is faithful.
Point your flows at the imported policy
The single most consequential thing to get right afterwards. When you build a flow, target the imported escalation policy — not a schedule directly.
A policy level that resolves to nobody is skipped and the ladder moves on, which is what PagerDuty does. A flow aimed straight at a schedule behaves differently on purpose: if nobody is on call it pages every eligible member rather than dropping the alert. That's the right call for a flow with no policy, and the wrong shape for a migrated PagerDuty setup.
Overrides only cover the next 14 days
We ask PagerDuty for overrides from now to a fortnight out. Cover arranged further ahead is not imported, and a clean report doesn't mean none exists — only that none exists in that window.
If someone has a holiday booked six weeks out, add it here by hand, or re-run the import closer to the date.
An empty schedule stays empty
If a schedule has nobody on it in PagerDuty, it arrives here paused, showing "No coverage" — not staffed with everyone who happened to be eligible. If that schedule is meant to be doing something, it needs a roster before it will page anyone.
Someone already in another account
Email addresses are unique across the whole platform, so a person whose address is already used by a different organisation can't be created here. The report names them and skips them; their rotation places are left empty rather than pointed at somebody else.
Very large accounts
There are limits on how much one pass reads — 200 schedules, 200 teams. If your account is bigger, the report says what it couldn't read and states plainly that the import is incomplete. It won't hand you a partial migration that looks finished. Get in touch and we'll raise the limits for the migration.
If PagerDuty rate-limits the read, we wait and retry rather than failing. A very large account may make the check take a couple of minutes.
After the import
- Check the coverage. Open On-Call and compare the calendar against PagerDuty's. The report's coverage section is worked out by the same engine that decides who actually gets paged, so it can't disagree with what the schedules will do — but comparing the two calendars is a good sanity check on whether the source was what you thought.
- Look for coverage gaps. Uncovered windows are flagged. Some are deliberate — plenty of teams have no out-of-hours cover on purpose — but they should be gaps you chose. See Coverage gaps.
- Build your flows, pointed at the imported policies.
- Invite people from Users when you're ready to cut over.
- Test before you switch off PagerDuty. Trigger a real alert and confirm the right phone rings.
Related
- Escalation policies — how levels, delays, and repeats behave here
- Rotations and coverage — schedules, rotations, and stacking
- Coverage gaps — what happens when nobody is on call
- Import from Opsgenie — the equivalent for Opsgenie