Migrate from PagerDuty to GoAlert

How a PagerDuty to GoAlert migration starts and what it involves

GoAlert is a rebuild, not a data import. Teams usually start this move when a PagerDuty renewal arrives with a higher quote, when a plan change puts paid add-ons in the path of on-call work, or when a residency or lock-in review asks where paging data and phone numbers live. The first step is to treat PagerDuty as a source of reference material: export services, users, schedules and escalation policies through its REST API, then rebuild each rotation, escalation step and notification rule in GoAlert by hand. The effort is driven by two things: how many schedules have overrides, layered rotations and follow-the-sun handoffs, and how much of the paging path runs through telephony. Voice and SMS in GoAlert currently depend on Twilio as the only supported provider, so the number of countries, sender numbers and carrier registrations you need is a planning input, not an afterthought. Confirm these with your Twilio account team before you commit to a cutover date.

In most organizations the work is done by a platform or SRE team that owns the PostgreSQL database, the GoAlert deployment and the Twilio account, often with an implementation partner for the schedule design and the integration rewiring. Your team decides the target shape: which identity provider signs engineers in (GitHub OAuth or an OpenID Connect provider, with Dex as a bridge if needed), where the data encryption key is stored so every instance uses the same key, and whether you run one engine instance with the rest in --api-only mode. Those decisions carry more risk than the rotation rebuild itself. Ask any partner for a written scope that names the schedules to be rebuilt, the monitoring sources to be re-pointed, and the parallel paging tests that will run before PagerDuty is switched off. Effort and risk stay manageable when the inventory is complete and the test plan is agreed up front, and they grow quickly when either one is left vague.

Which PagerDuty capabilities map cleanly to GoAlert and which need rework

This table maps the PagerDuty capabilities most teams rely on to their nearest GoAlert equivalent and marks each as clean, needs rework or gap. Use it to scope the rebuild before exporting data, since rework rows need manual steps and gap rows need another tool or a process change.

Capability	GoAlert equivalent	Status and what to check
On-call schedules and rotations	Schedules and rotations with calendar subscriptions	Clean for standard weekly rotations. Rebuild handoff times and time zones by hand and compare against the PagerDuty export.
Escalation policies	Escalation policies with ordered steps	Needs rework. Re-create each step, target and delay, since the REST API export does not map one-to-one to GoAlert configuration.
Services and integration keys	Services with alert sources	Needs rework. Generate new endpoints or keys in GoAlert and update every sending system that references the old PagerDuty key.
Users and contact methods	Users with phone, SMS and email contact methods	Needs rework. Users must sign in to GoAlert, and SMS or voice numbers should be verified against Twilio before cutover.
Login and identity	GitHub OAuth or any OpenID Connect provider, with Dex as a bridge	Needs rework. Confirm which identity system your staff use and test sign-in on the new instance.
Slack notifications	Slack channel as an escalation policy step	Needs rework. Channel notifications are configured as escalation steps, so review any PagerDuty Slack app rules that do more than page.
Email alert sources	Email ingress through Mailgun or built-in SMTP	Needs rework. Confirm the mail routing and parsing rules for each sender before moving production traffic.
Prometheus and Grafana alert sources	Native Prometheus and Grafana alert sources	Clean for standard alert payloads. Re-point Alertmanager or Grafana contact points and test each alert path in parallel.
Voice and SMS paging	Twilio as the only supported provider	Clean only if you accept Twilio. Plan your own Twilio account, sender numbers and message charges.
AIOps and event intelligence	Not provided	Gap. Plan a separate tool or accept the loss of automated grouping and noise reduction.
Status pages	Not provided	Gap. Use a separate self-hosted status page tool, as covered in the status page alternative.
Runbook automation and post-incident tooling	Not provided	Gap. Move runbooks to your wiki or automation platform and rebuild post-incident reviews in another tool.

What to export from PagerDuty and what you rebuild in GoAlert

The PagerDuty REST API gives you a documented way to pull services, schedules, escalation policies and users, but it does not carry every piece of your paging setup across. The cards below separate what you can export, what you must rebuild by hand, and what GoAlert needs in place before any rotation goes live.

Export services, schedules and escalation policies

Pull services, schedules, escalation policies and users through the PagerDuty REST API, choosing the US or EU host that matches the account region. Keep the raw JSON as an audit copy, because it records the rotation layers and escalation delays you will translate by hand. Check that every escalation policy references a schedule or user that also exists in your export, since a dangling reference is the most common gap in a rebuild.

Rebuild rotations and escalation steps

GoAlert takes the rotation, schedule and escalation policy structure you exported and recreates it. Rotation handoff times, time zones and override layers do not translate automatically, so compare each schedule against the PagerDuty original before cutover. Document who is on each step and why, so the rebuilt chain can be reviewed in the same way the old one was.

Recreate integrations and notification rules by hand

Integration keys, notification rules and contact methods are not carried over as a block, so each alert source must be configured again in GoAlert. Map every PagerDuty service integration to a GoAlert service and generate a new key for it. Confirm which users have SMS, voice or Slack contact methods, and re-enter them with their consent.

Provision PostgreSQL 17 with pgcrypto

The only hard requirement for GoAlert is a PostgreSQL database. The getting started guide recommends PostgreSQL 17 or newer for new installations and requires the pgcrypto extension, so enable it before the first start. Plan backups and a tested restore for this database, because paging stops if it is lost, and confirm the high availability design with your database team before cutover.

Set a shared data encryption key

GoAlert recommends a data encryption key so sensitive values such as API keys are encrypted before they reach the database. Every GoAlert instance must use the same key, including instances in a Kubernetes cluster that run with the --api-only flag. Store the key in your secrets manager, record who can read it, and plan how it will be rotated, because losing it means the encrypted values cannot be read.

Re-point alert sources and test paging

Repoint Prometheus, Grafana, email and generic API senders to the GoAlert endpoints and their new integration keys. Prometheus and Grafana alert routing should be checked alongside the GoAlert alert source settings, since a single wrong key silently drops pages. Run a parallel paging test in which each alert source fires to both systems until every route has been confirmed on the on-call phone.

How the migration moves from inventory to parallel paging

The migration runs in four phases, and each one produces an artifact the next phase depends on. The first phase is inventory. Export services, escalation policies, schedules, rotations and users from PagerDuty through its REST API, then map every escalation path on paper before you build anything in GoAlert. The output is a list of schedules with their rotation layers, handoff times and time zones, and a table of which services feed which policy and which integration keys route alerts into them. Confirm with each team which escalation steps actually page a human and which ones only post to Slack, because GoAlert's Slack step and its SMS and voice steps behave differently and need separate tests.

The second phase is a pilot service with a small, willing team. Rebuild that team's rotation, escalation policy and one notification path in GoAlert, then point a single low-impact alert source at it, such as a Prometheus Alertmanager route or a Grafana contact point. Before any user depends on the pilot, set up login. GoAlert supports GitHub OAuth and any OpenID Connect provider, and Dex can bridge identity systems it does not reach directly. Decide which identity source governs who can edit schedules and who can only acknowledge alerts, and test that a departing engineer loses access. Schedules are only as trustworthy as the accounts behind them, so identity is a precondition for paging, not a later hardening step.

The third phase is parallel paging. Keep PagerDuty live and send the same test alerts to both systems, with a dedicated test group whose members receive pages from each. Check delivery time, acknowledgment behavior, escalation timing and whether a missed acknowledgment reaches the next step in the right order. Your Twilio account handles SMS and voice in GoAlert, so verify sender settings, carrier delivery and call routing from the test phones in every region your engineers carry them. The final phase is cutover and decommission: switch production integration keys one service at a time, keep PagerDuty read-only for a period you agree in advance, and retain the exported incident history as an archive. Record each cutover in a runbook so the on-call owner can roll a single service back without touching the rest.

Migration sequence from inventory to decommission

This sequence moves on-call ownership from PagerDuty to a self-hosted GoAlert instance in five checkpoints, so every service keeps a tested paging path before PagerDuty is switched off. Each step ends with a named artifact that the next step depends on.

Inventory and export PagerDuty configuration
Pull services, schedules, escalation policies, users and integration keys through the PagerDuty REST API, using the US or EU host that matches your account region. Record which integrations send events into each service, including monitoring tools such as Prometheus and Grafana, email routes and any chat or webhook connections. Store the exports in a version-controlled location with access restricted to the people running the migration. Done when every active service has a documented owner, a list of its escalation steps and a list of its inbound integrations, reviewed by the on-call leads.
Build and pilot the GoAlert configuration
Install GoAlert from its release binary or the goalert/goalert Docker image, backed by PostgreSQL with the pgcrypto extension, and set the data encryption key before any sensitive values are stored. Recreate users, rotations, schedules, escalation policies and services from the export, then connect Twilio for SMS and voice. Run a pilot with a non-production service and confirm that each on-call shift resolves to the correct person through calendar subscriptions. Done when a pilot schedule has been checked against the PagerDuty schedule for the same dates and the discrepancies are closed or accepted in writing.
Run parallel paging tests with both tools live
Send test alerts from the same monitoring sources to PagerDuty and GoAlert at the same time, so each service produces paired notifications. Test every escalation step, including the timeout before escalation, the acknowledgment path and the fallback to a secondary responder, and test SMS and voice delivery to real devices on each rotation. Log each test with the timestamp, the source, the recipient and the outcome in a shared test log. Done when every escalation path has a passing entry from both tools and the on-call leads have signed off the log.
Cut over by re-pointing integrations
Change each monitoring source, such as Prometheus Alertmanager or Grafana alert contact points, to send to GoAlert, and confirm the GoAlert alert source for each one. Disable PagerDuty delivery for each service only after its GoAlert path has passed the parallel tests and its owner has approved the change. Keep PagerDuty in place as a read-only fallback during the cutover window. Done when a signed cutover checklist lists every service, its new integration target, the approving owner and the date the change was made.
Decommission PagerDuty after confirming no active integrations
Before removing access, search the export and the live monitoring configuration for any remaining PagerDuty routing keys, webhooks or email addresses, and confirm each one has been replaced or retired. Archive the final exports and the test log in your records system, then review the retention and licensing terms in your PagerDuty agreement to decide when the account is closed. Revoke API tokens and remove users who no longer need access. Done when a final check shows zero active PagerDuty integrations and the archive has been stored under your records policy.

What drives migration cost and duration

This table lists the main factors that set the effort of moving PagerDuty on-call work to GoAlert, with the reason each one moves cost and how to keep it down. Use it to scope your own inventory before asking a partner or your team for a quote, since the largest drivers are usually the number of schedules, alert sources and notification channels.

Driver	Why it changes cost or effort	How to keep it down
Schedule and escalation policy count	Each schedule, rotation and escalation step has to be rebuilt by hand in GoAlert, and overrides and layered rotations add review time	Retire unused schedules before export, consolidate duplicate teams and test the highest-severity policies first
Alert sources to re-point	Each Prometheus, Grafana, email or generic API integration needs a new service key and routing check, and PagerDuty integrations do not export automatically	Inventory every integration from the PagerDuty API, group sources by owning service and re-point one group per test window
SMS and voice notification channels	Twilio is the only supported provider for SMS and voice in GoAlert, so each country, sender and number setup needs its own carrier and delivery check	List the countries and notification types in use, confirm Twilio coverage for each and ask the quote to name who holds the Twilio account
Slack and email paging paths	Slack escalation steps and email ingress through Mailgun or SMTP need separate configuration and delivery tests	Reuse existing Slack and mail routing, keep the number of paths small and document one test case per path
High availability design	Multiple instances, one in default engine mode and the rest with --api-only, plus a PostgreSQL 17 or newer database and database switchover, add build and test work	Start with the minimum topology your paging SLA requires, reuse existing PostgreSQL operations and ask for the switchover test to be part of the scope
Encryption key and secrets handling	A single data encryption key must be identical on every instance and protects stored API keys, so key distribution and rotation procedures need design	Store the key in your existing secrets manager and include key handling in the runbook from the start
Identity integration	GitHub OAuth, any OpenID Connect provider or a Dex bridge must map to your existing user accounts and groups before users can sign in	Confirm which identity provider is authoritative and reuse existing groups instead of creating GoAlert-only accounts
Parallel paging test window	Running PagerDuty and GoAlert side by side for test pages, acknowledgements and escalations takes calendar time and coordination with on-call staff	Agree a fixed test plan with pass criteria, schedule tests outside change freezes and ask the quote to state how many test cycles are included

How the migration differs by team size and starting point

A small team with a handful of services and one or two schedules usually has a short inventory and a single escalation path. The migration is mostly about exporting the few objects that matter, rebuilding them by hand in GoAlert and proving that a page reaches a phone. Because the number of moving parts is small, one person can often own the cutover, and the main risk is forgetting a service that only pages at night.

Inventory: List every service, its schedule and its escalation policy, then confirm which ones are still active. Stale services are often the first thing to drop.
Testing: Run a parallel paging test with a test alert to each on-call person on each channel they use, such as SMS or voice.
Telephony: Decide whether Twilio is set up for your region and numbers, and confirm who holds the account and billing.
Integrations: Re-point the single or few monitoring sources, such as Prometheus or Grafana alerting, to the GoAlert integration key or endpoint.
Operations: Confirm who restarts GoAlert and PostgreSQL when something breaks, since no vendor will do it for you.

Before cutover, confirm that every active service has a tested path to a human who can act on it.

What usually goes wrong when teams move paging to GoAlert

Most paging migrations fail in the details, not the design: a missing integration, a shifted rotation or an untested escalation step only shows up when an incident hits. The six risks below are the ones that most often separate a clean cutover from a gap in on-call coverage, and each has a check you can run before PagerDuty is switched off.

Silent loss of alert integrations

Every monitoring source that pages through PagerDuty needs its own route into GoAlert, and the REST export does not rebuild those connections for you. Prometheus Alertmanager, Grafana alert contact points and email senders often keep pointing at PagerDuty after the schedules have moved, so alerts stop reaching anyone without any error. Inventory every sender, point each one at GoAlert, and fire a test alert from each source during the parallel run.

Timezone and rotation drift

Rebuilt rotations often lose the original handoff time, the time zone or the rotation start date, so an engineer may be on call an hour early or for an extra shift. Compare each GoAlert schedule against the PagerDuty schedule for the next several weeks, including a weekend and a daylight saving change. Check that calendar subscriptions show the same people for the same hours.

Missing or inconsistent encryption key

GoAlert recommends a data encryption key so that sensitive values such as API keys are encrypted before they reach the database. If instances run with different keys, or a key is lost during a database move, stored secrets can fail to decrypt and notifications break. Set the same key on every instance, store it in your secrets manager, and confirm that a restored database works before cutover.

Twilio setup delays

Twilio is the only supported provider for GoAlert voice and SMS, so your sender numbers, account approval and destination country permissions become critical path items. Teams often find that a sender number is not yet provisioned or a country is restricted only after the schedule is live. Confirm numbers, country coverage and delivery for every engineer's phone type with Twilio before the parallel period starts.

Untested escalation steps

An escalation policy can look correct on screen yet fail at a step, such as a delay that is too long, a Slack step with a wrong channel or a user with no verified contact method. Run a test page through each step of each policy, including the final fallback, and record who received it and when. Treat any step that does not respond as a blocker.

Decommissioning PagerDuty too early

Switching off PagerDuty before parallel paging tests pass removes the only tested path back to on-call coverage. Keep the PagerDuty services active and their notifications running until GoAlert has handled real and test incidents across several rotations. Export incident history beforehand, and set the shutdown date only after the parallel run is signed off by the on-call owner.

Questions teams ask before moving from PagerDuty to GoAlert

How much does a migration from PagerDuty to GoAlert cost?

No single figure applies, because the cost depends on what you run and who runs it. The main components are the software (GoAlert is Apache 2.0 licensed, so there is no per-user license fee), the PostgreSQL database and its hosting, the high availability design, the Twilio charges for SMS and voice messages, and the labor to export, rebuild and test. The one-time work is the export, rebuild and parallel testing. The recurring costs are hosting, the database, Twilio usage and the staff time to operate a paging system. Ask any implementation partner for a fixed-scope quote built from a written list of services, integrations and environments, and compare it with your current PagerDuty invoice line by line.

How long does it take to move from PagerDuty to GoAlert?

The timeline depends mainly on how many services, escalation policies, schedules and monitoring integrations you have, and how many of them need to be rebuilt by hand. Teams with a small set of services and simple rotations usually have a shorter path than teams with many overlapping schedules, custom notification rules and multiple event sources. Build time, parallel paging tests and the cutover window should each be scheduled separately. Confirm the duration with your implementation partner in writing, based on an inventory of your PagerDuty account, rather than relying on a general estimate.

What does the work need from our internal team?

Your team needs to provide access and decisions, not just code. You will need an owner who can approve the rotation design, a person with administrator rights in PagerDuty to run the REST API export, someone who manages the PostgreSQL database and the GoAlert hosting, and the on-call engineers who will test notifications. Your telephony owner should confirm Twilio number provisioning and message routing. Plan time for the people who know which alerts matter, because that knowledge rarely lives in the PagerDuty configuration itself.

Can our own engineers migrate from PagerDuty to GoAlert without a partner?

Yes, a capable internal team can perform the migration, since GoAlert ships as a single binary with Docker images for each release and its only hard requirement is PostgreSQL. The harder parts are the export and the rebuild: the PagerDuty REST API returns services, schedules and escalation policies in its own structure, which you must map to GoAlert services, rotations, schedules and escalation steps. Test the mapping carefully. The work also includes Twilio setup, the data encryption key used for stored API keys, identity integration, and high availability. Be honest with yourselves about on-call staffing during the cutover before deciding.

Do schedules and incident history transfer from PagerDuty to GoAlert?

Schedules and escalation structure can be exported from PagerDuty through its REST API and then re-created in GoAlert, but they do not import automatically. GoAlert documents rotations, schedules, escalation policies and calendar subscriptions, so the mapping is manual or scripted work. Incident history is a different question: export it from PagerDuty for your records and audit needs, and confirm with GoAlert's current documentation whether it provides any import path for historical incidents. Do not assume past incidents will appear in GoAlert. Keep the PagerDuty export for compliance evidence and retention.

How do we test paging safely during the migration?

Run GoAlert in parallel with PagerDuty before cutover, so both systems receive the same test events while only one is the live destination. Start with test services that do not page real on-call engineers, then move to low-severity services, and only then to critical paths. Re-point monitoring sources such as Prometheus and Grafana one at a time, and check that each alert reaches the intended escalation step and channel. Verify SMS and voice delivery through Twilio, Slack steps and email ingress separately. Keep PagerDuty active until every escalation path has been exercised, and document each test result as evidence for your operations review.

What GoAlert does not replace and how to plan for it

The first decision in this section is whether your team still needs the PagerDuty features that GoAlert does not document. GoAlert's documented scope covers on-call scheduling, automated escalations, notifications and alert sources such as Prometheus, Grafana, email and a generic API. It does not document status pages, AIOps (event correlation and noise reduction), runbook automation or post-incident tooling such as retrospectives and timelines. Before cutover, list every PagerDuty feature your responders used in the last few quarters, including Status Pages, Event Intelligence, Process Automation and incident postmortems, and mark each one as replaced, kept on a second tool, or dropped. Confirm the exact feature boundaries against the current GoAlert documentation rather than relying on this summary, because the product changes between releases.

For each gap you keep, choose between two paths. The first is to keep a commercial tool for that function and accept a second bill and a second set of users, roles and integrations to manage. The second is to adopt another self-hosted product, such as Uptime Kuma or OneUptime for status pages, which is covered on its own sibling page. Either way, a gap changes the migration plan: the status page URL that customers bookmark, the runbook links embedded in alert templates and the post-incident workflow must each have an owner and a target date. Ask the operations lead to name who maintains the replacement, who gets access to it, and where its data is hosted, because a status page that depends on the same PostgreSQL instance as your paging system adds a shared failure mode. When you assess the second tool, treat it as a dependency of the paging system rather than a convenience. Test what happens to notifications if the second tool is down during an incident, and confirm that runbook links, incident records and status updates remain reachable when GoAlert is the only working system. Document the decision in the migration runbook with its owner, review date and fallback, and rerun the parallel paging tests after any change. Ask your procurement or platform team to confirm in writing which PagerDuty add-ons are being cancelled, since keeping a partial subscription for a single feature can leave you paying for both systems during the transition.

How DeployOpen scopes and runs a PagerDuty to GoAlert migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a PagerDuty to GoAlert move is scoped and delivered as a fixed-scope engagement. The work covers the GoAlert deployment, the PostgreSQL and notification setup, the rebuilt schedules and escalation policies, and the parallel paging tests your on-call team signs off before cutover.

How we scope

We inventory PagerDuty services, schedules, escalation policies, users and integrations before any build work starts.
The written scope lists which rotations, escalation steps and alert sources move to GoAlert and which stay on PagerDuty.
We confirm your Twilio, Slack and email ingress requirements, identity provider and data residency constraints in writing.

How we build

We deploy GoAlert in your cloud account or data center with PostgreSQL 17 or newer and the pgcrypto extension.
We re-create rotations and escalation steps from the exported PagerDuty data, then re-point Prometheus and Grafana alert routes.
We run parallel paging tests with your on-call engineers and document every gap found against the PagerDuty baseline.

How we hand over

You receive configuration records, runbooks for schedules and notification providers, and the test results from parallel paging.
We document the data encryption key handling, the multi-instance layout and the database switchover procedure for your operators.
Your team takes over the cutover decision and the PagerDuty decommissioning plan with a written list of rebuilt items.

How we support

Ongoing support, upgrades and continuous testing of the paging stack are available as a retainer.
Retainer work can cover GoAlert version upgrades, such as tracking new releases on the GoAlert releases page, after your review.
Support can also include re-testing escalation paths after schedule changes, staff turnover or Twilio configuration updates.