Migrating from Tropo to Bandwidth
The thought of making the move from the Tropo APIs to Bandwidth’s can be stressful. We understand, and want to make the transition as smooth as possible. To do that, there are 3 important steps you’ll need to take with important considerations along the way:
- Learn the differences between the Bandwidth & Tropo APIs
- Determine and scope what code needs to be changed
- Implement the changes
Learn and document the differences between the APIs
Bandwidth and Tropo’s APIs have many of the basics in common, allowing you to make and receive a phone call, send and receive a text message, the list goes on. How each provider allows its users to accomplish these tasks, however, can differ greatly. Some of the key differences to focus on include:
- Incoming Calls
- Incoming Messages
- Number ordering
- Answer events
- Hangup events
Rest API & Callbacks and VoiceXML
Just about every CPaaS provider on the market has a VoiceXML (VXML) offering. Each provider calls its programming language something slightly different – for example, Bandwidth’s XML offering is called BXML.
In addition to an XML offering, some providers also offer a REST API & Callback option while others just offer the XML. So, what are the differences between these two options?
REST API & Callbacks – Maximum control
Using a REST API with callbacks allows for the most complete control over calls and messaging. Think of this option as a race car with manual control.
For a single call flow, each step needs to be verbosely configured. Incoming calls need to be answered, each call leg must be manually put into a bridge, each call needs to be hung up. Essentially, zero state is managed by your CPaaS provider and must be maintained externally. This leads to EXTREME flexibility.
Examples: Calls can be added and removed to a bridge, allowing developers to add/remove callers on a single bridge. Conference calls have the ability to speak notes or play audio to individual callers. Call recording can be toggled on/off. Calls can be forwarded to simulring any number of phones.
VoiceXML – The easy route
BXML relies on an XML document to control call flows and messaging. Think of this option as a car with an automatic transmission. BXML simplifies complex scenarios like conference calling and simulring forwarding. Where Rest API requires call state to be managed externally, all state for BXML is handled within the XML document.
If your requirements are pretty simple, a BXML option is probably just enough to get the job done. But if you’ve got complex requirements—don’t try to squeeze a round peg through a square hole.
Determine and scope changes
Once you’ve identified the main differences between your Tropo set-up and the Bandwidth APIs, it’s time to scope out any code changes. Some of the key focus points should be around:
- Callstate events, such as:
- Answer
- Hangup
- Gather
- Conference
- Message events, such as:
- Incoming message
- Message delivered
- Message error
- Group message
- Database changes
Most of the call logic remains the same, but it’s important to spend time investigating the code around the logic. Certain things like message and call creation require different parameters for Bandwidth vs. Tropo. Additionally, it’s important to keep any database tables and calls up-to-date to reflect how your chosen provider will track usage. You must also ensure that any endpoints are updated to accept your provider’s callbacks. Depending on whether you’re using a REST API or BXML, you should expect different responses based on your configuration.
For this step, focus on identifying the pieces of code that interact with Tropo and estimate the amount of work involved to transform them to fit Bandwidth’s API.
Implement the change
Implementing the changes you discover in your evaluation process will take varying amounts of time based on the business logic. Some Bandwidth customers have been able to migrate in about a week with a single engineer, while other customers with more complicated call flows migrated in a month or so with a team of developers.
Luckily, both Tropo and Bandwidth’s offerings require the same level of fine-grained thinking. Each ‘call event’ has to be handled somewhere or another. Each incoming message will always be sent to a callback URL.
Having a keen eye for detail is the key for success in this process. Be sure to narrow and focus on any tricks or hacks used to achieve certain flows in your original configuration. You typically don’t want to perpetuate these activities in the long run. Also, you’ll want to check out Bandwidth’s SDKs along the way to help ease your transition.
Don’t hesitate to reach out
Have questions about migrating from Tropo to Bandwidth? You can check out one of our migration guides, or reach out to one of our experts — they’re always happy to help.
