Migrate from PagerDuty

https://docs-dev.evohub.io/mcp

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

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

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

{
  "servers": {
    "evohub-docs-docs": {
      "type": "http",
      "url": "https://docs-dev.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. Anyone who is not a member yet is left out of rotations and escalation steps. The preview lists them 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. Members whose role cannot respond to alerts are also left out, with a warning 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 hours are rounded to whole days, with a warning; for shifts shorter than a day, give each shift its own layer with a shift window after importing.
• 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), are not imported; the layer covers the whole day and a warning tells you to set a shift window.
• Layers that have already ended are skipped. A layer with a future end date is imported without it (EvoHub layers have no end date), and one that only starts in the future starts from the import; both get a warning.
• Each person is kept once, in order.

#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 added at the end of their layers. Nobody is removed or reordered, and changes you made to the schedule stay. 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, schedule overrides, team members, event orchestrations and rules, response plays, business services and status pages, maintenance windows, notification rules and change events. Recreate upcoming overrides and maintenance windows in EvoHub, 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