Migration Guide

From Evo Voice
Jump to: navigation, search


This guide is designed for location managers, system integrators, and IT staff that are in charge of migrating a customer from their current platform (e.g. 8x8, Mitel, Cisco) to Evo Voice.

This guide represents our current best practices to ensure a smooth migration. Nothing in this guide is mandatory, but by following this guide, you can ensure a smooth transition with minimum/no downtime.

This guide should be read as soon as the customer is ready to move forward with Evo Voice.

Migration Process

Migrating to Evo Voice consists of a few main steps which will be covered in this guide.

  1. Determining all current call flow scenarios
  2. Create Flows in Evo Voice to handle the various call scenarios listed in step 1.
  3. Creating test numbers to test all the flows ahead of time.
  4. Forwarding existing numbers to test numbers
  5. Submit porting request to Twilio (Evo Voice's carrier)
  6. After the porting request is complete, delete any test numbers.

Determine Call Flow Scenarios

The first step in the process of migrating to Evo Voice is to determine your call flow scenarios. A call flow scenario is the path that an incoming (OR OUTGOING) call can take.

Examples of call flow scenarios are as follows:

  • During business hours, calls to the main number must ring the operators. After hours, calls to the main number should ring voicemail
  • During business hours, calls to John's main number should ring his office phone
  • After hours, calls to John's main number should ring his cell phone
  • When users dial 10 digit numbers, they should be allowed to call the outside world, but they should not be able to dial international.
  • When users dial 0, it should ring the operators

The Evo Voice team can help you determine all of your call flow scenarios.

Create Flows/Test Numbers

During this step, the Evo Voice team will work directly with your team to create and test the flows that you will need for your deployment.

As an example, let's say that we have a main number that must ring the operator staff. We might create a simple flow such as:


Where Patrick is the operator. In order to test this, we need a number which rings, this is where buying a few test phone numbers can help.

Let's go ahead and buy a test phone number under Endpoints. It doesn't matter what area code


NOTE: We recommend giving a tag such as "Test DID" to any test phone numbers which you purchase so that you can easily delete them later

We can now assign this phone number to the Flow we just created, e.g.


And if we call that number, it will ring the operator as expected.

We can proceed to implement Voicemail etc. (this will not be explained here as it is documented elsewhere on this wiki)

Forwarding Existing Numbers

Once you have all of the flows built the way you want them and have tested them fully with the test phone numbers, you can test the system live by setting call forwarding on your existing carrier to forward to the test number that you created.

For example - if you purchased the test number +19738408790 and have that assigned to your Incoming Operators flow, and your actual main # is +13236760869 you can go into your vendor specific portal and configure Call Forwarding for the 323 number to forward always to +19738408790. The details of how to configure this on your current platform are beyond the scope of this article but the support for your current phone system should be able to assist in setting that up. Just don't tell them you're switching to Evo Voice ;)

Now when anyone dials your 323 number, it will forward to your test number and your operators can answer it live! You can repeat this process with all of your phone numbers so that you can be fully live on the system before actually porting. This will allow you to test the system completely and if there are any issues you can just stop forwarding the phone number, fix the issue, and forward again to the test phone number

Submit Porting Request

Once you are confident that the Evo Voice system is ready and you have forwarded all your main numbers to test numbers you will want to submit your porting request to Twilio


The above link explains the information that we need in order to submit the request. Once you have the signed Letter of Authorization and one month's bill/CSR ready, email those documents to your Evo Voice account rep and we will submit the porting request on your behalf. Typically we will receive a date that is about two weeks from when the request is submitted.

Once the porting request has been submitted successfully, these numbers will be ready to configure in Evo Voice. You must Sync Phone Numbers for them to show up:


Once your Phone Numbers show up, don't forget to configure them with the correct Flow/data. Once they port over, they will no longer be forwarding to your test numbers, so you MUST configure your actual phone numbers as well. E.g.


After the Port

Once the port completes, everything should just work. By purchasing test numbers before the port we were able to test all system functionality without having to cross our fingers and pray the day of the port. Assuming all is configured correctly, you shouldn't even notice that the port has completed, everything will just work.

One thing you will want to do about a week after the port is to delete any Test Phone Numbers that you purchased. If you have assigned a tag to your test numbers, this is just a matter of filtering by that tag and deleting those phone numbers.

Using the Forwarding Screen

Evo Voice has an easy way to set up the fields necessary for call forwarding very easily using the Forwarding Screen.

In order to do this, the first thing you will want to do is to create a new Tag called something like "Test DID" and you want to assign that tag to any phone number you have purchased that is for testing. Please note that you can also do this during the Bulk Purchase Phone Numbers process.


The next thing that you optionally will want to do is create a new String Endpoint field (for Phone Numbers) called Dialed Number (or something like that).


Note in the image above how the first 3 phone numbers have the Test DID Tag assigned to them. This means that those numbers are going to be used JUST for forwarding an existing DID to. The Tag could be called anything but it is important because it will be used by the Forwarding screen to find phone numbers to assign.

The second important thing to note in the above screenshot is that those test DIDs are not assigned to any Flow or Customer. This is important because this is how the Forwarding utility knows they are available for use.


Finally - before we begin, you will want to configure your REAL phone numbers (not the Test DIDs) the way they would be in the real world (with the correct flow etc.)

Now let's assume that the numbers in the screen above are the 3 DIDs that we are eventually going to port to Twilio but not yet and For the time being, we want to forward them to a test DID. If we click the Forwarding... button we will see this screen


There are three main fields on this screen that are of use

Customer The customer you want to associate with the Test DIDs that are modified for Forwarding

Tags The tag(s) that the phone number must have to be considered a Test DID (this is the tag we created early to mark our Test DIDs)

Forward Field A string Endpoint field that will store the number of the Phone Number that is being forwarded to the modified Test DID

It is important to note that the purpose of this screen is to do the following things

  1. Find free Phone Numbers that haven't been assigned to any Flow with the Tag(s) you specified
  2. Configure those Phone Numbers exactly like the Phone Number that is going to be forwarded to them
  3. (Optionally) Set the Forward Field value on the Phone Number to the original forwarding number

Filled out it might look like the following:


and if we click the Forward button we will see the following:


Notice how our test DIDs have been configured for forwarding. They have the same flow as our real Phone Numbers and they also have their Dialed Number field filled in with the actual Phone Number.

At this point you will now want to go into your carrier portal and forward each of your actual DIDs to the Test DID.

Please note that if you are using HostedSuite console, you will want to modify your flow slightly so that you still pop if someone calls the Test DID.

Wherever your Dial Node is that rings the operators, you will want to add in this piece of Application Data


Note that this sends the Dialed Number to HostedSuite as an override so that if someone calls your Test DID, instead of popping on +16105578991 for example, we will pop on +13236760869 which is the actual phone number.


In conclusion, we have built the Evo Voice platform to support piecemeal migrations. By purchasing a few test phone numbers, you can quickly and easily test all system functionality before porting. This also allows you to go live before anything is ported.

This process has been tested with large deployments (100+ phone numbers) successfully. We find that the small cost of the test phone numbers (around $1/month per number) is easily offset by the piece of mind which this provides and you will typically only need the test numbers for a month or less.