The 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.