Inventory before choosing tools
Export the current operating model before rebuilding anything. A migration that preserves integrations but loses ownership, time zones, or override habits will still break coverage.
- Users, teams, service owners, and backup responders
- Rotations, overrides, holidays, handoff windows, and time zones
- Escalation chains, route rules, alert grouping, and severity mapping
- Integrations, ChatOps hooks, calendars, runbooks, and audit needs
Pick a migration pattern
Parallel run
Keep Grafana OnCall OSS visible while the replacement path receives copied alerts. Use this when missed pages are more dangerous than duplicate noise.
Service cutover
Move one owned service at a time. This keeps responders close to the change and makes rollback ownership explicit.
Manual rebuild
Recreate schedules and policies by hand when the old and new routing semantics do not match cleanly.
Onboard responders before cutover
Make the new workflow boring before the first real page. Run the same alerts through the old and new paths, then ask responders to acknowledge, escalate, hand off, and resolve a test incident from every device and channel they depend on.
- 1Pick one service with clear ownership and regular alert volume.
- 2Rebuild its responders, rotations, and escalation chain in the new workflow.
- 3Send test notifications through every channel before any alert route changes.
- 4Run a shadow week with both systems visible and one named rollback owner.
- 5Cut over service by service, then retire duplicate routes after one deploy cycle.
Where Squasher fits
Squasher should not be positioned as a full PagerDuty-style paging replacement. Use it where it is strongest: ingesting telemetry, grouping failures, attaching AI triage and evidence, opening monitor-driven incidents, and publishing status updates after an alert reaches your response workflow.
