How to migrate from PagerDuty: what the AI scan finds, what gets migrated, and how long it takes

TL;DR: Migrating from PagerDuty takes days to a few weeks, depending on configuration complexity. incident.io's AI scanner reads your account via a read-only API key, maps every escalation policy and integration, and produces a complexity score before you commit. Escalation policies translate directly into incident.io escalation paths. A three-phase parallel-run strategy (Test, Trial, Go-Live) runs both systems simultaneously so routing errors are caught before live traffic shifts, significantly reducing the risk of missed alerts during cutover. Zendesk migrated 1,200 users, 150 teams, and 5,000 monitors with two engineers and zero major issues.

Zendesk migrated 1,200 users, 150 teams, and 5,000 monitors from PagerDuty to incident.io with a core team of two engineers and zero major issues, as detailed in the incident.io rescue program. That result should shift how you think about PagerDuty migration complexity.

The most common objection to replacing PagerDuty isn't the cost of the new tool. It's the fear of breaking years of invisible escalation policies, Event Orchestration rules, and schedule overrides that nobody fully documented. Teams worry that the alerting infrastructure they've quietly built over the years will collapse the moment they try to move it.

That fear is real, but it's based on a false premise: that migration scope is unknowable until you're already committed. incident.io's AI-powered scanner eliminates that uncertainty by reading your entire PagerDuty account before you sign anything, producing a complexity score and phased migration plan that maps every dependency. This guide walks through exactly what the scanner reads, how escalation policies translate, and the three-phase playbook used by Zendesk and Intercom to migrate without dropping a single alert.

Why migrating from PagerDuty feels risky (and why it isn't)

PagerDuty is deeply embedded in most alerting stacks. Over years of use, teams accumulate dozens of escalation policies with multi-level timeouts, time-based routing rules for business-hours versus off-hours coverage, hundreds of Datadog or Prometheus monitors pointing at PagerDuty services, and custom webhooks that nobody remembers building. The fear isn't switching platforms; it's not knowing what you've built.

Three factors make that fear worse than the reality:

1. You can read most configuration complexity via API, which lets us scan it automatically rather than audit it manually.
2. A parallel-run approach fires both systems simultaneously during the transition, so there's no single high-stakes cutover moment.
3. We built incident.io's migration tooling specifically to handle the PagerDuty object model, including escalation paths, schedule layers, and Terraform configurations, so the translation isn't guesswork.

The actual migration drivers pushing teams to switch are well-documented. PagerDuty's pricing comparison for 2026 shows the Business plan at $41/user/month, with AI features (AIOps at $699/month and Advance at $415/month) adding $13,368/year regardless of team size. A 100-person team on the Business plan plus those two AI add-ons lands at roughly $62,000/year before Statuspage or Jira integrations. Watch incident.io's on-demand session on PagerDuty migration patterns to understand why teams of different sizes and industries are making the switch.

The coordination tax: how context switching increases MTTR

PagerDuty handles alert delivery well, but many teams still coordinate the broader incident workflow manually. When a P0 fires at 2:47 AM, an engineer may acknowledge the alert in PagerDuty, create a Slack channel, open monitoring tools like Datadog in another tab, file a Jira ticket, and update the status page separately. Depending on the team’s workflow maturity and automation setup, that coordination overhead can add several minutes before active troubleshooting begins.

At 15 incidents per month with a loaded engineer cost of $150/hour, that coordination tax costs approximately $562.50/month in wasted engineering capacity, or $6,750/year spent toggling between tabs instead of fixing the underlying problem. incident.io eliminates this overhead by running the entire incident lifecycle inside the Slack channels where your team already works, using automatic team routing to escalate to the right on-call engineer without manual intervention.

How long does it take to migrate from PagerDuty?

Your migration timeline depends on three variables: the number of users, the number of custom Event Orchestration rules, and the number of monitoring integrations pointing at PagerDuty. The AI scanner produces a custom timeline estimate before you commit, so you don't have to guess.

General ranges based on configuration complexity:

• Smaller teams with simple escalation policies: A few weeks from first scan to full Go-Live
• Mid-size teams with moderate complexity: Several weeks, including parallel running and pilot validation
• Enterprise teams with complex Event Orchestration: Weeks to a couple of months for a full phased cutover

Zendesk's migration at 1,200 users, 150 teams, and 5,000 monitors completed with a core team of two, proving what purpose-built tooling makes possible even at scale. The Intercom migration video shows how a mid-size engineering organization ran the same process in a matter of weeks.

incident.io also offers a contract buyout of up to 12 months free on a multi-year deal for teams migrating from PagerDuty, removing the financial risk of running both tools during the transition period.

The parallel migration strategy: pros and cons

Running PagerDuty and incident.io simultaneously during the Test and Trial phases is the key risk-reduction mechanism. Both systems receive the same alerts, so no incident gets dropped if a routing rule isn't configured correctly in incident.io yet.

Pros of parallel running:

• Zero missed alerts during configuration validation, so you catch routing errors safely before live traffic shifts
• Engineers can compare alert delivery side-by-side to validate notification chains
• Easy rollback at any point during Test or Trial phases without production impact
• Schedule mirroring tests cover requests and overrides in incident.io while PagerDuty remains the backup paging system

Cons to plan for:

• Temporary double-alerting means engineers receive notifications from both systems during Trial phase, which can feel noisy for the first few incidents
• Engineers need to know which system is authoritative for acknowledgment during Trial
• Running two platforms simultaneously requires a short window of dual spend

The incident.io changelog on easier migrations outlines how schedule mirroring specifically addresses the double-alerting problem by keeping incident.io schedules synchronized with PagerDuty throughout the trial.

What gets lost when switching from PagerDuty?

We migrate most configuration automatically with minimal manual effort on your end. A few areas require deliberate planning.

Historical incident data: We don't auto-migrate PagerDuty incident history into incident.io. You can export past incidents via the PagerDuty API or CSV (Comma-Separated Values) export for compliance archival, but incident.io's Insights dashboard starts fresh from your first incident on the platform. Flag this to your CISO (Chief Information Security Officer) team early so they can plan the archival workflow before decommissioning your PagerDuty account.

Custom Event Orchestration rules with complex conditional logic: Basic alert routing rules translate directly. Highly customized suppression logic or enrichment rules with multiple nested conditions may require manual recreation and testing during the Test phase.

Datadog monitors: If you have hundreds of Datadog monitors pointing at PagerDuty services, incident.io provides a dedicated Datadog migration tool that reads your Datadog API keys, maps existing PagerDuty services to incident.io teams, and generates a configuration file you review before applying. The Datadog monitor migration help article walks through the exact steps.

For a direct capability comparison once you've migrated, the incident.io vs PagerDuty feature breakdown covers on-call, response coordination, and AI features across both platforms.

PagerDuty escalation policy migration explained

PagerDuty escalation policies use timeout-based rules with up to 20 escalation levels and up to nine repetitions of the full policy. Time-based rules route to different responders during business hours versus off-hours, and multi-user notifications at a single level support simultaneous paging.

We map all of this directly to incident.io's escalation path model. Here's how a typical three-level policy translates:

PagerDuty's escalation policy documentation details the full object model if you need to audit your current policies before the scan. incident.io reads all of this via the same API and surfaces it in the migration report.

If your team manages on-call configuration via Terraform, incident.io supports the same workflow. You can update Terraform config to point Datadog monitors or other alert sources from PagerDuty to incident.io in bulk, covering escalation paths, schedules, and alert routes. The PagerDuty migration tools documentation and the PagerDuty migration help article cover both the manual and Terraform-based paths.

How to migrate from PagerDuty to incident.io

The migration runs across six streams: account setup, alert connections, routing, dependencies, onboarding prep, and user cutover. These streams overlap across a pre-migration setup step and three distinct parallel-run phases (Test, Trial, Go-Live) rather than running sequentially. Here's how each phase works.

Pre-migration: AI scan and account setup

You provide a read-only PagerDuty API key and our scanner reads every object in your account: all services, escalation policies, schedule configurations with their layers and overrides, user accounts, team memberships, and connected integrations. Our scanner produces a custom migration guide with a complexity score, a timeline estimate, and a phased plan covering all six streams. You see this before you commit to anything, which is the single most important risk-reduction step in the entire process.

Once you decide to proceed, account setup runs in parallel with the scan review:

1. Create your incident.io organization and connect to your Slack workspace.
2. Replicate your user directory via SCIM (System for Cross-domain Identity Management) provisioning for Enterprise plan customers, or manual invite for smaller teams.
3. Configure your service catalog with ownership mappings for each service that currently has a PagerDuty service record.
4. Connect your PagerDuty account directly to incident.io as an alert source to enable the parallel-run phase.

The on-call readiness report within incident.io tracks how prepared each team is to start receiving live pages, so you can monitor migration progress across all teams in one dashboard rather than chasing status updates manually.

Phase 1 (Test): Alert connections and routing

For Datadog specifically, the migration tool reads your API keys, identifies all monitors currently routing to PagerDuty, and generates a mapping file that redirects each monitor to the correct incident.io team. You review the file, adjust any incorrect mappings, and apply it in bulk. For Prometheus or Grafana, you connect alert sources by dropping incident.io webhook URLs into each tool's notification channel configuration, other monitoring tools connect via the method documented in incident.io's alert source setup guides. For escalations from alerts, incident.io handles the same trigger-to-escalation logic that PagerDuty routes through its service configurations.

During this phase, all alert sources remain connected to PagerDuty. The incident.io connection runs in shadow mode, receiving the same alerts without firing live notifications to your team, which gives you a validation window to confirm that alert routing rules, severity mappings, and team assignments produce the correct results before any live traffic shifts.

Phase 2 (Trial): Dependencies and onboarding prep

With routing validated, your team and your service catalog need preparation. The service catalog in incident.io stores owner information, dependencies, runbooks, and recent deployment data for every service. Populating it from your existing PagerDuty service directory takes most of the manual effort in this phase.

Your team onboards faster than most engineering leaders expect, because incident.io runs entirely through Slack commands. Engineers need to know three commands to participate effectively in their first incident: /inc declare to open an incident, /inc update to post a status, and /inc resolve to close it. The on-call onboarding 30-day checklist covers the full ramp for teams building new on-call rotations alongside the migration.

This phase is also when you configure incident.io's workflows: the automation rules that replace manual steps in your current process, such as automatically creating Jira tickets based on incident attributes and conditions, paging a secondary responder if the primary hasn't acknowledged within five minutes, and manually updating your Statuspage during incidents (automatic Statuspage updates on incident state changes are on the incident.io roadmap but not yet available). The incident.io workflow and integration guide featuring Pleo shows how one engineering team configured workflows to replace a complex manual incident process.

Phase 3 (Go-Live): User cutover

The Trial phase redirects live alerts from one pilot team to incident.io, with PagerDuty still running as a backup. Schedule mirroring keeps the two systems synchronized, so cover requests and overrides made in incident.io reflect back into PagerDuty automatically. Your engineers can choose which paging solution notifies them during this phase, validating the notification delivery chain (push, SMS, call) for each responder before full cutover.

After the pilot team runs real incidents through incident.io and confirms the experience, you expand to additional teams. Once a majority of teams have migrated, redirect all remaining alert sources and run both systems for one final week to catch stragglers. Then export your historical PagerDuty incident data for archival, decommission user accounts (or set them to read-only), and turn off PagerDuty billing.

PagerDuty migration checklist

Use this checklist across your three migration phases and track completion in a shared Notion doc or Linear project.

Pre-migration:

• Run the incident.io AI scanner with a read-only PagerDuty API key and review your complexity score and timeline estimate
• Export your full inventory of PagerDuty services, escalation policies, schedules, and integrations
• Identify your custom Event Orchestration rules and webhooks that require manual recreation
• Review the on-call readiness report to assess team preparation before shifting live pages
• Assign your migration lead and define a stakeholder communication plan
• Confirm your contract buyout terms if transitioning mid-PagerDuty contract

Test phase:

• Connect PagerDuty to incident.io as an alert source for parallel validation
• Recreate all escalation policies as incident.io escalation paths with matching timeout values
• Configure on-call schedules for the pilot team, including business-hours and off-hours layers
• Connect Datadog monitors using the bulk migration tool and validate team routing
• Run shadow escalations (both systems fire, incident.io in validation mode only)
• Validate alert deduplication behavior for high-volume alert sources
• Populate the service catalog with owner, dependency, and runbook data

Trial phase:

• Redirect live alerts from the pilot team to incident.io, with PagerDuty as backup
• Enable schedule mirroring so cover requests in incident.io sync back to PagerDuty
• Configure responder paging preferences (push, SMS, call) and test delivery
• Monitor for missed or duplicate alerts across a representative sample of incidents
• Configure incident workflows (auto-Jira ticket creation based on incident attributes, manual Statuspage updates, Scribe transcription)
• Run the pilot team's first post-mortem in incident.io and validate the auto-draft quality
• Collect feedback from on-call engineers and iterate on escalation policy configuration

Go-live:

• Redirect all remaining alert sources and monitoring tools to incident.io
• Run both systems in parallel for one final week as a safety net
• Export PagerDuty historical incident data via API or CSV for compliance archival
• Decommission PagerDuty user accounts or set to read-only
• Update all internal runbooks and documentation with /inc declare, /inc update, and /inc resolve commands
• Conduct a post-migration retrospective using incident.io's Insights dashboard

Post-migration (ongoing):

• Track MTTR trends in the Insights dashboard and compare to your PagerDuty baseline
• Optimize escalation policies based on actual incident routing patterns
• Expand the service catalog as new services are added
• Archive PagerDuty data on a defined retention schedule for compliance audits

Comparing PagerDuty alternatives for migration

If you're evaluating multiple platforms before committing, here's how the leading options compare on the factors that matter most during a PagerDuty migration.

Opsgenie is excluded from this comparison because Atlassian is sunsetting Opsgenie in April 2027, making it a platform to migrate away from rather than a migration destination.

The key differentiator for incident.io is the AI scanner: no competing platform reads your PagerDuty account automatically and produces a complexity score and custom timeline before you sign. That single capability reduces migration risk more than any other feature on this list. For a broader feature comparison covering on-call scheduling, alert routing, and AI capabilities, the 2026 PagerDuty vs incident.io vs FireHydrant breakdown is worth watching before your evaluation.

Zendesk case study: migrating 1,200 users with zero downtime

Zendesk's migration is the most detailed public proof point for what incident.io's migration tooling can handle at enterprise scale. The numbers: 1,200 users, 150 teams, and 5,000 monitors migrated from PagerDuty with a core team of two engineers and zero major issues, as described in the incident.io PagerDuty rescue launch post.

Intercom followed a similar pattern, moving from both PagerDuty and Atlassian Statuspage to incident.io’s unified platform. Their experience is documented in the Intercom on-call migration video, which highlights the workflow changes their engineers experienced during the transition, particularly the shift from coordinating incidents across multiple disconnected tools to managing response workflows directly inside Slack.

Across both Zendesk and Intercom, the common thread is reduced coordination overhead during incidents. Instead of jumping between alerting systems, chat tools, ticketing platforms, and status pages, engineers were able to centralize much of the incident workflow in a single environment. Teams adopting incident.io commonly describe the Slack-native experience as the biggest operational change engineers notice immediately after migration.

The pattern across Zendesk and Intercom is consistent: migrations go smoothest when teams use the parallel-run strategy rather than a hard cutover, and when the service catalog is populated before live traffic shifts. The Slack-native architecture is the specific change on-call engineers notice immediately after cutover:

"For our engineers working on incident, the primary interface for incident.io is slack. It's where we collaborate and where we were gathering to handle incident before introducing incident.io." - Alexandre R. on G2

If your team currently spends more time coordinating incidents than debugging them, schedule a demo to understand your actual migration scope and ask about running the AI scan as part of your evaluation.

Share your current migration challenges or questions in the comments below. If you're working through a specific PagerDuty configuration you're not sure how to translate, the incident.io team responds via shared Slack channels and has worked through most edge cases before.

Key terminology

Event Orchestration (PagerDuty): A rules engine in PagerDuty that routes, enriches, and suppresses alerts before they notify users, supporting conditional logic with multiple nested rules and actions.

Parallel run: Running PagerDuty and incident.io simultaneously during migration, with both systems receiving the same alerts so no incidents are dropped if a routing rule is incorrectly configured in the new platform.

Escalation path (incident.io): The incident.io equivalent of a PagerDuty escalation policy, defining which responders are notified in sequence and the timeout between each notification level.

MTTR (Mean Time To Resolution): The average time from when an incident is declared to when it is fully resolved, including alert acknowledgment, diagnosis, fix, and verification.

Coordination tax: The overhead added to MTTR by context-switching between PagerDuty, Slack, Datadog, Jira, and Statuspage during incident response, eliminated by Slack-native incident management.

P0 (Priority Zero): The highest incident severity classification, typically reserved for critical outages or failures with immediate customer or business impact. Some teams use P1 as their top severity level; terminology varies by organization but the principles of escalation and response apply equally.

Complexity score: The output of incident.io's AI migration scanner that rates your PagerDuty configuration across six migration streams and produces a timeline estimate before you commit to the migration.

AI migration scanner: incident.io's tool that reads your PagerDuty account via a read-only API key, maps every service, escalation policy, schedule, and integration, and generates a custom migration guide with phased plan before you sign.

SCIM (System for Cross-domain Identity Management): An open standard protocol that automates the exchange of user identity information between identity providers (such as Okta or Azure AD) and applications like incident.io, enabling automatic user provisioning and deprovisioning without manual account management.

CISO (Chief Information Security Officer): The senior executive responsible for an organization's information security strategy, risk management, and compliance requirements, including data retention and archival policies for operational tooling.