Twilio recently announced that the Twilio Video WebRTC service will be turned off in December 2024. Video is a core part of infrastructure for telehealth providers; it’s important to plan this kind of transition, to avoid any disruption that impacts provider operations. As a leading webRTC video API provider, we’re deeply familiar with the challenges associated with migration. In this post we’ll aim to cover:

  • High-level best practices
  • Key choices you’ll need to make
  • Timelines and resource requirements

A typical migration has four major phases:

  1. Choosing a new platform
  2. Planning and allocating resources
  3. Writing the code and testing it
  4. Moving traffic

Let’s dive into each of these phases to understand the specific considerations and tradeoffs.

Choosing a Platform

Our recommended approach is to divide your platform evaluation into five topics.

  • Reliability
    There are two aspects of reliability: first, overall service uptime. The importance of uptime is obvious, and in general this is not an area of differentiation for major players that have been operating in this space for several years. Second, whether video sessions reliably connect and remain connected for any user, anywhere in the world, on any network. The big things to ask about here are
    • Does a vendor have in infrastructure in every region where you have users? If not, many of those users will have to route via long-haul, public internet routes, and some of those calls will fail.
    • Do they heavily test and benchmark on a wide variety of real-world networks?
    • Does a vendor heavily test and optimize on a wide variety of real-world devices, including older devices and mobile Safari? Device support is, surprisingly, not something that every video vendor prioritizes.
  • Quality
    Delivering high quality video and audio for telehealth use cases is challenging because of real-world conditions. A majority of calls take place on older devices, cellular networks, and web browsers. A platform vendor should be able to show you benchmarks that tell you how their platform performs on, for example, a poor cellular data or wifi network. The goal should be to send good quality video whenever possible and to gracefully degrade the video quality whenever there are network issues. Look for capabilities like
    • Simulcast
    • Adaptive BitRate
  • Features and Requirements
    If you’re porting an existing application from Twilio Video, our recommendation is to – at least initially – narrow the focus to what you’re using today. It’s natural to have an ambitious roadmap and want to see every feature on that roadmap supported by a platform. However, roadmaps and requirements change over time. A good platform, a platform that is under active development, will add new features every quarter.
    • First, prioritize evaluating how difficult your port from Twilio Video will be. Ensure there aren’t missing features that will require workarounds because that introduces cost and time.
    • Second, look at a vendor’s history of adding new features. Talk to that vendor. Tell them your roadmap and try to get a sense of whether your roadmap aligns with the platform’s roadmaps and commercial goals
  • Compliance
    Compliance is just as important as reliability, call quality, and features. But we’ve left it until next-to-last in the evaluation sequence, simply because in the video space all the established vendors are HIPAA-compliant, operate in ISO 27001 certified data centers, and offer data geo-fencing.

  • Observability & Support
    A video platform should give developers and product teams at least three things:
    • East-to-use dashboards
    • REST API access to all metrics and SDK action logs
    • Enterprise tooling integrations

Finally, good engineering support will, for a lot of customers, make the difference between an easy port and smooth scaling as you grow, versus struggling to ship an application that works well for all users. A good partner will act as a Product Manager who is an extension of your team to help you become successful. Things to look for here are:

  1. Sample code repositories for many common use cases and features.
  2. Guidance on how to tune your video settings to maximize quality and reliability for your use case
  3. Willingness to help debug your application code, even if your problems aren’t directly related to vendor APIs or real-time video.

Planning and resource allocation

Here is a quick rule of thumb:

Two weeks of FTE work for each major part of the application you are porting

  • Real-time video & audio
  • Recording
  • Monitoring, Observability and Data Science

If your team knows your current video implementation, porting should take one engineer about two weeks, or two engineers that work well together about a week.

On the other hand, if your video feature set is complex and includes multiple different video use cases, including recording, and you’ve built out custom integrations at the metrics and data layer, then a port is likely to be much closer to six weeks of FTE work.

Implementing and testing

Here are two considerations that we think are very important.

  1. Initially, do a straight port of your video implementation, changing as little as possible. Don’t add new features to your application during a port. Don’t do any big architectural rewrites.
    1. Combining a porting project with a rewrite is, almost always, a recipe for a slower, riskier implementation. The more code you change at one time, the harder it is to debug, QA, and evaluate.
    2. The fastest, lowest risk approach is port to a new platform while changing as little of your application code as possible. Make sure everything is working as expected in production. After that, turn your attention to architecture improvements and new features!
  2. Don’t build an abstraction layer. Write directly against your platform’s APIs.
    1. Turns out that designing, building, debugging, and maintaining an abstraction layer is a lot more work than doing several ports. An abstraction layer sounds like a good idea, but every single customer we’ve had who set out to build an abstraction layer has abandoned the effort, either before ever getting to production with the abstraction layer, or down the road to improve code maintainability.
    2. Using an abstraction layer prevents you from leveraging the specific strengths of a video platform. This can be okay for very simple apps. But even for simple apps, using the lowest common denominator feature set across multiple vendors is not usually a path to success.

Testing a new video implementation

It’s key to have a testing framework in place. Some principles that we consider core to running a POC, and are indicative of a successful deployment, include:

  • Test on simulated bad networks
    • It’s important to test on simulated bad networks since that will best mimic real-world conditions.
  • Test on a wide variety of devices
    • It’s also important to test on a variety of real-world devices. Android phones, iPhones, and older laptops. Again, your engineering team will likely have fast machines and – for browser-based apps – will tend to test on their laptops during development, not on their phones.
  • Test at scale

Moving traffic

When you’ve tested internally and are ready to move production traffic, we recommend the following sequence:

  1. Set up monitoring
  2. Train your support staff
  3. Move 10 opt-in customer accounts
  4. While monitoring, move 10%, then half, then all of your traffic

In our experience, you will usually find at least one or two bugs in step three, while testing with a handful of accounts that have opted into being beta testers for your new video implementation. But, generally, if you’ve worked closely with your vendor to test on a variety of networks and devices, step four goes smoothly.

Wrapping Up

So how long will all of this take? Of course the most accurate answer is, “it depends.”But, as a rule of thumb, from start to finish a port usually takes between one and three months. A typical migration might look like this:

  • Vendor selection – 2-3 weeks
  • Implementation planning – 2 weeks
  • Implementation and testing – 2 weeks
  • Moving traffic – 2-3 weeks

At the end of the day, migration doesn’t need to be overwhelming. The best way to tackle this is to break the porting process down into defined phases. And do a straight port, initially, changing as little code outside your video implementation as possible. Finally, lean on your vendor. We’re all here to help.

Author: Kwindla Hultman Kramer, CEO, Daily