This is the operational runbook for moving a live voice workload onto TeleQuick Voice without dropping a call. The goal is a controlled cutover: you run the new stack alongside the old one, move traffic a slice at a time, verify audio quality on real calls, and keep a one-command path back until you’re confident. 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 “what to 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; 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 can’t cut over what you haven’t inventoried. Write down, for the workload you’re moving:
  • Numbers (DIDs). Which E.164 numbers take live traffic, who the carrier of record is, and whether each is portable or re-pointable (most SIP DIDs can be re-pointed by changing routing at your carrier without a formal port).
  • Trunks. Ingress/egress SIP IPs, credentials, codecs on the wire (almost always G.711 µ-law/A-law for PSTN), and any registration vs. IP-authenticated setup.
  • Runtime. Your current ASR/LLM/TTS or speech-to-speech providers, or an existing agent framework you want to keep behind a bridge.
  • Routing. IVR/menu trees, skill queues, business-hours rules, and where calls hand off to humans.
  • Baselines. Capture your current MOS, one-way latency, and answer seizure ratio now — you’ll compare against these after cutover, not against a spec sheet.
Export a week of your existing CDRs. The distribution of call durations and concurrency is what you’ll canary against and what sizes your trunk.
2

Pick a deployment path

Two decisions gate everything downstream:
  • Where the engine runs — managed cloud, self-hosted/on-prem, or the hybrid (managed control plane + your own inference). This decides where raw call audio lives. See Deployment Models.
  • Media mode per trunk — direct terminates RTP on the shard running 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 in a separate workspace (or on a dedicated test DID and trunk), not on a 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.telequick.dev and <workspace-id>.webrtc.telequick.dev. Inbound INVITEs are tenant-routed by the leftmost DNS label, so no cross-tenant extension collisions.
  • Trunk. Create an inbound trunk in the console: source IP / DID match, media_mode, the routing rule, and (for AI answering) the agent to bind. Trunk secrets are sealed 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 by re-pointing (or porting) them to a trunk — see Number Provisioning.
Self-serve number purchasing 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) rather than sourcing new numbers through the platform.
On self-hosted/on-prem, the engine owns its NIC for the kernel-bypass fast path, so applying its network config is 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 answering while the new one proves itself.
  • Smoke test. Place a call to your test DID, confirm two-way audio, agent answer, DTMF, and a human handoff if you use one.
  • 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 untouched.
  • Watch the canary. Compare live MOS, latency, and failure rate against your Step 1 baselines — not just averages, tails. Ramp the slice up only while the new path stays at or better than baseline.
5

Cut trunks and numbers

Once 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. Because the engine matches trunks by source IP / DID, the switch is a routing change at your carrier — no re-registration dance.
  • Numbers. Move the rest of your DIDs to the new trunk in the same way you moved the canary. Do it in batches, verifying each batch before the next, so a problem is contained to one batch.
  • Drain the old platform. Leave the old system answering (routing removed but still reachable) until in-flight calls finish, then decommission.
6

Verify on real calls

Cutover isn’t done until the numbers say so. Verify against your baselines:
  • Audio quality. Per-call MOS (ITU-T E-model, from loss + jitter) is written 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 localizes it to transport, ASR, LLM, or TTS.
  • Signalling. Confirm the answer sequence and no unexpected BYEs in the SIP/RTP traces.
  • 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: e.g. “MOS ≥ baseline, p95 turn latency ≤ baseline, ASR ≥ baseline over 500 calls.” Roll forward only when the bar is met.
7

Keep a rollback ready

A migration you can’t reverse isn’t a migration, it’s a leap. Before you cut each batch, know exactly how to put it back.
  • The lever is carrier routing. Rollback = re-point the affected DIDs back at your old platform’s trunk. Keep the old system warm and reachable until you’ve verified for long enough to trust the new path.
  • Batch = blast radius. Because you cut in batches, a rollback only touches the batch that regressed, not your whole number range.
  • Keep credentials live. Don’t rotate SIP secrets or tear down the old trunk until the rollback window closes.
  • On-prem caveat. Carrier-routing rollback is instant; changing the engine’s own network config still requires a reboot, so treat engine config as a separate, planned change from DID routing.

​
Printable checklist

Copy this into your change ticket and tick 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 verified batches
  • Old platform draining in-flight calls, not yet decommissioned
After cutover
  • MOS distribution verified against baseline
  • Turn and media latency verified against baseline
  • SIP traces clean; no unexpected BYEs or one-way audio
  • Pass bar met over a real call volume before rolling 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.