Strategies for Migrating an Existing Contact Center to Twilio Flex

Strategies for Migrating an Existing Contact Center to Twilio Flex

Migrating from an existing solution, whether on-premise or SaaS, to Twilio Flex can be challenging to cutover all at once. For many companies, a gradual migration may be preferable. In this session from SIGNAL with Mladen Milanovic and Court Swenson from cloud solution provider Presidio, we covered how to approach incremental migration off of an existing contact center platform, with a deeper dive on how to do so with Cisco UCCE.

Let’s explore!

Complex Migrations

In this video from the Shibuya railway station in Tokyo, 1,200 engineers converted an above ground train track to an underground subway line in under 3.5 hours. With only 5 hours between the last train of the night and the first train of the morning in a station that moves more than 740,000 passengers a day, there was no room for error.

Moving an on-premise contact center to the cloud can be just as complicated. Which is why many businesses do not move their contact centers all at once. Companies like Shopify and Lyft have taken the approach of making the move to Flex incrementally, beginning with small groups and then expanding the implementation to larger groups or more complex use cases.

Building a Bridge

As a developer, your role in a contact center migration is to build a bridge between systems. Where you choose to build that bridge has a huge impact on how difficult it is to build. If you build a bridge in a place without great soil, the engineering task will be much more complex.

So where should you build the bridge in a contact center? Here are three popular options:

1. A specific channel – many Twilio customers get started on a channel like chat or video where all of their agents are segmented out and start fresh with Twilio Flex.
2. Specific call type – this common migration for voice use cases involves transferring over only one type of call, such as technical support or returns.
3. New business unit or use case – more like a hovercraft than a bridge — you don’t need to worry about where to start, because you can effectively go anywhere.

Voice Flow Migration

Taking a closer look at voice flow migration, the challenge is how to take calls from a shared number and send them to the right platform. There are two critical decisions you must make:

Decision 1: How do you get your call from your first platform to your second platform?

To get calls from Twilio to a legacy provider, you have a choice to do it via Direct Inward Dialing (DID) or Session Initiation Protocol (SIP) and whenever possible, SIP is the preferable option.

Decision 2: Who holds the number?

You’ll need to determine when it makes sense to keep the phone number/s with the legacy system and when it makes sense to host it on Twilio.

Transfers can be tricky, and not just the tech behind the actual transfer. Maintaining the context and providing that to agents is paramount. Watch the video to see the code you need to transfer calls from a Twilio SIP call to an external contact center, while providing agents with the right context using either your legacy provider’s REST API or X-Headers on the SIP INVITE.

Migration in Action

Check out the demo with Miladen Milanovic and Court Swenson from Presidio to see what an actual contact center migration looks like. Presidio helps clients migrate on-premise contact centers (such as Cisco, Avaya, and Genesys) to the cloud. Their customers often have made a significant investment in on-premise systems ($1 million+ on a new PBX and ACD ) which are:

• Complex
• Expensive
• Non-flexible
• Not fully depreciated

When they are in so deep on an on-premise system, an incremental migration often makes the most sense. By migrating in stages, these businesses can:

• Preserve their existing investment until it reaches full asset appreciation.
• Begin consumption of digital features.
• Maintain and improve customer experience.
• Adopt new communication channels.
• Minimize migration risks.

Presidio often suggests their clients identify one department (such as the Interactive Voice Response, or IVR) to migrate to the cloud with Twilio. In this case, as soon as they build the cloud IVR, they can start consuming digital features like speech recognition, text to speech, and accepting PCI-compliant payments, which have an immediate impact on the enterprise.

Watch the video to see Milanovic and Swenson demonstrate the following four stages of migration from a Cisco UCCE system to Twilio Flex:

1. Build an IVR on Twilio.

In this example, a company receives the call on their legacy system, routes it to Twilio, processes the call, and sends that context back to agent on the legacy system. This enables immediate implementation of digital features.

2. Migrate a team of agents to Twilio, keep legacy phones.

This method allows an enterprise to migrate a department of agents to new the Twilio Flex desktop while still using their existing enterprise phones to receive the calls and handle the customer interaction. This enables better agent training and adoption.

3. Migrate an entire department to Twilio Flex (including phones and desktop).

By moving the calls over in stages, this final step is the easiest of the migration. The Flex “plumbing” is already in place, so that once an enterprise migrates the entire department, they can instantly take advantage of the full power of Flex as it exists today. Businesses choose to segment departments for migration based on the timing of legacy asset depreciation and new features requirements. Meanwhile, other departments can evaluate the solution.

4. Final step: migrate all departments to Twilio Flex.

In this final step, an enterprise migrates all contact center departments over to Twilio Flex, and only the non-contact center users stay on the on-premise system. Keep in mind that continuing with accurate reporting during the migration is critical. 

Want to dive deeper? Watch the session, and get in touch to see if a migration to Twilio Flex is right for you.