Migrating to Vobiz: The Complete Telephony Switching Guide (2026)

A hospital cannot shut off its water supply to replace the pipes. The taps keep running while crews work underneath the floor, swapping sections one at a time and pressure-testing each joint before the next cut. Moving a production voice stack off Plivo, Twilio, Exotel, or Telnyx works the same way, since calls cannot stop arriving while you migrate. Telephony migration is the process of moving your voice API integration, SIP trunks, phone numbers, and call-handling logic from one provider to another without dropping live traffic.

This guide covers what actually changes for each of the four providers named above, what Vobiz's own migration tooling does and does not solve, where the real switching costs hide, and the exact cutover sequence engineering teams use to move without an outage.

Why Teams Are Re-Evaluating Their Telephony Provider

A pipeline built around Vapi, Retell AI, ElevenLabs, LiveKit, or Pipecat depends on consistent, low-latency audio and a provider that treats AI voice agents as a first-class workload. Vobiz is built and tuned for that specifically: sub-80ms latency for browser and mobile audio streaming, native SIP and WebSocket integrations for most agent platforms out of the box, and self-serve signup that gets a team from account creation to a live sandbox call in minutes instead of a sales cycle.

For teams with meaningful India traffic, the case sharpens further: India-specific 140/160/92 series numbers, TRAI-compliant DLT registration and GST-ready billing built into the platform rather than added later, and direct support rather than a ticket queue. None of that makes Plivo, Twilio, Exotel, or Telnyx a bad choice — Plivo, Twilio, and Exotel all offer real-time, developer-accessible voice APIs, and Telnyx runs its own private fiber network rather than reselling carrier capacity. The question this guide answers is narrower: for a team building AI voice agents with meaningful India traffic, what specifically changes if you move onto Vobiz?

What Changes When You Migrate: The Five Moving Parts

Every telephony migration, regardless of source provider, touches the same five layers. Understanding them before you start is what turns a stressful weekend cutover into a scheduled, boring one.

Authentication and client setup. Every provider issues its own account identifier and secret, and your codebase's HTTP client or SDK constructor has to change to match. Moving to Vobiz means swapping Account SID/Auth Token pairs (Twilio) or Auth ID/Auth Token pairs (Plivo) for Vobiz's own X-Auth-ID and X-Auth-Token headers, and repointing the base URL to api.vobiz.ai/api/v1.

Call-control markup. Twilio uses TwiML, Plivo uses PlivoXML, Exotel uses its own Applets/flow builder, and Vobiz uses VobizXML. If your IVR logic lives in XML documents your server generates dynamically, every verb needs a mapping check: <Say> becomes <Speak>, and Twilio's <Gather> carries over as <Gather> on Vobiz too, though several of its attributes get renamed underneath — more on that below.

Phone numbers. This is the layer most teams underestimate, and it gets its own section below because the answer is not what most people expect.

SIP trunking configuration. Trunks, credential lists, IP access control lists, and origination URIs need to be re-created on the new platform, with failover and load-balancing rules re-tested rather than assumed to carry over.

Webhooks and signature validation. Every provider signs its inbound webhooks differently to prove the request actually came from them. Twilio signs with X-Twilio-Signature using HMAC-SHA1 over the full reconstructed URL and sorted POST fields; Vobiz signs with X-Vobiz-Signature-V3 using HMAC-SHA256 over the base URL plus a per-request nonce. Vobiz still accepts an older X-Vobiz-Signature-V2 variant and a legacy SHA1-based header for backward compatibility, but new integrations should validate against V3 only. Skipping this step is a common way migrations pass every manual test and then silently drop production traffic, because the webhook handler starts rejecting valid requests as unsigned — or worse, accepts anything because it's still pointed at the deprecated legacy header.

Critical for SaaS & Multi-Tenant Platforms: Vobiz Sub-Account KYC Models

If you run a B2B SaaS platform or multi-tenant system that provisions sub-accounts for your end-customers (e.g., giving each client their own phone numbers or IVR logic), Vobiz’s sub-account architecture works differently than Plivo or Twilio.

Vobiz enforces a strict kyc_mode distinction at the sub-account level:

• personal_use (Internal Workloads): Intended for your own internal operations. Sub-accounts inherit the parent account’s identity verification.
• customer_use (End-User / Multi-Tenant Workloads): Intended if your platform’s end-users or clients make/receive calls under their own legal identity. Each customer_use sub-account requires independent legal verification before traffic can be routed.

What this means for your migration pipeline:

1. Verification Requirements: Onboarding end-customers to customer_use sub-accounts requires submitting verified Indian business credentials—specifically PAN, GST, CIN, and DigiLocker-based Aadhaar verification.
2. API & Workflow Changes: You cannot programmatically provision and instantly route traffic for new end-customers without incorporating this KYC submission flow into your tenant onboarding logic.
3. Migration Lead Time: If you are migrating hundreds of existing multi-tenant sub-accounts off Plivo or Twilio, budget developer time to collect or map your customers' KYC documentation prior to cutover.

Vobiz vs. Plivo, Twilio, Exotel, and Telnyx at a Glance

Sourcing note: Vobiz figures come from its pricing page, its Exotel comparison (self-serve onboarding, 140/160/92 series), and its Plivo, Twilio, and Telnyx comparison pages. Plivo's ₹0.38/min rate and its $1,000/month Enterprise minimum are independently confirmed on Plivo's own pricing page.

Telnyx's per-minute structure is independently confirmed on Telnyx's voice API pricing page.

Twilio's $0.0496–$0.0699/min India rate is taken directly from Twilio's own India voice pricing page, cross-checked against its Elastic SIP Trunking pricing for India; INR conversion uses the mid-market rate at time of writing (~₹95.75/$1).

Migrating from Plivo to Vobiz

Of the four migrations in this guide, this is typically the fastest to execute — the request/response pattern for call control will already feel familiar if you're coming from Plivo, and most of the surface-level work is swapping credentials, the base URL, and one XML verb.

Migration effort by domain: call-control XML, conferences, and recordings are low-effort, mostly namespace and attribute renames. The voice call API and SIP trunking are medium-effort, since Vobiz splits Plivo's unified calls.* actions into dedicated resources: client.play_audio, client.speak_text, client.dtmf, client.record_calls, and client.live_calls, each requiring an explicit auth_id parameter that Plivo's SDK handles implicitly. Phone numbers and sub-accounts are high-effort, because Vobiz uses a pre-provisioned inventory model instead of Plivo's carrier-search-and-buy flow, and Vobiz's sub-accounts add a kyc_mode distinction (personal_use vs. customer_use) plus PAN, GST, CIN, and DigiLocker-based Aadhaar verification that Plivo's flat sub-account model has no equivalent for.

We built a Claude Code skill for this migration — it installs as .claude/skills/plivo-to-vobiz/SKILL.md and does structural code transformation rather than find-and-replace. It threads the required auth_id parameter through every account-scoped call, splits in-call actions into our dedicated resources, converts PlivoXML to VobizXML (including unifying <<GetDigits>/<GetInput> into <Gather>), and rewrites webhook signature validation to our current X-Vobiz-Signature-V3 scheme. Point it at a single file with a prompt like "migrate outbound.py, Python, SDK only" and it produces a focused diff with inline annotations, not a one-shot rewrite of your repo.

Strength: the mapping is mechanical almost everywhere, and Vobiz publishes verb-by-verb and endpoint-by-endpoint tables rather than leaving you to reverse-engineer the differences.

Bottom line: this is the most straightforward migration in this guide — plan for a phased cutover, and most Plivo integrations can move in days, not weeks.

Migrating from Twilio to Vobiz

Twilio migrations follow the same shape as Plivo migrations, with more surface area because Twilio's feature set is broader. Vobiz's migration agent for Twilio installs the same way, as .claude/skills/twilio-to-vobiz/SKILL.md, invoked with /twilio-to-vobiz, and its own verification checklist recommends four gates before cutover: an auth smoke test (one successful read call), an XML byte-compare against a reference render, a signature round-trip test (real callbacks validate true, tampered ones fail), and a parallel-run comparison on a slice of live traffic.

What maps cleanly, per Vobiz's TwiML-to-VobizXML mapping: <Say> becomes <Speak>; <Play>, <Pause>, <Redirect>, <Hangup>, <Record>, and <Stream> all keep their names but change their SDK method calls (say() → add_speak(), pause() → add_wait(), and so on). <Dial><Client> and <Dial><Sip> both become <Dial><User>. One structural gotcha worth flagging: Twilio nests <Conference> inside <Dial>, while Vobiz returns <Conference> as a top-level element directly from <Response> — a difference that won't show up in a quick read-through but will break a naive find-and-replace port.

What doesn't map cleanly: Twilio's call-update model (client.calls(sid).update(...)) fans out into Vobiz's dedicated resources depending on what you're doing mid-call — play_audio, speak_text, dtmf, record_calls, or live_calls — each keyed by (auth_id, call_uuid) instead of just the call SID. On the <Gather> side, attributes get renamed rather than dropped: input becomes inputType, timeout becomes executionTimeout, speechTimeout becomes speechEndTimeout, and Vobiz adds a digitEndTimeout parameter Twilio doesn't have; numDigits and finishOnKey keep their names unchanged. And Twilio's X-Twilio-Signature (HMAC-SHA1, full URL plus sorted POST fields) becomes Vobiz's X-Vobiz-Signature-V3 (HMAC-SHA256, keyed by your Auth Token over the base URL plus a nonce) — not a drop-in swap in your validation middleware, and worth double-checking you're validating against V3, not the legacy SHA1-based header Vobiz still accepts for older integrations.

The migration agent. The Twilio-to-Vobiz skill handles exactly these renames, including the Account-SID-to-Auth-ID mapping and the TwiML verb conversions, producing annotated diffs with reasoning for each change rather than applying changes silently.

Strength: Twilio's own published India voice rates run $0.0496–$0.0699/min — roughly 12 to 17 times Vobiz's ₹0.38/min at current exchange rates — plus TRAI-compliant, GST-ready billing that Twilio's USD-only invoicing doesn't offer Indian entities.

Trade-off: Twilio's breadth, including Segment, SendGrid, Flex, Verify, and a much larger third-party integration ecosystem, has no Vobiz equivalent. This is a voice and messaging migration, not a full CPaaS-suite replacement.

Bottom line: worth doing if voice is the majority of your Twilio bill and you're not deeply dependent on Twilio's adjacent products.

Migrating from Exotel to Vobiz

Exotel isn't primarily a developer-first API platform — our Exotel comparison puts it plainly: Exotel is built for large sales teams, Vobiz is built for developers. Its Harmony platform, regional hubs in India, UAE, and Indonesia, and account-manager-led support model serve contact centers that want a managed product and a relationship, not raw API access — and that's a legitimate reason to stay if it's what your team actually wants, not just inertia.

If it isn't, the migration is mostly a process change rather than a code port. Exotel doesn't publish self-serve pricing — you go through a sales demo — while Vobiz's rates are public and self-serve signup takes about 5 minutes. If your Exotel usage is mostly IVR flows built in their visual builder rather than custom API integration, "migrating" means rebuilding that call flow in VobizXML rather than porting code.

Bottom line: the right move for engineering-led teams who outgrew Exotel's sales-gated model and want to own call logic in code instead of a vendor's flow builder.

Migrating from Telnyx to Vobiz

Telnyx's differentiator is real: it owns and operates its own private fiber network rather than reselling carrier capacity, which is a legitimate technical advantage for latency-sensitive US and global traffic. Vobiz's own Telnyx comparison doesn't dispute this. It credits Telnyx with massive global scale, a developer-centric UI with real-time debugging, and ISO, PCI, HIPAA, and SOC 2 certification that Vobiz does not currently hold.

What actually changes: Telnyx doesn't use a proprietary call-control markup language the way Twilio (TwiML) or Plivo (PlivoXML) do — most Telnyx integrations run over standard SIP trunking or its Call Control API, so there's no XML dialect to convert. The work is the same five-layer swap from earlier in this guide: repoint your SIP trunk's origination and termination URIs and credential lists to Vobiz, swap authentication to X-Auth-ID/X-Auth-Token, re-provision your DIDs from Vobiz's inventory or connect them via BYOC, and re-point webhook URLs to Vobiz's callback structure with X-Vobiz-Signature-V3 validation.

Where Vobiz's case is strongest: India. Telnyx has no India-specific DID series and doesn't support TRAI compliance or India phone support, according to Vobiz's comparison, which lines up with Telnyx being a US-headquartered network operator whose strength is US and global reach, not the Indian regulatory environment specifically.

On pricing, read the fine print. Telnyx's own voice API pricing page lists outbound and inbound calls at $0.002/minute, but that figure sits on top of a separate SIP trunking usage fee — $0.005/minute outbound and $0.0032/minute inbound in Telnyx's own worked example. The all-in cost is higher than the headline number, a pattern worth checking on every provider in this guide, Vobiz included.

Strength: if HIPAA or PCI certification is a hard requirement today, Telnyx currently has compliance credentials Vobiz doesn't. Trade-off: none of that compliance or network investment is India-specific, and Telnyx's own pricing page confirms there's no India rate card at all.

Bottom line: stay with Telnyx if HIPAA/PCI certification is non-negotiable for your business today; move to Vobiz if your traffic is India-heavy and you want a transparent, all-in per-minute rate without adding a separate trunking line item.

The Number Porting Reality Check

You don't have to give up your number to move to Vobiz. Bring Your Own Carrier (BYOC) lets you keep your existing carrier, SBC, or on-premise PBX exactly as it is, and use Vobiz as the platform layer on top — your numbers stay where they are, and we handle the call routing, the AI voice agent integrations, and everything else in this guide from there. In our own words: "Your numbers stay where they are — Vobiz becomes the platform layer on top." Setup is typically same-day.

Setup is typically same-day: you send us your SIP signalling IPs, your numbers in E.164 format, and your origination URI; we whitelist each other's IP ranges, you point your SBC at sip.vobiz.ai, and both sides test bidirectional calls before you're live. No renumbering, no lost caller-ID history, no waiting on a porting request.

What BYOC doesn't do is make Vobiz your carrier of record. Your existing carrier relationship and billing stay exactly where they are, and if you eventually want to consolidate fully onto Vobiz-issued numbers instead, that's a separate, formal number-porting (LNP) process we don't run yet. Our own migration guide is direct about that gap for Plivo specifically: "You cannot port (transfer) a phone number from Plivo to Vobiz. There is no number-porting process.

If full consolidation onto Vobiz numbers is what you're after rather than BYOC, the documented workaround is a staged cutover:

1. Decide between BYOC (keep your existing numbers and carrier, same-day setup via SIP) and buying new Vobiz numbers outright. If you buy new, porting in isn't supported, so keep your old numbers active in parallel during the transition.
2. Attach them to your applications and trunks and confirm routing works end to end.
3. Update every reference, including your app, CRM, website, IVR prompts, and outbound caller ID, to the new numbers.
4. Run the old and new numbers in parallel while traffic shifts over, so callers using the old number still connect.
5. Decommission the old numbers only once you've confirmed traffic has fully moved.

Either way, decide deliberately. BYOC gets you onto Vobiz fastest with zero number disruption; a staged renumbering is the move if you want Vobiz as your carrier of record too.

Talk to your Vobiz contact about which fits before you commit to a migration date.

Compliance: What Doesn't Change When You Switch

Switching providers does not switch which regulator has jurisdiction over your calls. Two examples — one from India, one from the US:

India: TRAI and DLT. Per Exotel's own developer documentation, any business making commercial calls or sending commercial SMS in India needs a consent database with timestamps and source of consent, must pre-approve every message template through the DLT portals of authorized carriers, can only place promotional calls between 9 AM and 9 PM IST, and must screen against the National Do Not Call registry for promotional traffic. Non-compliance carries penalties up to ₹1,000 per complaint per day for calling DNC-registered numbers, plus message blocking and operator blacklisting for repeated violations. None of this is provider-specific. It's a legal obligation on the business, and it survives a switch from Exotel, Plivo, or anyone else to Vobiz unchanged.

United States: A2P 10DLC. The equivalent US framework, as Infobip explains it, requires application-to-person messaging sent from a 10-digit long code to complete a two-step brand-and-campaign registration with US mobile carriers before it can go out reliably: brand registration verifies your business's legal identity and tax ID, and campaign registration ties a specific use case and message examples to that number for carrier review. Unregistered traffic gets blocked, delayed, or throttled, and carriers can suspend non-compliant senders outright. It's primarily an SMS/MMS framework rather than a voice one, but it's the direct US analog to India's DLT regime, and it matters when evaluating any new messaging provider, Vobiz included. Ask whether your new provider has direct carrier relationships that speed up registration, or whether you're routing through an intermediary that adds delay.

The practical takeaway: build your compliance checklist around the regulator, not the vendor, and re-verify it fresh with whichever provider you land on rather than assuming your old provider's compliance setup transfers automatically.

The Cutover Checklist: How to Migrate Without an Outage

Whatever provider you're migrating from, the cutover sequence looks the same:

1. Create a Vobiz account and get credentials, but keep your existing provider's credentials live. Start everything in sandbox.
2. Update your client and environment variables, including new SDK imports and new secret names, in a branch, not in production.
3. Translate your call-control markup to VobizXML, verb by verb, using the comparison pages above for your specific source provider.
4. Redirect webhook URLs and implement Vobiz's X-Vobiz-Signature-V3 validation alongside, not instead of, your existing validation, until you're ready to cut over.
5. Decide between BYOC (keep your existing numbers and carrier, same-day setup via SIP) and buying new Vobiz numbers outright. If you buy new, porting in isn't supported, so keep your old numbers active in parallel during the transition.
6. Run an auth smoke test (one successful read call, like retrieving account details) before touching call flows.
7. Byte-compare your rendered VobizXML against a reference render, and confirm <Gather> uses the renamed attributes (inputType, executionTimeout, speechEndTimeout) rather than the old TwiML or PlivoXML names.
8. Validate the full call flow in sandbox, covering answer, IVR, transfers, recording, and every webhook your app depends on, and run a signature round-trip test to confirm real callbacks validate true and tampered ones fail.
9. Run a canary. Route a small percentage of real traffic to Vobiz while the rest stays on the old provider, and compare call quality, latency, and error rates directly.
10. Migrate remaining traffic in batches, not all at once, and watch call detail records as you go.
11. Monitor, then decommission the old provider's numbers and app only after you've confirmed traffic has fully and stably moved.

How to Choose: Evaluation Criteria Before You Commit

Before picking a target provider, or deciding to stay put, run your shortlist through six questions:

Latency, if you're routing to a voice AI agent. Ask for a specific number, not a marketing range. Vobiz states sub-80ms latency for its WebRTC and voice infrastructure; ask any provider you're evaluating for the equivalent figure and how it's measured.

All-in pricing, not headline pricing. As the Telnyx section above shows, a per-minute voice API fee can sit on top of a separate trunking fee. Ask for the fully loaded cost per minute for your actual call mix, across inbound, outbound, local, and toll-free, not the cheapest line item on the pricing page.

Number portability, in both directions. Can you port a number in from your current provider, or does it support Bring Your Own Carrier as a middle path that avoids renumbering entirely? Can you port a number out later if you switch again? Get this in writing before you commit, for any provider, not just Vobiz.

Regulatory fit for your markets. TRAI/DLT readiness matters if you call into India; HIPAA/PCI matters if you're in US healthcare or payments. No single provider in this guide covers every regulatory regime, so match the provider to your actual footprint.

Migration tooling and support model. A structured migration agent and published verb-by-verb mapping tables, like Vobiz publishes for Plivo and Twilio, meaningfully de-risk a switch compared to reverse-engineering the differences yourself. Ask whether your target provider publishes this for your specific source platform.

Contract structure. None of the providers compared here except Plivo's Enterprise tier publish a required minimum spend, but "no minimum" and "no sales-gated pricing" are different claims. Exotel requires a full sales conversation to see real numbers at all, which is worth knowing before you invest engineering time in an evaluation.

Conclusion

Switching telephony providers is a real engineering project with a real switching cost. The BYOC-versus-full-renumbering question alone means it's worth deciding deliberately rather than defaulting to whichever provider your AI voice agent platform mentions first. The providers compared here each made a coherent bet: Twilio on developer mindshare and breadth, Plivo on low-cost programmable voice, Exotel on India's managed contact-center market, Telnyx on owning its own network. Vobiz's bet is narrower and more specific: voice infrastructure built for AI agents talking to people, priced transparently, with India compliance built in rather than added later. Whether that trade favors a switch depends on how much of your traffic is voice, how much of it touches India, and how attached you are to the phone numbers you already have.

If the fit looks right after working through the sections above, the fastest way to find out for certain is to run the two checks that don't require touching production: compare Vobiz's live pricing against your actual call mix, and provision a sandbox number to test real latency against your own voice agent before committing to a cutover date.

FAQs

Can I keep my existing phone number when I migrate to Vobiz?

Yes — with Bring Your Own Carrier (BYOC), your numbers stay with your existing carrier and Vobiz becomes the platform layer on top, typically set up same-day. What Vobiz doesn't offer yet is a formal number-porting (LNP) process to become your carrier of record; its own documentation is explicit that you cannot port a number in from Plivo, for example. For full consolidation onto Vobiz-issued numbers instead of BYOC, the alternative is provisioning new numbers and running them in parallel with the old ones until traffic fully shifts over.

How much cheaper is Vobiz than Plivo or Twilio for Indian calling?

It depends on which provider. Plivo's own India pricing page lists domestic outbound at ₹0.38/minute, billed in 60-second pulses — matching Vobiz's ₹0.38/min, so cost isn't the reason to choose Vobiz over Plivo; the case there is the AI voice agent integrations, self-serve speed, and TRAI/GST billing instead. Twilio is a different story: its own published India rates run $0.0496–$0.0699/minute, roughly 12 to 17 times Vobiz's rate at current exchange rates. Confirm current rates and exchange rates directly before budgeting, since both move.

How long does a Plivo-to-Vobiz or Twilio-to-Vobiz migration take?

There's no universal number. It depends on how much of your call logic lives in XML flows versus custom code, and whether phone numbers and sub-accounts, the two highest-effort areas per Vobiz's own comparisons, are part of your setup. Vobiz's migration agents are built for scoped, file-by-file migration rather than a single overnight cutover, which points to a realistic timeline of days to a few weeks for most production integrations rather than hours.

Does switching providers change my TRAI or 10DLC compliance obligations?

No. TRAI/DLT rules in India and A2P 10DLC rules in the US are regulatory obligations on your business, not features of any one telephony provider, and they apply regardless of which platform you use. What changes is how much of the compliance workload your new provider handles for you. Vobiz and Exotel both offer India-specific TRAI/GST support, for example, while Telnyx's own pricing and comparison pages show no India-specific compliance tooling.

Is Vobiz a good fit for AI voice agents specifically, or just traditional call center use?

Vobiz is built specifically for the AI voice agent case, with native SIP and WebSocket integrations for Vapi, Retell AI, ElevenLabs, LiveKit, Pipecat, Bolna, Ultravox, and OpenAI Realtime, and a stated sub-80ms latency target aimed at that workload. A provider like Exotel is built more broadly for contact centers, which is a different design center even where the raw voice capability overlaps.

What's the biggest thing teams underestimate when migrating telephony providers?

Based on Vobiz's own migration documentation, it's phone numbers and sub-accounts, both rated high-effort in Vobiz's Plivo and Twilio comparisons, not the call-control code, which tends to map fairly mechanically. Teams that plan for a code migration and don't budget separate time for number reprovisioning and parallel-running old and new numbers are the ones most likely to hit an unplanned gap.