WebRTC.ventures recently completed a Kurento to LiveKit migration for a client running one of the more complex real-time platforms we’ve worked on, and we did it without downtime. The platform had conferences, webinars, inbound telephony (call center), outbound telephony, recordings, and live transcription and translation in English and Spanish — all in production, serving real users every day throughout the entire migration.
This post covers the key decisions and findings. The full technical case study, including architecture diagrams and a complete phased rollout, is available as a white paper. Download it below.
Evaluating Kurento Alternatives
Kurento had served the platform well, but it was no longer the best foundation for the next stage of growth, and it was time to evaluate Kurento replacements. The Kurento project itself had slowed into maintenance mode, and newer real-time communications platforms were advancing faster in WebRTC support, codec capabilities, scalability, developer tooling, and ecosystem momentum.
The existing stack (FreeSWITCH, JavaESL, and another service to handle the call center flow) also carried growing operational complexity across Kurento and the telephony infrastructure. That made scaling, troubleshooting, and extending the system increasingly expensive.
Finally, the call center was built around a rigid scripted IVR, not dynamic AI-driven conversations. Supporting modern AI voice agents would have required a more major rebuild.
Choosing LiveKit Over Other WebRTC Media Servers
We evaluated four open-source media servers: Janus, Jitsi, mediasoup, and LiveKit. All four are solid, quality platforms, and so the choice came down to requirements. SIP support, recordings, AI agent integration, and horizontal scaling were non-negotiable, and that narrowed the field quickly. Timing played a role too: LiveKit’s SIP server wasn’t production-ready when we first looked. A few months later it was, and that settled it.
The trade-off we accepted is worth naming: LiveKit abstracts signaling, state management, and media routing. It is faster to build on, but offers less low-level control than Kurento and the other three options we considered. For a migration under time pressure, the speed advantage outweighed the loss of low-level control.
Further Reading: Open Source WebRTC Media Servers: Choosing the Right One for Your Use Case
How We Sequenced the Kurento to LiveKit Migration
We sequenced the rollout by priority: conferences and webinars first, then telephony and the call center. The call center was a critical feature and we wanted to validate performance there before moving on to recordings and transcription/translation, which we expected to be more straightforward. Those came last.
Callers now land directly in a LiveKit room via LiveKit’s SIP integration, with a voice agent already present. No routing chain, no IVR menu, and no handoffs. Just a natural conversation.
Results: LiveKit in Production
The migration resolved all three problems we started with: scale ceilings, cost, and fragility. It also unlocked AI capabilities that would have required significant rework on the old stack. The specific metrics, the before-and-after architecture, and five production pitfalls to avoid in your own migration are all in the LiveKit migration case study, now available to download.
WebRTC.ventures is a LiveKit Development Partner specializing in complex real-time applications. Get in touch if you’re planning a similar migration.
