Oncallferry
An incident-operations migration workspace linking source configurations, normalized policies, destination capabilities, rehearsal evidence, cutover approval and runbook-review candidates.
On-call migrations are organizational as well as technical. Schedules encode time zones, overrides and rotations; escalation policies encode delays and fallbacks; integrations and runbooks carry service-specific assumptions. The supplied research confirms an official open-source migration tool that already moves several major source configurations into one destination. It also documents unsupported schedule types, manual attachment steps and a single-destination constraint.
Oncallferry therefore cannot lead with basic migration novelty. Its plausible wedge is multi-destination translation, managed rehearsal and a runbook-review layer. It would preserve every source object, source version, extraction time, normalized representation, destination capability, lossy mapping, unsupported field, proposed target object, reviewer decision, rehearsal result, approved cutover, destination readback and rollback artifact.
A successful import does not prove that a page reaches the right responder or that an escalation behaves equivalently. Cutover needs shadow tests, responder acknowledgment, scenario replay and an explicit fallback. Runbook staleness is also a candidate, not a fact: missing telemetry may reflect renamed services, sampling gaps, seasonal systems, telemetry outages or an intentionally dormant procedure. An owner decides whether to update, archive or retain it.
Schedules and incident records contain employee and operationally sensitive data. The product needs least-privilege access, narrow retention, tenant isolation and a record of who approved each transformation. It must not page production responders during rehearsal without authorization. The buyer hypothesis is a platform-engineering, site-reliability or incident-management leader planning an on-call migration, but organization size, source estate, target choices, timing, budget and current migration tooling need validation.
A platform-engineering, site-reliability or incident-management leader responsible for an authorized on-call tooling migration and safe cutover.
Automation can reduce migration effort, while a silent schedule or escalation mismatch can break incident response.
Active migration tooling and recurring vendor-exit pressure make the problem current.
Semantic loss and operational cutover explain difficulty, but an official open tool already handles core object migration.
The input identifies a concrete migration buyer and confirms real source-to-destination gaps plus an unserved runbook-review workflow.
An official free migration tool closes much of the base use case, while destination diversity, telemetry access, buyer timing and managed-service economics remain unresolved.
Discussion
No comments yet — be the first to weigh in.