No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

How to Migrate Voice to the Cloud

2BMKPX2.jpg

Business person pressing button
Image: Prostock-studio - Alamy Stock Photo
Do you feel like you are drowning as you begin to plan out your enterprise voice migration? Moving your voice services to a premise-based solution, a hybrid solution or 100% to the cloud is a lot of work and consumes a lot of time. It also requires very niche knowledge to avoid undertows with the carriers. The following is a high-level overview of how to plan some of your telecom projects. It will help you to logically divide a telecom migration project up into bit-sized chunks so that you feel more in control and less overwhelmed.
 
Telecom migrations are unique when compared to other technology projects. While all technology projects need careful, methodical planning to stay on schedule, telecom projects can be very collaboration intense. Parallel to this are external factors outside your control, such as carrier’s activities. Network engineering teams lay the foundation for voice to avoid jitter and latency while prioritizing voice and creating a dedicated VLAN . Another team in your enterprise will likely handle the DHCP requirements. And another team may provide SFTP services for future telephone firmware updates. Unless you are fortunate to have a large voice services team, you will likely also rely on your field IT techs to help unbox and place telephones and collect the old phones.
 
This is where you really earn your paycheck. Interdepartmental collaboration, playing nicely with others, winning hearts and minds — call it what you want, but getting along with others is absolutely the most valuable skill in IT leadership. There’s a delicate balance to managing people who are outside your department while adhering to a schedule. Building relationships, maintaining open lines of communication, following up and gratitude go a long way. Simultaneously you need to lead from the front while doing much of the work. Respect is earned, not demanded and collaboration is key.
 
Cooperation with your end users is a must. I like to begin each project with a kickoff call that includes a representative from the business. This person will be the SME (subject matter expert) and help to champion the new voice solution to his/her colleagues. I give this person my white-glove treatment and in return, I typically receive the same. It is imperative that I fully understand how the business operates so that I can match up the technology to meet the needs of the business.
 
I always have a conversation where I say, “Not only do I want to know how you do business today, but I also want to know how you would like to do business tomorrow. Because I’m bringing in new technology, I want you to assume we can help to streamline and automate something for you. The sky's the limit. What can we improve?”
 
Sometimes there are no changes. Other times we implement a new design. But no matter what happens, that five-minute conversation helped them to drop their guard, and it let them know I’m on their side and I fully understand that I operate a cost center and we work for them.
 
The following is a high-level outline I follow for my telecom projects. It helps to break down what can feel overwhelming into bite-sized chunks. I prefer the agile method over the waterfall method as many different activities can be addressed early and simultaneously.
 
Tip: I like to create a shared document that holds all documentation about the project in a single document. I give all the stakeholders access and set the expectation that everyone contributes. This eliminates version control issues with documents and it makes it easy for everyone to know that there’s a single place to go for the project.
 
 
Phase One: Discovery
  • Conduct a site survey
    •  Review bills, contracts and services. Is the site one year into a three-year contract for ISDN circuits? Expect to incur ETFs (Early Termination Fees). Perhaps you can prioritize other sites until the obligation is met at this site.
    • It might make sense to also visit the site. Legacy hardware has a way of staying hidden — out of sight, out of mind. But it may also be important to the business. A site visit, along with a thorough tour and conversations with the business can be enlightening!
  • Order carrier customer service records
    • Order customer service records (CSR) as early as possible. It can take weeks - in some cases months to obtain these. These records are critical to knowing what you have, what should be ported and what you can eventually retire.
  • Conduct user interviews
    • I find it helpful to talk to folks - generally a representative from each division or department. The requirements from say, an ER department will be vastly different than the needs of the PFS (Patient Financial Services) department. Do problems exist today? What would they like to have that they can’t do today? Talking to them pays dividends and they often appreciate it too.
Tip: Often these folks will sometimes offer to participate with the project; help draft the test plan - becoming the department’s SME (Subject Matter Expert) and testing on the go live date.
○ Do a data dump from your old system. This data export will be used for analysis - reviewed by the telecom team and the business.
 
Phase Two: Do Multiple Analyses
  • Answer questions about network and voice
    • Is the network ready for voice? Will the pass-through ports on the phones be used, or will dedicated network ports be used? Partner with your network engineers as needed. Establish voice subnets, prioritize voice traffic, etc.
  • Analyze the CSRs
    • Carefully review these records. Often, the “main” number to the business — the number that clients call - is the billing telephone number (BTN). Sometimes this number can't be ported to a new carrier. In these cases, the BTN needs to be changed before you can port your phone numbers. You will need to build a few weeks into the schedule for your carrier to make this change.
  • Analyze the phone system
    • It’s time to review the export from your previous phone system. Whether it’s a few dozen or tens of thousands of records, a spreadsheet will be your home base throughout this analysis. Very large deployments of independent UC systems may benefit from a database in lieu of a spreadsheet. I like to incorporate formulas, such as highlighting duplicate names, or bringing in an email address from another source. Formulas help to identify errors, reduce manual entry and streamline the process.
    • Will you install local hardware? Do you have rackspace, power and network ports for it? This opens up many more questions unique to hardware management.
Phase Three: Plan Thoroughly
  • Draft the scope of work SOW (SOW)
    • I like to break out an SOW for each department helping with the project. Most commonly, I have an SOW for field IT and an SOW for the business. I find that documenting and reviewing it with them helps to put their minds at ease
  • Specify the affected people and processes
    • It’s important to consider how many user licenses are needed and what why specific employees need those licenses?
    • How about other operations — auto attendants, hunt groups, ring downs, etc.?
    • Do call flows follow the sun, or load balance between different facilities?
  • A call center project would benefit from a feature requirement document (FRD). An FRD is just as it sounds. A document which clearly states for all parties involved, all of the features and functionality that the business needs for a new contact center. Typically, this document is drafted by a business, and reviewed by a vendor during the bidding process. It’s also incorporated into the SOW for future reference among both parties. The document is as long as it takes to thoroughly describe the business needs in any situation, at any time, on any day. Some are only four-five pages while others are a small book.
  • Determine the license types and pricing structure
    • UC licenses - With some UCaaS providers, it is necessary to order the quantity of licenses needed by following a strict and regimented process fostered through one of the provider's salespeople. I prefer the UCaaS providers that give me access to a portal where I can assign and remove licenses in real time and billing follows suit - no choke point in the process.
  • SIP trunking (if applicable) — Unfortunately SIP trunking is sometimes still a thing. It’s a throwback to that legacy mindset of the necessity of physical circuits on top of DID numbers all of which were billable items. I prefer a UCaaS solution that bills only by the end-user license - allowing the customer to provide the broadband.
    • Draft a test plan
    • Based on business requirements, the business should help to draft a test plan for the go live date. This might be as simple as testing an auto attendant and a handful of DIDs or it might be much more complex. The test plan should reflect the details outlined within the FRD.
  • Resolve all the details around phone numbers
    • Are you porting existing numbers or ordering new numbers?
    • Do you have toll free (TF) numbers? Where do they point? Are they switched, dedicated, international, etc.?
    • Documenting every phone number in a spreadsheet helps to ensure both the business and the telecom team are on the same page.
  • Order/install network hardware
    • Will new switches or routers be needed?
    • Will new cabling need to be run where phones are placed?
TIP: A strong and collaborative relationship between the voice and network engineering teams and their leadership makes a world of difference.
  • Order voice hardware, such as phones or headsets
  • Don't forget about geography
    • Will your users be at a single address or multiple facilities? Addresses should be carefully documented for e911 compliance.
  • Plan the deployment timing
    • If the project includes multiple sites, will we deploy to one site at a time or all at once? This will likely be influenced by time and resources.
  • Plan the carrier order process
    • Submit the order
    • After the discovery and planning phases, you are ready to place an order. Depending on timing, you might place your order months before your desired go live date.
    • Follow up with the carrier - sometimes a few times.
    • Request the carrier’s project order number (PON)
    • Request the port order number. Note that this is not the same as a project order number.
    • The carrier will eventually provide the Firm Order Commitment date (FOC ). This is the date the carrier agrees to the order. This can be a long and drawn-out process. I’ve seen it take nine months for a large carrier to move numbers from TDM to IP flex, within the same company! But it can also be relatively quick and easy - within a month. Preparation is key, but complexity is the greatest influence.
Tip: Full ports are easier than partial ports. Moving from one address to another can be a challenge. New services can be easy, but can be difficult if new infrastructure is needed. Word to the wise, the carrier does not always agree to your desired date. Work with your account team if it is necessary to alter the go live date after the FOC date is provided. See my article on this topic.
 
Phase Four: Put together a communication plan
  • Who, What, Where, When, How, Why
    • These are all key ingredients to a story and important fundamentals of communicating a change. People are typically adverse to change, so a concise, but thorough message helps folks to accept and embrace it.
    • This should happen weeks before the go live date, a reminder shortly before and again on the go live date. Of course, this is a minimum in my opinion. Business needs and styles vary greatly.

Tip: Everyone has different learning styles. So within my communication announcements, I typically try to provide two forms of delivery: Written instructions and a video. I’ve found that it reduces the questions that come back to our team.

Phase Five: Go live
  • Follow the test plan – and be sure to test 911.
  • Be available
  • Be flexible
Phase Six: Wrapping up the project
  • Meet with the business one last time
    • I generally hold the last meeting a day or two after the cutover.
  • Busy trunks circuits
  • Place disconnect orders
  • Shut down the old phone system (or cancel old UC service)
  • Retire contracts
  • Verify billing stops, validate credit for billing beyond disco date
  • Hold a post-project review. What went well, what could we improve for the next project?
This is a high-level plan which outlines the general principles of a voice migration project. Contact centers are more involved and can take over a year from conception to go live, but this outline is just as accurate. (See my article, “Guiding the conversation around a call center") A small-office project of a couple dozen users can sometimes be completed from start to finish, including porting numbers, in under a month. Every situation is a little different, but the overall approach is the same.
 
Key ingredients to success with these projects are to be thorough, communicate heavily, be flexible, and be proactive. If you plan to migrate multiple sites in different phases, it’s helpful to create your process in a way that’s easily repeatable.
 
I hope you find this useful. You might also find my article “1 Year, 50 Sites: Lessons Learned in Cloud VOIP Projects” useful as you plan your migrations. If you have questions, feel free to connect with me on LinkedIn and message me your questions.