Migration
Migrate from PagerDuty, checklist first.
A PagerDuty migration is mostly about not breaking paging while you move. This is the checklist: forward alerts in parallel before you import anything, and cut over only once the comparison is boring.
Competitor information last verified September 2026. Sources are linked beside each fact.
Checklist
Six steps, in order.
- 01
Inventory
List your PagerDuty services, schedules, escalation policies and users. This is what the importer will read.
- 02
Forward alerts in parallel
CallHeim accepts PagerDuty Events API v1 and v2 request bodies at a CallHeim integration URL, so tools that let you set the endpoint and key can be pointed at CallHeim alongside PagerDuty.
- 03
Run the dry run
Connect a read-only PagerDuty token and review the counts of what would map and what would fail.
- 04
Review
Check schedule layers and overrides, and relink any service that does not yet page through the right escalation policy.
- 05
Cut over
Once the parallel run and the imported configuration look right, re-point the remaining senders and stop sending to PagerDuty.
- 06
Decommission
Retire the old PagerDuty integrations and routing keys once every sender is confirmed on CallHeim.
The process
What writes, and when.
- 01Parallel run
no workspace write
Forward alerts to CallHeim alongside your existing tool, so you can compare the two before anything changes for your team.
- 02Dry run
no workspace write
CallHeim reads your PagerDuty or Opsgenie account with a read-only token. The dry run writes nothing to your CallHeim workspace, and keeps a copy of the extract for the import.
- 03Review
no workspace write
Check what the dry run mapped and what it could not. Schedule layers and overrides may arrive empty, escalation rules keep only the first target of each tier, and team and service-to-policy links need checking by hand.
- 04Import
writes to your workspace
Run the same process for real. It creates the mapped users, teams, services, schedules, escalation policies, incidents and maintenance windows in your workspace. Re-running an import updates the same records instead of duplicating them, and overwrites edits made to imported records.
- 05Re-point senders
no workspace write
Give each alert source a new CallHeim integration URL and key. Existing PagerDuty or Opsgenie keys are not reused, and a tool with a fixed events.pagerduty.com endpoint cannot be repointed.
- 06Cut over
no workspace write
Once the parallel run and the imported configuration look right, stop forwarding to the old tool and retire it.
PagerDuty specifics
What is different about a PagerDuty move.
Event bodies are accepted as-is
Run in parallel during a move: CallHeim receives PagerDuty Events API v1 and v2 bodies, Opsgenie outgoing webhooks, and alerts forwarded from Splunk On-Call, Squadcast, Zenduty and Grafana OnCall.
Every sender needs a CallHeim integration URL and key; existing PagerDuty routing keys are not reused.
A fixed endpoint cannot be repointed
A tool that hard-codes events.pagerduty.com as its destination cannot be repointed at CallHeim; it needs a configurable webhook or integration URL. Check each sender before you plan a cut-over date around it.
For reference: The PagerDuty/pagerduty Terraform provider is listed on the Terraform Registry, partner tier, v3.36.0 (published 2026-08-25). (Terraform Registry API, checked 2026-09-24)
From your PagerDuty account
What the importer reads.
Users
Name, e-mail, role and one phone number. Imported as invited records — each person still has to be invited to sign in.
Teams
Name and description.
Services
Name, description and team.
Schedules
Created as a shell; layers, overrides and restrictions come from whatever the vendor API returns for that schedule.
Escalation policies
Tiers and timeouts, up to 8 tiers.
Incidents
The last 90 days of history, so analytics do not start from an empty chart.
Maintenance windows
Start, end and the service it applies to.
Before you commit
What needs a human check.
- Schedule layers and overrides: the extractor requests a plain list, so layers, overrides and phone contact methods may arrive empty depending on what the vendor API returns.
- Escalation rules: only the first target of each tier carries over.
- Team and service links: services are written before their escalation policy, so an imported service may not page through the right policy until you relink it.
- Imported users: they arrive as invited records and are not reliably pageable until they sign in.
Import tooling (early access) reads your PagerDuty or Opsgenie configuration (US-region accounts); an optional dry run lets you review the result before anything is written to your workspace.
Recreating what doesn't transfer whole
Escalation policies and schedules, specifically.
These are the two object types worth budgeting real review time for. Everything else on the needs-review list above is a quick check; these two usually need hands-on rebuilding.
Escalation policies
Tiers and timeouts import correctly, up to 8 tiers — but only the first target of each tier carries over. After Import, open each imported policy and add back any secondary or backup target the original had configured: a tier that paged "Alice, then Bob, then the whole team" imports with only Alice until you re-add the rest by hand.
Schedules
The base schedule and most rotations come across, but layers, overrides and phone contact methods may arrive empty, depending on what the source account’s API returns for that schedule. Before cutover, open the old schedule and the imported CallHeim schedule side by side, and rebuild any missing layer, restriction or override directly in CallHeim’s schedule editor.
What an escalation policy looks like once rebuilt in CallHeim (example data).
Questions
About the move.
Can I migrate from PagerDuty?
Import tooling (early access) reads your PagerDuty or Opsgenie configuration (US-region accounts); an optional dry run lets you review the result before anything is written to your workspace. During the move you can also run in parallel: Run in parallel during a move: CallHeim receives PagerDuty Events API v1 and v2 bodies, Opsgenie outgoing webhooks, and alerts forwarded from Splunk On-Call, Squadcast, Zenduty and Grafana OnCall. Every sender needs a CallHeim integration URL and key; existing PagerDuty routing keys are not reused.
Is there a trial?
CallHeim is in early access. 14-day trial with up to 5 seats and no card required. Adding a user beyond a plan’s seat limit is refused (Trial 5, Starter 10, Pro 50, Business 200); existing users and paging are not affected.
How does pricing work?
Starter $9, Pro $15 and Business $29 per user per month. Enterprise is negotiated. Paid plans are activated directly by the CallHeim team. Some features are tied to plan: the REST incident API and related-incident insights on Pro and above; email-to-alert (per-workspace inbound alert e-mail addresses) on Trial, Business and Enterprise, not Starter or Pro.
Forward one sender before you touch the rest.
CallHeim helps teams stay in control when critical systems are not. Explore the platform, connect one source, and send yourself a page.
Early access · every workspace starts with a 14-day trial for up to 5 seats, no card required