There are just some things you can’t do manually. Migrating several thousand DDI numbers from a Telecom ISDN to SIP is one of those things. Here’s the process one government agency with 20 contact centers used to accomplish this type of migration successfully.
Obviously, if your company is of any size, you will have a lot of DDI numbers to migrate. This agency had 22,000, and some of those numbers connected to 24/7 mission-critical services. While you always want any project to be successful, in this case, it was doubly important because wrong numbers or dropped emergency calls just weren’t an option.
So, where do you start? You will probably want to start with some planning. Well, not planning exactly, more like answering a couple of questions. First, how many numbers can your telecom provisioning system accommodate for migration? For the agency, this was 500 numbers per hour. Second, how much risk can you tolerate? Because of what they do, the agency had very little tolerance for risk. They decided to stagger their migration over a two-week period. This approach accommodated testing in smaller batches and testing earlier so that they could catch issues quicker.
Next, you will need to create a call campaign for testing. For this, you will need a flat file that contains the data for all of the migrated DDI numbers and a pretty simple test case. The agency’s test case was to use automation to call each DDI number. You will also need to configure a couple of gateways. Here’s what this looked like for the agency.
If the DDI number was successfully migrated, it followed this scenario:
- A new SIP gateway intercepts the test call based on the caller identification number (CLID)
- These test calls are then directed to an IVR where they receive a pre-set test message; for example, the agency used, “SIP trunks”.
If the DDI number was not successfully migrated, it followed this scenario:
- An old ISDN gateway intercepts the test call based on the caller identification number (CLID)
- These test calls are then directed to an IVR where they receive a pre-set test message; for example, the agency used, “ISDN trunk”.
The automated solution you use for inbound calling to test the numbers should provide you with a report or log that provides details of the failed calls. Typically, you will discover migration issues that can be resolved with a little manual effort. Using automation, the agency was able to test approximately 1,000 DDI numbers in about 12 minutes. “To be honest, we probably couldn’t have done it manually,” said a member of the agency’s Network Infrastructure Team. “We most likely would have done spot checks in each of the ranges and then taken a reactive ‘wait and see’ approach for any user-reported issues.”
The agency, the New Zealand Ministry of Social Development, concluded their migration with load testing overlaid by functional testing just to ensure there were no quality or functional issues. You can read the full case study on this migration.
Find out more about the Cyara Platform!
