Migrate from PagerDuty

https://docs.evohub.io/mcp

claude mcp add --transport http evohub-docs https://docs.evohub.io/mcp

{
  "mcpServers": {
    "evohub-docs": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://docs.evohub.io/mcp"
      ]
    }
  }
}

{
  "mcpServers": {
    "evohub-docs": {
      "url": "https://docs.evohub.io/mcp"
    }
  }
}

{
  "servers": {
    "evohub-docs": {
      "type": "http",
      "url": "https://docs.evohub.io/mcp"
    }
  }
}

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

#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.
• 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

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.

#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. For help planning a migration, contact info@evosync.io.

#Related

• Migrate from Opsgenie
• Integrations overview
• Schedules and rotations
• Escalation policies