# Migration Checklist > A step-by-step cutover plan: audit, pick a path, provision, canary, cut trunks and numbers, check MOS and latency, and keep a rollback ready. This is the operational runbook for a move of a live voice workload onto FirstByte 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](/modalities/voice/migration/from-livekit)** — Move browser/app media onto our transport (bring your own media). - **[From Twilio](/modalities/voice/migration/from-twilio)** — Re-point Media Streams and SIP trunks. Use PCMU passthrough. - **[From Asterisk / FreeSWITCH](/modalities/voice/migration/from-asterisk-freeswitch)** — Re-point trunks and agents onto a FreeSWITCH-shaped core. - **[From WebRTC](/modalities/voice/migration/from-webrtc)** — Keep your capture and codec. Divert encoded Opus onto QUIC. - **[From WebSocket audio](/modalities/voice/migration/from-websocket-audio)** — On-ramp bespoke WebSocket audio senders. - **[Migration overview](/modalities/voice/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. > **TIP:** > 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](/modalities/voice/concepts/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](/modalities/voice/concepts/sessions-calls-tracks-streams). > **NOTE:** > 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 `.sip.firstbyte.fast` and `.webrtc.firstbyte.fast`. 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](/modalities/voice/runtime/byo-asr-llm-tts), [BYO speech-to-speech](/modalities/voice/runtime/byo-speech-to-speech)). Or keep your existing framework behind a [vendor bridge](/modalities/voice/runtime/keep-existing). - **Numbers.** Bring your existing DIDs. Re-point them (or port them) to a trunk. See [Number Provisioning](/modalities/voice/transport-telephony/number-provisioning). > **WARNING:** > 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. > **NOTE:** > 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](/modalities/voice/observability/mos-jitter-loss). - **Latency.** Check the turn and media latency breakdown. If answers feel slow, the [latency breakdown](/modalities/voice/observability/latency-breakdown) shows whether the cause is transport, ASR, LLM, or TTS. - **Signalling.** Check the answer sequence in the [SIP/RTP traces](/modalities/voice/observability/sip-rtp-debugging). Check that there are no unexpected BYEs. - **Common faults.** One-way audio and connection failures each have a focused runbook: [one-way audio](/modalities/voice/troubleshooting/one-way-audio), [call not connecting](/modalities/voice/troubleshooting/call-not-connecting). > **TIP:** > 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](/modalities/voice/migration/overview)** — Which path fits your existing workload. - **[SIP trunking](/modalities/voice/transport-telephony/sip-trunking)** — Trunk fields, matching, and credentials. - **[Latency breakdown](/modalities/voice/observability/latency-breakdown)** — Where the milliseconds go, stage by stage. - **[MOS, jitter & loss](/modalities/voice/observability/mos-jitter-loss)** — Read call-quality scores off every CDR.