# Migrate from PagerDuty

EvoHub On-Call has a built-in importer that reads your PagerDuty account with a read-only REST API key and creates the matching schedules, escalation policies and integrations. This page explains how to run it, what it maps and what you finish by hand.

## How PagerDuty concepts map to EvoHub

| PagerDuty | EvoHub | Notes |
| --- | --- | --- |
| Users | Organization members | Matched by email. Invite everyone — EvoHub has no per-seat fee. |
| Teams | Teams | Not created. You choose which of your EvoHub teams each PagerDuty team's schedules, policies and integrations go into. |
| Schedules and layers | Schedules and layers | Imported, in the same time zone. |
| Layer restrictions | Shift windows | Imported when EvoHub can express them (see below). |
| Schedule overrides | Overrides | Those in the next 90 days are imported with their schedule. |
| Escalation policies | Escalation policies | Imported, including loops. |
| Services | — | EvoHub has no services. Each service's integrations are imported with the service's name. |
| Service integrations (Events API v2, email, CloudWatch, Datadog…) | Integrations | Imported, each with a new URL to point the sender at. |
| Event orchestrations and rules | — | Not imported. |
| Notification rules | Notification settings and notification schedule | Not imported; each person sets their own. |

## Before you import

- **Invite your people first.** The importer matches PagerDuty users to EvoHub members by email address. A schedule or escalation policy that names someone who is not a member yet is not imported until they join; the preview says which person is missing. The preview lists unmatched people and, if you are allowed to invite, offers an **Invite N people** button. People who join later can still be added: see [Run it again](#run-it-again).
- **Make sure they can respond to alerts.** A member whose role cannot respond to alerts holds back the schedules and policies they appear in the same way, with a message naming them.
- **Create a read-only REST API key.** In PagerDuty: **Integrations → API Access Keys → Create New API Key**, tick **Read-only API Key** and copy it. A user's personal REST API key also works but only sees what that user can see.

You need the On-Call settings permission to import (Owners, Admins and Members have it by default).

## Run the importer

:::steps
### Open the importer
Go to **On-Call → Import from PagerDuty** (also linked from the **Moving from Opsgenie or PagerDuty?** banner on the Integrations page).
### Enter the key and service region
Paste the **PagerDuty REST API key** and choose the **Service region**: **US** (api.pagerduty.com) or **EU** (api.eu.pagerduty.com). Click **Preview**. The key is used for this import only; EvoHub does not store it.
### Review the preview
Nothing is created yet. The preview shows **People** (who matched), **Teams** (where each PagerDuty team's objects go — by default, your current team), **Schedules** with their layers, **Escalation policies** with their steps and delays, **Integrations** with the EvoHub type each maps to, and every warning. Untick anything you do not want.
### Import
Click **Import N items**. The result lists what was created (with links), what was **Skipped** and why, and the warnings.
### Point your senders at EvoHub
For each imported integration, the result shows its new URL. Update each sender. Alerts reach EvoHub only after you do this.
:::

Only one import runs at a time per organization. If PagerDuty limits the key's requests, the importer waits and retries; if it is still limited, wait a minute and try again.

## What is imported, and how

### Schedules

Each PagerDuty schedule becomes an EvoHub schedule in the same time zone, and each layer becomes a layer. PagerDuty's top layer — the one that wins — becomes EvoHub's first layer.

- **Turn lengths** of whole days carry over: one day is daily, seven days is weekly, any other number of days is a custom rotation. Turns of whole hours, up to 168, become custom rotations of that many hours; other turn lengths are rounded to whole days, with a warning.
- **Restrictions** become shift windows when EvoHub can express them: one daily window (it may run past midnight, such as 22:00–06:00), the same window on selected weekdays (such as Mon–Fri 09:00–17:00), or whole days (such as Saturday and Sunday). Two daily windows, or a weekly restriction that runs across days (Friday 18:00 to Monday 09:00), cannot be expressed: that schedule is not imported, and the preview tells you to create the layer by hand, one layer per window.
- Layers that have already ended are skipped. A layer that starts or ends in the future is imported with that start or end date.
- People are kept in order. A layer with the same person on more than one turn, or with a user the key cannot read, cannot be imported as it is: its schedule is not imported, and the preview says why.

### Overrides

Overrides that have not ended and start within the next 90 days come over with their schedule, for the same person and the same start and end. The preview shows how many each schedule brings. An override for someone who is not in EvoHub yet, or cannot respond to alerts, is not imported and the preview names it: invite them or change their role, then run the import again. Overrides further ahead than 90 days come over on a later run.

If PagerDuty does not return a schedule's overrides, the schedule is still imported and the preview says so. An override already on the schedule is never added twice.

### Escalation policies

Each PagerDuty escalation policy becomes an escalation policy, and each target of a rule becomes a step:

- Steps can target a **user** or a **schedule**.
- PagerDuty's delay is the wait *after* a rule; EvoHub's is the wait *before* a step, using 1, 2, 3, 5, 10, 15, 30 or 60 minutes. The importer converts them so each step lands as close as possible to its PagerDuty time and warns about any difference.
- A rule with several targets notifies them at once in PagerDuty; in EvoHub each target is its own step, a minute apart.
- **Loops** become repeats, up to EvoHub's maximum of 5, after the last rule's delay.

### Integrations

PagerDuty services are not imported as services — EvoHub has none. Instead, each integration of an active service becomes an EvoHub integration named **Service · Integration** (for example "Checkout API · Events API v2"), attached to the service's escalation policy if that policy is imported.

- **Events API v2** integrations become EvoHub **API** integrations, which accept the Events API v2 format as it is: the same body, the same `dedup_key`, and the same answer (`202` with `status`, `message` and `dedup_key`). The sender changes only two things: the URL (`https://events.pagerduty.com/v2/enqueue` → the integration's URL) and the `routing_key`, which must be the new integration's key. A `routing_key` in the body is read before the `?key=` in the URL, so the old one must not stay.
- An integration made for a tool EvoHub has its own integration for (Datadog, Prometheus, Grafana, New Relic, Amazon CloudWatch, Sentry and others) becomes that integration; point the tool at its URL in the tool's own settings.
- **Email** integrations become email integrations with a new address.
- **Events API v1** integrations are imported, with a warning: EvoHub reads the v2 format, so switch the sender to v2 when you point it at EvoHub. **Change events** are not read.
- Integrations of disabled services are not imported.

## Run it again

You can run the importer again at any time. Items that were already imported are marked and skipped, so a re-run never creates duplicates.

A schedule imported before that people have joined since — they were invited after the first run, or were given a role that can respond — shows **Add N new people**. Tick it and import: they are put where PagerDuty has them in the layer. If you changed the layer in EvoHub since the import, they are added at the end instead and a warning asks you to check the order. Nobody is removed. Adding people changes who is on call from then on, so check the schedule afterwards.

## What you recreate by hand

The preview lists these under **Not imported yet**: services, team members, event orchestrations and rules, response plays, business services and status pages, maintenance windows, notification rules and change events. Recreate upcoming **maintenance windows** in EvoHub, any **overrides** the preview flagged, and ask each person to set [their own notifications](https://docs.evohub.io/notifications.md).

## Run both in parallel, then cut over

Where a sender supports several destinations, add the EvoHub URL next to PagerDuty for a week or two, fire a test alert through each integration, and compare what each paged. Then remove the PagerDuty destinations.

The import itself is free. Alerts and notifications in EvoHub are billed by usage — see [How billing works](https://docs.evohub.io/how-billing-works.md). For help planning a migration, contact info@evosync.io.

## Related

- [Migrate from Opsgenie](https://docs.evohub.io/migrate-from-opsgenie.md)
- [Integrations overview](https://docs.evohub.io/integrations-overview.md)
- [Schedules and rotations](https://docs.evohub.io/schedules-and-rotations.md)
- [Escalation policies](https://docs.evohub.io/escalation-policies.md)