How to Migrate From Retell or Vapi to Your Own LiveKit Stack (Without Dropping a Call)

Should you actually migrate off Retell or Vapi?

Only for three reasons: cost at volume, control you can't get from the platform, or a compliance and data-residency posture you have to own. If none of those apply, stay, and I say that as someone who makes money doing these migrations.

It matters that I'm not a vendor sceptic. I integrated Retell into a production AI interview platform in 48 hours, and that integration drove false positives from 50% to 15%, a 70% reduction Retell published as an official customer case study. It was the right decision at the time and got us to market faster than building would have. Later, at volume, I replaced it with a custom LiveKit stack and took per-minute cost from about 10¢ to about 2.5¢ with quality unchanged. Both decisions were correct. They were correct at different times.

The reasons that don't justify migrating: a vendor price increase you haven't modelled against your own engineering cost, a desire to "own the stack" as an end in itself, and an engineer who wants to build it. All three are real and none survives contact with the break-even arithmetic, which says that below roughly 20,000 minutes a month a managed platform is cheaper all-in once you count two engineer-days a month of maintenance. That model is in the voice AI build vs buy break-even, and if it says buy, believe it.

The reader I'm writing for has already crossed that line. Their bill has become visible to finance, they have real customers on real numbers, and their fear isn't technical difficulty; it's a bad week. That fear is correct, and the rest of this post is about making the bad week impossible rather than unlikely.

“Both decisions were right at the time. The platform got us to market and the custom stack got us margin. Anyone telling you those are opposing philosophies is selling one of them.”— Neeraj Sharma, founder of Axionry

What are you actually replacing?

The orchestration layer, which is the easy part, and then about twenty platform features you forgot you were using. The pipeline is two weeks. The parity list is the project.

Read Retell's own pricing page as a requirements document and the scale is obvious. Beyond voice infrastructure, LLM and TTS, they sell call transfer, appointment booking, knowledge base, IVR navigation, batch and campaign calling, branded caller ID, verified phone numbers, post-call analysis, AI quality assurance, advanced denoising, safety guardrails, PII removal, webhooks, simulation testing, call analytics and transcripts. Several are priced as add-ons: knowledge base at +$0.005 a minute, denoising +$0.005, guardrails +$0.005, PII removal +$0.01, AI QA at $0.10 a minute after the first 100 free.

The useful realisation is that you can skip about a third of it. Most teams aren't using campaign calling, IVR navigation or AI quality assurance, and the ones who are usually know. Go through the list with the person who owns the agent's behaviour, not the engineer who will build it, because they'll give different answers and only one is right.

What you can't skip is the operational surface. Your ops team looks at a dashboard every day. Somebody reads transcripts. Something downstream consumes post-call summaries. Those aren't features of the voice pipeline; they're features of the workflow around it, and rebuilding them is real work nobody puts in the estimate.

How do you prove the new stack is as good before cutting over?

Shadow mode plus five numeric parity gates defined before you start. Everyone writes about how to build the new thing. Almost nobody writes about how to prove it's as good as the old thing, which is the actual hard part and the only thing a nervous VP wants to see.

The five metrics that must reach parity: task success rate on your own definition of success, false-interruption rate, voice-to-voice p95 latency, transcription accuracy on your domain vocabulary, and cost per completed call. Four of the five are measurable on your current vendor stack today, which is why week one exists. Define the gate values before you build, because gates set afterwards are set to whatever you achieved.

Shadow mode has an easy version and a hard version; start with the easy one. The easy version is offline: pull a corpus of recorded calls, replay the audio through the new stack, and score the outputs against the vendor's transcripts and outcomes. The hard version forks live audio so both stacks process the same call in real time while only the vendor's audio reaches the caller. Offline gets you 80% of the confidence for 20% of the work, and it's repeatable in CI afterwards.

The metric people forget is cost per completed call, as distinct from cost per minute. A cheaper per-minute stack that takes longer to resolve the same request isn't cheaper. Measure the whole call, including the ones that fail and get retried, and compare against the vendor's per-minute rate times its actual average handle time.

How do you cut over traffic safely?

1% → 5% → 25% → 100%, holding each gate for at least 48 hours of real traffic, with a numeric rollback trigger agreed before the ramp starts. Qualitative triggers don't work: "if it looks bad" means the person with the strongest opinion decides, at 2am, without data.

Route by a deterministic hash of the caller's number rather than randomly per call. A given caller then gets a consistent experience across the migration instead of flipping between two agents with two different voices between calls, which is confusing in a way that generates support tickets you'll misdiagnose as quality problems.

Rollback must be one change. A feature flag or a single config value that returns 100% of traffic to the vendor, tested before the ramp begins, documented in a runbook that names who is allowed to pull it without asking. If rolling back requires a deploy, you don't have a rollback; you have an intention.

And keep the vendor account funded for 60 days after you hit 100%. It costs almost nothing on a pay-as-you-go plan and is the difference between a rollback and an outage in week nine, when you discover the failure mode that only appears on the third Tuesday of a month.

import hashlib

# The ONLY thing you change to roll back. Set to 0.0 and everything
# returns to the vendor on the next inbound call. No deploy required.
RAMP = 0.05          # 0.01 -> 0.05 -> 0.25 -> 1.0

def route_call(caller_number: str) -> str:
    """Deterministic per-caller routing, so one caller sees one stack."""
    digest = hashlib.sha256(caller_number.encode()).digest()
    bucket = int.from_bytes(digest[:4], "big") / 0xFFFFFFFF   # 0.0 .. 1.0
    return "livekit" if bucket < RAMP else "vendor"

# Emit the routing decision on every call. Without it you cannot attribute
# a complaint to a stack, and every incident becomes a guess.
def on_inbound(caller_number: str):
    stack = route_call(caller_number)
    log({"evt": "route", "caller_hash": caller_number[-4:], "stack": stack,
         "ramp": RAMP})
    return stack

# What this does NOT handle: callers who switch numbers, outbound campaigns
# (hash the destination instead), or per-customer pinning for named accounts.

What will go wrong?

Turn-taking will feel different before your metrics say anything is wrong. Customers will treat the voice change as a product change. Vendor concurrency limits you never hit will become limits you have to provision. And your transcripts will differ, quietly breaking everything downstream of them.

Turn-taking is the one that catches people. Every platform makes different endpointing choices, and callers notice a change in conversational rhythm long before a false-interruption metric moves enough to be significant. Expect a week of tuning after each gate, and expect the qualitative feedback before the quantitative signal. The mechanics of what to tune are in turn detection and barge-in for voice agents.

The voice change is a product decision engineers make by accident. If your callers have heard the same voice for a year, changing it is customer-visible and belongs in a release note, not a config diff. Pick the new voice with whoever owns the brand, and pick it before the ramp rather than during it.

The transcript drift is the subtle one. Different STT models format numbers, punctuation and proper nouns differently, and anything downstream that parses transcripts, analytics, CRM enrichment, QA scoring, keyword alerts, was tuned against the old format. Diff a hundred transcripts across both stacks before you ramp, and check what consumes them.

What do you actually lose?

A dashboard your ops team likes, a support contact who answers, somebody else's compliance posture, and somebody else's pager. These are real losses, not all recoverable, and a migration guide that omits them is marketing.

The dashboard generates the most internal friction and the least engineering respect. Your ops team has muscle memory for a UI they use daily, and replacing it with Grafana and a transcript viewer is a downgrade in their experience even when it's an upgrade in capability. Budget time for it, involve them before the ramp, and accept that the first version will be worse.

The compliance posture can block the whole project. On a vendor, one SOC 2 report and one BAA cover the pipeline. On your own stack, every provider in the chain needs its own agreement: Deepgram signs BAAs for enterprise customers handling ePHI, Rime offers a BAA on Enterprise, LiveKit lists HIPAA compliance on its Scale plan. That's a procurement project running in parallel with the engineering, and procurement doesn't compress to fit a sprint.

The pager is the honest one. On a vendor, a 3am failure is someone else's night. On your own stack it's yours, and voice failures happen while a customer is on the line. Mitigate with real alerting, provider fallbacks and a runbook, but don't pretend the burden moved anywhere other than onto your team.

What would I do differently?

Instrument first, and take the eval harness seriously the first time rather than the second. Every mistake I made in this migration traces back to measuring late, and every week I lost went to arguing about whether something had regressed instead of looking it up.

The second is to decide the voice earlier. It's a small decision that turns into a large one the moment a customer notices, and much cheaper to make deliberately in week two than to relitigate at gate 3 with traffic already flowing.

The third is to run the procurement track in parallel from day one. If any of your customers care about a BAA or data residency, start collecting agreements from every provider in the chain in week one. The engineering finishes in six weeks. The paperwork doesn't, and it's the paperwork that decides whether you can ramp past 25%.

If you want the underlying architecture rather than the migration mechanics, that's the full LiveKit voice AI build guide. If you want the telephony half specifically, it's in LiveKit SIP trunking with Twilio vs Telnyx. Before any of it, price your current volume on a custom stack in the voice AI cost calculator: if the saving doesn't cover two engineer-days a month, stop here and stay where you are. And if it does, and you'd rather have this run by someone who's already done it on a platform with real customers on it, that's exactly what voice AI development is.