Migrate from PagerDuty

Moneat reads your PagerDuty account with a read-only API key and turns it into Moneat on-call configuration: schedules, layers, overrides, escalation policies, and teams. Nothing pages from Moneat until you decide it should, and Moneat never changes anything in PagerDuty.

This guide walks through creating the key, what the import brings across, how people are matched, and how to check the result before you move production paging.

Before you start

Make an inventory of the things that can wake someone up or change the handover:

• People, teams, schedules, layers, and overrides.
• Escalation policies and priorities.
• Personal notification rules and contact methods that responders must recreate in Moneat.
• Services, integrations, and the systems that send events to PagerDuty.
• The current responder for each schedule, including upcoming handoffs.

Only organization owners and admins can import or switch on-call paging in Moneat.

Create a read-only API key

In PagerDuty, an Admin or Account Owner opens Integrations → API Access Keys, selects Create New API Key, and ticks Read-only API Key. Give it a description such as "Moneat migration" and copy the key when it is shown.

A read-only key is all Moneat needs. Moneat only reads from PagerDuty's REST API, and the key is sent in a request header on each call, never in a URL.

Read your PagerDuty account

On Settings → On-call Migration, choose PagerDuty, paste the key, agree to the key being held while the read runs, and select Load from PagerDuty.

The read runs in the background. You can leave the page; Moneat emails you when the package is ready to review, or if something is needed from you. If PagerDuty rate-limits the read, Moneat waits and tries again on its own.

To finish a read that was interrupted, Moneat holds your API key encrypted for up to 7 days. It is removed as soon as the package is ready to review, when you cancel the import, or when you select Remove key on the import. Removing Moneat's copy does not revoke the key in PagerDuty; delete it under Integrations → API Access Keys once the migration is done.

The migration is named after your PagerDuty subdomain, such as pagerduty-acme. Reading the same account again later uses the same name, so the import updates what it made before instead of making copies.

What is imported

Moneat reads:

• Users and teams, with each team's members.
• Schedules and their layers.
• Overrides in the next two weeks.
• Escalation policies and priorities.
• Who is on call over the next two weeks, to compare against the import.

Personal notification rules and contact methods are not read. Each responder chooses how Moneat contacts them under Paging. Services, integrations, and incident history are not imported either; see Reconnect alert sources.

Importing turns each record into Moneat configuration, saved through the same checks as the on-call pages:

Each record is saved on its own, and the report lists what happened to every one: created, updated, unchanged, kept with its Moneat changes, not imported, or failed, with what Moneat left out of it. A record Moneat refuses fails alone; the rest still import. Some PagerDuty settings have no Moneat equivalent and are listed on the records that use them:

• Restrictions on a layer. The layer covers every hour until you edit it.
• A layer with an end date. Moneat keeps it running until you remove it.
• Escalation targets other than users and schedules.
• Repeat counts or delays beyond what a Moneat policy allows.

An import that would put more people on call than your on-call seats is refused before anything is saved. Add seats under Settings → Billing, then import again.

People and accounts

Each PagerDuty user is matched to a member of your Moneat organization by email, regardless of case. A matched person takes their turns, overrides, policy steps, and team membership across.

A PagerDuty user with no matching member is listed in the report under What the import made, with every place they are left out. A layer that is missing a person is imported switched off, so it never pages a gap. You can bring them in two ways:

• Switch on Invite people without a Moneat account on the review. Moneat leaves a pending invitation for each of them, as a member, with the email PagerDuty has. An invitation already pending is left as it is.
• Invite them yourself from Settings → Members.

Invitations are not emailed unless you also switch on Email the invitations. Without it, the invitations wait under Settings → Members, where you can send each one when you are ready. Invitations expire after 7 days. Once people accept, import again to add them to their layers, overrides, policies, and teams.

Review the import

1. Load from PagerDuty, as above.
2. Confirm that the result reads as PagerDuty and that the record counts look right.
3. Select Review import. Reviewing is read-only; PagerDuty continues paging.
4. Read the proposed creates, updates, removals, unsupported records, and who would be on call. Windows the import would leave with nobody on call must be acknowledged before you can import.
5. Choose how to import, then import.

Do not acknowledge a coverage gap just to make the button available; a page raised during an uncovered window reaches nobody.

Mirroring or a one-time import

An import is one-time by default: Moneat creates the schedules and policies and holds each policy as a draft, so nothing pages from Moneat and PagerDuty remains the only system paging. Use this to check the configuration, then switch paging over when you are ready.

Mirror before switching is off unless you turn it on. Mirroring publishes the imported policies when they are saved, so Moneat pages for every alert an alert route sends to them while PagerDuty keeps paging too. Agree on a test window and make sure responders know both systems will page them. While mirroring, compare:

• The current responder and next handoff for every production schedule.
• Escalation order, wait times, and repeats.
• SMS, push, voice, email, and Slack delivery.
• Acknowledgement, resolve, reassign, and manual escalation actions.

The migration status stays visible at Settings → On-call Migration. It shows whether the import is ready, mirroring, paging from Moneat, or handed back to PagerDuty.

Importing again

Read the account again and import whenever PagerDuty changes during the migration. Importing the same migration again updates what the last import made instead of making copies:

• A record that is unchanged is left alone.
• A changed record updates its Moneat object.
• A record that is no longer in PagerDuty has its Moneat object removed.
• An imported object you deleted in Moneat is made again.

An imported object you changed in Moneat since the last import keeps your changes. The report lists it as Kept Moneat changes, and the review names it before you import. PagerDuty's changes to that record are not applied; to take PagerDuty's version, delete the object in Moneat and import again. If the record has since left PagerDuty, Moneat keeps the object and stops linking it to PagerDuty, so later imports leave it alone. A schedule that left PagerDuty stays while it holds a layer or a current override that was added or changed in Moneat. A kept escalation policy still follows the import's mirroring choice: it pages from Moneat only when mirroring is on.

Imports add people to teams and never take anyone off a team. Switching paging over or back is not a change to the imported objects.

While an import is saving records, the migration cannot start paging, return paging, or take a second import. Wait for the report, then continue. A migration that is paging from Moneat must be returned before a changed import can be applied.

Reconnect alert sources

Moving schedules and escalation policies does not move the systems that send alerts. For each PagerDuty service integration:

1. Create the corresponding Moneat alert source, using a native adapter where one exists or Generic HTTP for a JSON webhook.
2. Add an alert route that sends its alerts to the imported escalation policy.
3. Point a non-production or low-risk integration at the new ingress endpoint first.
4. Verify the source event, matched alert route, grouping result, paging attempt, and incident.
5. Move the remaining integrations after the first path is understood.

Verify the result

Before cutover, check the import against PagerDuty:

1. Read the report under What the import made. Every failed record, record left out, and person without an account needs an answer.
2. On Schedules, compare who is on call now and the next handoff for each production schedule with PagerDuty.
3. Open each imported escalation policy and compare its steps, delays, and repeats.
4. Check that each team lists the right schedule, policy, and members.
5. Send a test alert through each production route and confirm the responder who would be paged first.

Cut over when the result is trusted

1. Open the migration status page.
2. Confirm the phase is Imported, not paging or Mirroring and that the version is current.
3. Select Start Moneat paging and confirm the schedules and responders in the dialog. Cutover publishes every imported policy. If one cannot page yet, including a policy whose steps reach nobody with a Moneat account, nothing changes and the message names it.
4. Turn off the PagerDuty services and escalation policies you moved. Moneat does not change anything in PagerDuty, so until you do, both systems page.
5. Watch the first real alerts and verify acknowledgement stops escalation.

If the result is not acceptable, use Return paging to provider. Rollback archives the published versions of the imported policies, so nothing pages from Moneat, and leaves the imported schedules and policies in place for another review. Turn PagerDuty back on if you stood it down.

Migration checklist

• Created a read-only PagerDuty API key and read the account into Moneat.
• Read the list of what was not carried over and covered each item in Moneat.
• Reviewed the import and resolved every coverage gap.
• Invited everyone the report lists without an account, and imported again once they joined.
• Imported without paging, or mirrored during a planned test window.
• Reconnected alert sources and routes, and tested delivery and responder actions.
• Confirmed the first responder for every production schedule.
• Cut over to Moneat, stood down PagerDuty paging, and deleted the API key.

Moving from Opsgenie instead? See Migrate from Opsgenie. Need a second pair of eyes on the cutover plan? Talk to us before you move production paging.