Skip to main content
Back to blog

Migrating from Telnyx to Orbit — the runbook

The Telnyx-to-Orbit migration runbook for latency-sensitive senders. Telnyx numbers, connections, SIP trunk configs, and messaging profiles mapped onto Orbit's routing surfaces, then the cutover walked in order — voice first, then SMS, then optional WhatsApp — with the rollback path and the dry-run checklist that close it.

Orbit Editorial Team

Quick answer: A Telnyx-to-Orbit migration follows the same per-family swap pattern the Plivo runbook and the Sinch runbook set down: export the inventory first, then cut voice first, SMS second, and WhatsApp last if you use it — voice leads because it is the hardest family to exit when your traffic is latency-sensitive. The Orbit vs Telnyx comparison page grades the platform decision; this post is the ordered execution of that decision.

Who this runbook is for

This runbook is for Telnyx senders whose exit decision is already made, on one of two triggers.

You ran the head-to-head and the combination won. Both Orbit and Telnyx own a wholesale voice network, so owning the wires was not the deciding row — the Orbit vs Telnyx matrix grades what surrounds it: native AI voice agents, voice-biometric caller verification, BYO-WABA WhatsApp, embeddable video, and a built-in contact center on one pay-as-you-go bill. If that is the trigger, this post assumes the decision and walks the move.

Your traffic is latency-sensitive and every hop of mediation is a cost you count. Telnyx is hardest to exit when calls route through a chain of resellers: on either platform the routing contract is much simpler once traffic lands on an owned wholesale softswitch, but the cutover still has to sequence around it because a voice path cut before its shadow run validates is an incident, not a migration. That sequencing is exactly what this post orders, and rollback stays available until each wave validates.

Inventory: map Telnyx resources to Orbit

Export before anything moves. Telnyx's console names its resources differently than Orbit does, and the export sheet is the audit every later wave re-checks against:

Telnyx resourceOrbit surfaceWhat moves
Phone numbers (inventory)The Orbit numbers surface — porting + numbering planNumber ownership, port eligibility, the E.164 inventory
Connections (Call Control / SIP)programmable-voiceInbound routing destinations, SIP trunk credentials, outbound caller-ID policy
Messaging profilessms-apiSender registrations (10DLC / alphanumeric sender IDs), campaign metadata, delivery-report webhook consumer
Voice applications / call flowsprogrammable-voice flowsIVR menus, routing logic, recording policy — re-authored, not imported
Optional WhatsApp scopewhatsapp-business-apiWABA registration, template approval, unified inbox routing

Three notes on the mapping, checked against the Orbit vs Telnyx cells rather than asserted flat:

  • Voice — YES. Owned wholesale voice network is parity on both sides; once trunks land, outbound terminates on Devotel's own wholesale softswitch rather than a reseller chain, which is the latency argument's resolution.
  • AI-agent runtime — PARTIAL on Telnyx, YES on Orbit. Telnyx publishes an MCP server plus a skills catalog for hand-wiring an integration; Orbit ships a native LangGraph agent runtime with a built-in tool catalog. When you export the voice application layer, note which of your Telnyx voice applications are API-wired versus IVR-menu logic — the re-author targets differ.
  • Embeddable video — PARTIAL on Telnyx. If your inventory includes video/RTC scope, the Orbit vs Telnyx cell grades it partial on the incumbent side; what moves is whatever your current Telnyx traffic actually carries. Voice and SMS lead; the optional scope hops later.

Every sender identity, live number, connection, messaging profile, and flow definition exported to one sheet — the registration gate a later wave re-checks before it moves.

How to cut over, channel by channel

Voice moves first because the number's port is the longest-lead item, and a voice wave validates on shadow traffic rather than on a production caller. SMS follows, because the delivery-report webhook consumer has to accept staging deliveries before any sender cuts. WhatsApp closes the sequence when you have it — the WABA registration re-attaches, so it never rides the same wave as voice.

1. Voice first — port numbers in waves, re-author on shadow traffic

Connectivity crosses before anything else. Port a non-critical or after-hours line first against the porting mechanics and the country capabilities pages, then batch customer-facing lines once wave one validates. With a validated ported number in hand, re-author the call-flow logic — IVR menus, routing destinations, recording — against the voice channel docs and run it on shadow traffic before any production caller touches it. Telnyx flow definitions are proprietary, so a flow does not import; its routing contract does.

2. SMS — delivery-report consumer stands up before senders cut

A migration fails on the far side, not the send side. Stand up the Orbit delivery-report webhook consumer — the endpoint that accepts delivery events — before any sender identity moves, and cut sender traffic only after the consumer accepts staging deliveries clean. Sender-level configuration is tenant-owned, so the 10DLC or alphanumeric sender-ID registration you audited travels with the move rather than resetting to a platform default. The SMS channel docs carry the webhook event shape. For 10DLC specifically, the 10DLC registration walkthrough covers re-registering the sender identity on the new account before the old one closes.

3. Optional WhatsApp — WABA re-attach, then unified inbox

If the inventory includes WhatsApp scope, move it last and separately. Re-register the WABA on the Orbit account, re-approve the templates, and route the channel into the same unified inbox as SMS — the WhatsApp Business API guide covers the attach sequence. Until that wave validates, hold Telnyx-side WhatsApp traffic live; the channel never rides a voice or SMS wave because the registration re-attach is a Meta-side approval window, not a switch.

Rollback stays open until each wave validates

Rollback is the sequencing rule, not a feature. Because numbers port in waves and the old senders stay live until each wave validates, every step above is reversible by reverting the wave before the next one starts: voice reverts the routing back to the Telnyx connection until the shadow run validates; SMS reverts the sender until the delivery-report consumer accepts staging cleanly; WhatsApp stays Telnyx-side until the WABA re-attach lands. A flow that joined a wave without a validated predecessor is the failure shape the halted-migration recovery walk covers — read it before you need it.

Dry-run checklist and the numbering plan on Orbit

The ordered execution checklist, each row closing on a docs surface:

  1. Export the inventory. Every Telnyx number, connection, messaging profile, and flow definition into one sheet — the registration gate every wave re-checks.
  2. Dry run on staging. Stand up the Orbit account and run the delivery-report consumer and the re-authored flow against staging traffic — a dry run never writes to production and never touches a live caller.
  3. Port numbers in waves — non-critical first, customer-facing in batches — against the porting mechanics and the country capabilities document set that sizes the number plan on Orbit.
  4. SMS senders re-register last of the messaging traffic — per the SMS channel docs — and cut only after the consumer accepts staging deliveries.
  5. Close the Telnyx account only after the last wave validates — rollback stays open because numbers moved in waves and old senders stay live until a wave validates.

Frequently asked questions

Where the voice cutover starts — which number first?

A non-critical or after-hours line. The first wave exists to validate the port and the re-authored flow before any customer-facing number moves; once wave one validates, customer-facing lines batch in. The phone number porting guide walks the bulk portability check, the in-platform LOA, and the port webhooks that tell you a wave landed.

Do my Telnyx call flows import into Orbit?

No — they re-author. Telnyx flow definitions are proprietary, so the routing contract imports and the definition does not. The export sheet inventories every IVR node and routing destination, the programmable-voice surface reproduces the contract node for node, and the rebuilt flow validates on shadow traffic through a ported non-critical number before a production caller touches it.

What moves first, and what moves last?

Inventory first — it is the gate later waves re-check against. Voice numbers then port in waves, SMS senders re-register after the delivery-report consumer stands up, and optional WhatsApp closes the sequence because its WABA re-attach is a Meta approval window, not a switch. Rollback stays open through every step because no wave closes until its predecessor validates.

Where do I compare Telnyx alternatives before committing?

The best Telnyx alternatives 2026 guide scores Orbit, Sinch, Vonage, and Bandwidth for the segment this runbook most often serves. Use it beside the Orbit vs Telnyx head-to-head; this runbook is the migration their comparison decided. The sibling Plivo runbook and Sinch runbook carry the same arc if your inventory spans more than one incumbent.

Published 25 September 2026.

Migrating from Telnyx to Orbit — the runbook — Orbit by Devotel