This is the operational runbook for a move of a live voice workload onto ClutchCall Voice without a dropped call. The goal is a controlled cutover. You run the new stack in parallel with the old one. You move traffic one slice at a time. You check audio quality on real calls. You keep a one-command path back until you trust the new stack. Do this once end-to-end on a test DID before you touch production numbers. For the specifics of your source platform, pair this checklist with the matching guide. The steps are the same. Only the item that you re-point differs.

From LiveKit

Move browser/app media onto our transport (bring your own media).

From Twilio

Re-point Media Streams and SIP trunks. Use PCMU passthrough.

From Asterisk / FreeSWITCH

Re-point trunks and agents onto a FreeSWITCH-shaped core.

From WebRTC

Keep your capture and codec. Divert encoded Opus onto QUIC.

From WebSocket audio

On-ramp bespoke WebSocket audio senders.

Migration overview

How the pieces map and which path fits your workload.

​
Cutover steps

1

Audit what you run today

You cannot cut over what you did not inventory. Write down these items for the workload that you move:
  • Numbers (DIDs). Which E.164 numbers take live traffic. Who the carrier of record is. Whether each number is portable or re-pointable. Most SIP DIDs can be re-pointed by a routing change at your carrier, without a formal port.
  • Trunks. Ingress/egress SIP IPs, credentials, and codecs on the wire (almost always G.711 µ-law/A-law for PSTN). Note whether the setup uses registration or IP authentication.
  • Runtime. Your current ASR/LLM/TTS or speech-to-speech providers, or an existing agent framework that you want to keep behind a bridge.
  • Routing. IVR/menu trees, skill queues, business-hours rules, and the points where calls hand off to humans.
  • Baselines. Capture your current MOS, one-way latency, and answer seizure ratio now. After cutover, you compare against these values, not against a spec sheet.
Export a week of your existing CDRs. The distribution of call durations and concurrency is your canary reference. It also sets your trunk size.
2

Pick a deployment path

Two decisions gate everything downstream:
  • Where the engine runs. The options are managed cloud, self-hosted/on-prem, or the hybrid (managed control plane + your own inference). This decision sets where raw call audio lives. See Deployment Models.
  • Media mode per trunk. direct terminates RTP on the shard that runs the agent (fewer hops, lower latency). proxy is the default for hostile-NAT carriers. See Sessions, Calls, Tracks & Streams.
There is intentionally no sandbox environment. The platform is a single production plane. Do your side-by-side test in a separate workspace, or on a dedicated test DID and trunk. There is no sandbox toggle.
3

Provision the new stack

Stand everything up before any live traffic touches it.
  • Workspace + SIP host. Onboarding provisions your per-tenant SIP and WebRTC hosts as <workspace-id>.sip.clutchcall.dev and <workspace-id>.webrtc.clutchcall.dev. The engine routes inbound INVITEs to the tenant by the leftmost DNS label. Thus there are no cross-tenant extension collisions.
  • Trunk. Create an inbound trunk in the console. Set the source IP / DID match, the media_mode, the routing rule, and (for AI answering) the agent to bind. The platform seals trunk secrets at rest.
  • Runtime. Configure the agent. Bring your own ASR/LLM/TTS or a speech-to-speech provider (BYO runtime, BYO speech-to-speech). Or keep your existing framework behind a vendor bridge.
  • Numbers. Bring your existing DIDs. Re-point them (or port them) to a trunk. See Number Provisioning.
Self-serve number purchase from inside the console is a demo-grade catalog today, not a production buy flow. Plan to bring your own numbers (re-point or port an existing carrier DID). Do not plan to source new numbers through the platform.
On self-hosted/on-prem, the engine owns its NIC for the kernel-bypass fast path. Thus a change to its network config requires a host reboot, not a hot reload. Provision and reboot in a maintenance window before you send traffic. The reboot is not part of the live cutover.
4

Run side-by-side and canary

Keep the old platform in service while the new one proves itself.
  • Smoke test. Place a call to your test DID. Check two-way audio, agent answer, and DTMF. If you use a human handoff, check it too.
  • Canary a slice. Point a small subset of DIDs (or a carrier-side percentage split across both trunks) at the new trunk. Start with low-stakes traffic. The rest of your numbers stay on the old platform, unchanged.
  • Watch the canary. Compare live MOS, latency, and failure rate against your Step 1 baselines. Compare the tails, not only the averages. Increase the slice only while the new path stays at or better than baseline.
5

Cut trunks and numbers

When the canary holds under real load, move the remainder.
  • Trunks. Re-point your carrier’s routing so production INVITEs arrive at the new SIP host. The engine matches trunks by source IP / DID. Thus the switch is a routing change at your carrier. No re-registration is needed.
  • Numbers. Move the rest of your DIDs to the new trunk in the same way you moved the canary. Move them in batches. Check each batch before the next. Then a problem stays contained to one batch.
  • Drain the old platform. Leave the old system in service (routing removed but still reachable) until in-flight calls finish. Then decommission it.
6

Verify on real calls

The cutover is not complete until the numbers show it. Check against your baselines:
  • Audio quality. The engine writes a per-call MOS (ITU-T E-model, from loss + jitter) to every call record. Watch the distribution, not one call. See MOS, Jitter & Loss.
  • Latency. Check the turn and media latency breakdown. If answers feel slow, the latency breakdown shows whether the cause is transport, ASR, LLM, or TTS.
  • Signalling. Check the answer sequence in the SIP/RTP traces. Check that there are no unexpected BYEs.
  • Common faults. One-way audio and connection failures each have a focused runbook: one-way audio, call not connecting.
Set an explicit pass bar before you start. For example: “MOS ≥ baseline, p95 turn latency ≤ baseline, ASR ≥ baseline over 500 calls.” Roll forward only when the results meet the bar.
7

Keep a rollback ready

A migration that you cannot reverse is not a migration. It is a leap. Before you cut each batch, know exactly how to put it back.
  • The lever is carrier routing. Rollback means: re-point the affected DIDs back at your old platform’s trunk. Keep the old system warm and reachable until you trust the new path.
  • Batch = blast radius. You cut in batches. Thus a rollback only touches the batch that regressed, not your whole number range.
  • Keep credentials live. Do not rotate SIP secrets or remove the old trunk until the rollback window closes.
  • On-prem caveat. A carrier-routing rollback is instant. A change to the engine’s own network config still requires a reboot. Thus treat engine config as a separate, planned change from DID routing.

​
Printable checklist

Copy this into your change ticket. Tick each item as you go. Before cutover
  • DIDs, trunks, runtime providers, and routing inventoried
  • Current MOS, latency, and answer-rate baselines captured
  • Deployment path chosen (managed / on-prem / hybrid) and media_mode set
  • Workspace, per-tenant SIP host, trunk, and agent provisioned
  • Numbers identified as re-pointable or scheduled to port
  • On-prem only: engine network config applied and host rebooted in a window
During cutover
  • Test-DID smoke passed: two-way audio, answer, DTMF, handoff
  • Canary slice live; MOS/latency/failure at or above baseline
  • Production trunks re-pointed at the new SIP host
  • Remaining DIDs cut in checked batches
  • Old platform in drain: in-flight calls only, not yet decommissioned
After cutover
  • MOS distribution checked against baseline
  • Turn and media latency checked against baseline
  • SIP traces clean; no unexpected BYEs or one-way audio
  • Pass bar met over a real call volume before roll-forward
  • Rollback window closed, then old trunk and secrets retired

​
Next steps

Migration overview

Which path fits your existing workload.

SIP trunking

Trunk fields, matching, and credentials.

Latency breakdown

Where the milliseconds go, stage by stage.

MOS, jitter & loss

Read call-quality scores off every CDR.