The Key to Successful Voice Migrations


HaileyThe UC team at NetCraftsmen has been very successful in all sorts of client engagements. One thing we’ve never been afraid to take on are migrations (especially large-scale efforts) from a legacy PBX solution to a Cisco UC solution that includes Cisco Unified Communications Manager. In all of our endeavors, we’ve come across various schools of thought as to what the key ingredient is for a successful migration. Some say project management and planning. Others say having a large team with clearly defined roles. I say those things are nice. In fact, they’re great…but ladies and gentleman, I’m here to tell you that the key ingredient to a successful migration (IMO) is none of the above. So, what is it? It’s simple…D-A-T-A. That’s right, data. Everyone has heard of the “garbage in, garbage out” theory and this has never been more relevant than during a migration. Now, there are a lot of things to learn about the legacy PBX before moving forward with migration; however, I find that A LOT of folks tend to overlook how important it is to verify the end user data. The end user data doesn’t just include the phone configurations, either. It also includes things like verifying where a user actually is so they receive the correct phone. If you’re lucky, you have some reporting capabilities that give you a headstart…but you may not. Even if you do, you may not be able to trust the accuracy of the reports you can retrieve. So, getting data means more than just simply pulling reports. It means dedicating some resources and doing a little bit of work the old fashioned way…via feet on the street. Here are just a few examples of things to ponder:

Location (Building/Floor/Room/Cube) – this can be a combination of things that ultimately lead to a user. The typical inclination is “well, we can just get that from ”. Most commonly, I hear “well, that’s in LDAP so no worries”. Well, if you’re LDAP is accurate for everyone and everything, then sweet. Unfortunately, I find this to be a rarity. In many companies, people move around a lot. Over the years, this may not be maintained. So, Joe Schmoe’s location is listed as Rm 711; however, when you get to that location Susie Queue informs you that she’s been sitting there for 2 years and Joe Schmoe moved across the street or up to the 13th floor.

First and Last Name – This is usually straightforward. However, people can and do get married. Sometimes this gets updated and sometimes it doesn’t. This is your chance to make the newlywed happy by getting this data upfront.

Nickname – this is one that can really irritate a user. If the boy named Sue has trained everyone to call him “King T-Rex” and suddenly “Sue Err” shows up as the Cisco Calling Line ID…well, the King may not be so happy with you. This can quickly turn into bad press as we well know that sometimes the only feedback that’s heard is of the bad variety.

Directory Number(s) – this one seems pretty straightforward, but depending on how accurate the PBX data (or phone labels) is – it may not be. A real world example: PBX station dump tells me that User A has 22222 programmed on the phone. However, I find out that 1) User A retired years ago and 2) that extension belongs to someone else. For some reason, I pick up User A’s phone with “22222” written next to the primary line and make a call but 22333 shows up as the Calling Line ID. My point here is that things aren’t always what they seem. When User A left, User B took over that desk and phone; however, due to physical office moves User B ended up at another location where a phone was reconfigured with 22222 and User C received 22333 but the label on the phone wasn’t updated.

I don’t want to bore you with details here and go into the dozens of things you might want to look for because that might turn my “blog” into an “epic” so the items above are just a few examples of data that might require a “feet on the street” approach to verify. In addition, they are also things that are worth finding out about upfront. In some cases, having the right data can save you a logistical headache on cutover day…such as finding that Joe Schmoe no longer sits in Rm 711. You can spare yourself the headache of a technician blindly removing Susie Queue’s phone and replacing it with Joe Schmoe’s as this might make Susie quite unhappy. Conversely, good ol’ Joe might be pretty annoyed to come in and find a legacy phone with no dial tone on Monday. In other cases, it can save you a nasty-gram email or phone call from King T-Rex who’s not happy that everyone is making fun of him after finding out that he’s the boy named Sue.

In closing, I’ll say that each migration is unique. However, I firmly believe in putting feet on the street during the user data survey collection phase of most any migration. I’ve seen folks use other methods (surveys, relying solely on reports from various systems,  ). I’m not saying these things can’t work…but I’ve seen more stumbling than running and that’s unfortunate. The fact of the matter is that sometimes, you have to put in some extra time upfront to get complete and accurate data…and that, my friends, is a major factor in pulling off successful migrations of any size. So far, it’s helped us to not only successfully migrate customers to Cisco UC solutions; but also enjoy a relaxed feeling of confidence on cutover days.

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.