Migrate from PagerDuty

Current coverage

HowlOps reads PagerDuty without modifying it. The preview labels every item exact, lossy, or unsupported before you select it.

PagerDuty	HowlOps	Important limits
Users/accounts	Existing members + optional invitations	Every readable account is shown, including people not currently referenced by an on-call object. Existing members match by case-insensitive email; everyone else is opt-in and invited as a safe HowlOps member. PagerDuty account roles, contact methods and personal notification rules do not import.
Team + memberships	Team + members/leads	Manager becomes lead; responder becomes member. Observer and unknown roles stay visible in warnings but receive no HowlOps team access because there is no equivalent read-only role. If several managers exist, all remain lead members and the first source-ordered manager becomes the canonical team lead.
Legacy schedule + overrides	One-layer schedule + overrides	One unrestricted daily or weekly layer imports, including participant order, IANA timezone/hand-off conversion and an explicit override window of up to 366 inclusive days. Multi-layer schedules, restrictions, finite layers, weighted duplicate participants, differing active/phase starts, unsupported turn lengths and multi-team ownership fail closed.
Shift-Based Schedules v3	Exact narrow subset or unsupported inventory	A single rotation with one unbounded, full-day/full-week event, simple DAILY/WEEKLY RRULE, rotating_member_assignment_strategy, one shift per member, no empty/duplicate slots and no override/custom shift in the selected window imports. HowlOps also checks PagerDuty's computed final_schedule for unknown sources, members and concurrent assignments. Every other v3 shape remains visible and fails closed.
Escalation policy	Escalation policy	assign_to_everyone parallel targets, step timing and repeats import. A multi-target round_robin rule fails closed because parallel paging would change who is assigned. PagerDuty handoff-notification mode is reported for separate setup.
Service + integration references	Business service + cutover inventory	Name, description, owner team and escalation-policy catalog link import. Integration names/types are inventoried, but routing keys and credentials are never copied. Urgency/timeouts require review.
Business Service	Business service	Name, description and a single owner team import. Point of contact, subscribers, supporting-service dependencies and impact graph remain cutover gaps. A technical and business service sharing a name fails closed because HowlOps catalog names are unique.
Maintenance Windows + Priorities	Unsupported cutover inventory	Both collections are read and shown. PagerDuty maintenance targets technical services while HowlOps maintenance targets monitors; configurable PagerDuty priority labels also have no lossless account-wide mapping.
Event Orchestration	Unsupported cutover inventory	Global orchestrations are listed so routing cannot disappear silently. PCL conditions, nested rule paths, suppression, automation and service routing are not activated or approximated.

Selection is dependency-aware: selecting a schedule selects its team, selecting an escalation policy selects its schedule/team targets, and selecting a service selects its policy and team. If a required dependency is unsupported, the dependent object cannot be imported as if it were complete. Rows marked imports with changes are never selected by default.

Use a read-capable US or EU API token. Preview may need access to users, teams, schedules, escalation policies, services and event_orchestrations.read. A scoped token that cannot see an area cannot prove that the migration is complete. A missing/unavailable Event Orchestration feature is reported; rejected credentials or a forbidden scope fail the preview instead of pretending it is complete.

PagerDuty requires since and until when listing overrides, so HowlOps never invents a hidden history window. The wizard visibly defaults to the next 90 days and lets you choose up to 366 days. If any selected-window override has no valid interval or its responder email cannot be resolved, the whole schedule fails closed rather than silently dropping part of the timeline.

PagerDuty documents both last-layer precedence and schedule restrictions. The source fields are defined by the official GET /schedules API schema. HowlOps imports only the subset whose resulting on-call timeline it can preserve; unsupported schedules remain visible in preview for manual recreation.

People are invited only when you select them. Before acceptance, their imported team membership, schedule positions, overrides and direct escalation targets are visible as invited/pending but have no authorization or paging effect. Accepting the ordinary workspace invitation atomically activates all of those bindings; SAML JIT sign-in and SCIM provisioning perform the same atomic reconciliation for users that bypass the invitation screen. A failure stays retryable. Activate every required account before redirecting production events.

This is a one-shot migration, not continuous synchronization. Re-running uses PagerDuty IDs and typed HowlOps import links to avoid duplicates. It distinguishes unchanged, source-changed, legacy and repairable state, but deliberately preserves an already-linked HowlOps object rather than overwriting edits made after migration.

Not migrated

HowlOps does not import PagerDuty alerts, incidents, notes, analytics or audit history; user passwords/SSO identities, account roles, teams outside the token's scope, contact methods or personal notification rules; executable priorities or maintenance windows, response plays, extensions/webhooks, status dashboards, business-service relationships or dependencies; routing/integration keys; service support hours, urgency rules, auto-resolve/acknowledgement timeouts; v3 shapes outside the exact subset above; or executable Event Orchestration. Items that can be discovered safely are inventoried in preview/report; secrets are never returned, logged or persisted.

ChatOps connections are installations and identities belonging to the destination workspace, not portable PagerDuty data. Reinstall and authorize Slack, Microsoft Teams or other chat integrations in HowlOps, map channels, and test acknowledge/resolve commands before cutover.

Cutover checklist

Use the service-integration and Event Orchestration inventory as a cutover checklist. Resolve every unsupported/lossy row, accept invitations, compare rendered on-call and escalation timelines, recreate ingress integrations, orchestration, maintenance windows and notification/contact methods, then test pages end to end. PagerDuty routing keys still point to PagerDuty and are deliberately never reused or stored; configure every sender with a new HowlOps endpoint. Reconnect ChatOps channels and identities, run both systems in parallel, and redirect event senders only after review.