The Art of Converting Large Customers to Cisco
Freshly off a vacation planned by my lovely wife for my 30th birthday, I figured I would come back and try and blow the wheels off with a new blog post that could really have some effect on the community. In this blog post I will reveal some of the techniques that I use to migrate REALLY big customers to Cisco UC / CC typically from other vendors. That being said earlier this year I found myself migrating thousands of users from an ancient CUCM to a new CUCM in the same environment so it can be used in other places.
In 2007 I had the opportunity to co-lead a project of converting 14 hospital campuses to a centralized mode. The first was the main Campus and the old PBX there had nearly 10,000 users on it. Everyone was terrified of how on earth we would handle data collection, seeing as there was just so many phones. We came up with an automated method that’s saved us thousands of man hours in discovery, and I have now use the process to migrate upwards of 30,000 phones in my career. Today, I open the books on the process that makes the magic happen.
This article is going to focus on a legacy PBX, a ROLM 9006 to be exact. What we will do is use the information in the old PBX, parse it out to something we understand as Cisco engineer’s and this will be a starting point for BAT file creation. I won’t cover any of these tools, I am only going to cover the idea of ‘converting’ the end user information. This strategy can be used for other PBX’s. I have written deep sets of tools like these for ROLM 9005, ROLM 9006, Nortel Meridian and Avaya. I have migrated over 30,000 phones with these techniques, so I promise you, it works.
Overview of Process
The first thing you need to do is understand your PBX. In all honesty I asked an engineer for each PBX to break it down for me AND how to extract the information. Legacy telco engineers know their system as well as we know Cisco, and they can always help!
In the case of the 9006 it included a feature called a ‘regen’. Basically it was a way to dump all the information out of the PBX into flat files in case you needed to regenerate the platform from a tragedy. Good news for us in that day it was plain text flat files, so we get all the information we could ever ask for!
REGEN commands for ROLM 9006
All the below commands would be executed on an ROLM 9006 terminal and saved or logged to file. We will then use these files to parse through to create our end user collection data. The below commands are executed on the ROLM 9006 to collect the data necessary for transformation. Below each command I will show a snippet of what each command output’s, however due to all of my data being customer specific, at this time it is difficult for me to release my test data for tool creation.
- REGEN-KASU – Maps all the key/button assignments to the stations
H500: AMO KASU STARTED ADD-KASU:1709,11,5709,Y,N; ADD-KASU:1711,7,5711,Y,N; ADD-KASU:1712,11,5712,Y,N; ADD-KASU:1713,7,5713,Y,N; ADD-KASU:1714,11,5714,Y,N; ADD-KASU:1717,7,5717,Y,N; ADD-KASU:1719,7,5719,Y,N;
- REGEN-DEST:ALL – Call Forwarding information for each line. (Mostly important in figuring out who has voicemail)
H500: AMO DEST STARTED ADD-DEST:CFW,1701,PHML,1000,; ADD-DEST:CFW,1702,PHML,1000,; ADD-DEST:CFW,1708,VCE,5701,,DN,, 1,1,1,1,1,1,0,0; ADD-DEST:CFW,1709,VCE,5709,5701,DN,DN, 1,1,0,0,2,2,0,0; ADD-DEST:CFW,1711,VCE,5711,,DN,, 1,1,0,0,0,0,0,0;
- REGEN-PERSI – Description information for all of the stations.
H500: AMO PERSI STARTED ADD-PERSI:PINM,4,YES; ADD-PERSI:COSXCD,6; ADD-PERSI:STN,1470,"MA DESK",,,"SURGERY",; ADD-PERSI:STN,1701,"PHONEMAIL DIRECT",,,"",; ADD-PERSI:STN,1702,"PHONEMAIL GUEST",,,"",; ADD-PERSI:STN,1703,"LAB SVCS-LAB",,,"",; ADD-PERSI:STN,1704,"MODEM LOC18",,,"",; ADD-PERSI:STN,1705,"CHAD STACHOWICZ",,,"",; ADD-PERSI:STN,1706,"TEST USER 1",,,"",; ADD-PERSI:STN,1707,"TEST USER 2",,,"",;
- REGEN-PUGRP:SYS – Pickup groups configured and stations configured
H500: AMO PUGRP STARTED ADD-PUGRP: 1,1845&&1848&3025&3200&3840&4027&4029; ADD-PUGRP: 1,4033&4034&4039&5845&&5848&7295&8279; ADD-PUGRP: 1,8416;
- REGEN-SCSU:NONANATE – Station configuration information
H500: AMO SCSU STARTED ADD-SCSU:1704,,1-1-79-22,0,0,9,9,1,1234561234,UNDEFINE, 000000000000,N,,0,ANATE,N,,,,DTMF,Y,,,0,,,5,5, N,N,,N,N,N; ADD-SCSU:1705,,1-1-79-0,0,0,9,9,0,1234567676 ,UNDEFINE, 000000000000,Y,,0,ANATE,N,,,,DTMF,Y,,,10,,,5,5, N,N,,Y,N,N;
You should be able to see that we have almost everything we need to create a pretty decent amount of data about the system automatically. Let’s look at what we can gather from all this garbled junk.
- We can get all the phones and their each of the lines that are on them currently. A lot of old PBX’s use the concept of ‘rollover’, however cisco has true call waiting. I will not account for this in the tool I write in the blog, but all my own tools cleanup rollover as a configuration parameter.
- Also included in the line dump is the Class of Service number for each line. With a little help from the old PBX admin you can easily figure out which number means emergency, local, long distance, and international.;
- We can gather a description off the phone which is usually a name. In most of the tools I have I can match this name against a few different sources to try and generate a match. Usually I use an LDIF dump of AD and try and auto locate their AD to associate to the phone. The description field will also serve as a source of caller ID even if we make no matching utility.
- We can see call forwarding which ultimately tells us if this is a number or user that has voicemail. Between all of this information we have enough information to configure voicemail correctly in BAT as well as generate BULK import files for Unity Connections or Unity.
- We get pickup groups. We can use this information to build an import file for call pickup groups as well as assign them to the appropriate lines.
Considering all this, you can basically eliminate intensive end user discovery and basically send the customer a 80% ready to go copy of their data that just needs review and a bit of touchup. I have had well maintained PBX’s convert at 98% accuracy BEFORE any human review. When I term accuracy I just mean that between converting these flat regen files to Excel’s and the customer making changes, there is none.
Breaking down the 9006
Some important things from the following line of stations regen dump:
ADD-SCSU:1815,,1-2-91-6,0,0,20,20,0,2162344500,UNDEFINE, 000000000000,N,,1,OPTI,N,OEADVPL,,1,,30,,,5,5,OFF,Y, N,NONE,,Y,Y,0,1,N,
- OPTI or PHANTOM type are both important.
- The bolded 5 in the subsection of “5,5,OFF,Y” represents the Class of service of the phone. In our PBX COS translate as below:
- 1815 is the main extension on the phone
- 2162344500 is the ANI on the phone.
A line of Description regen dump is pretty obvious what to do with it:
- 1702 is the main extension of the phone this description is for (and presumably a good source for Caller Id Names)
- PHONEMAIL GUEST in this case is the description for the phone. This example was obviously the voicemail pilot, but other descriptions would have peoples names, conference room names, etc..
A line of the add lines dump (KASU) is pretty easy to read:
- 1709 is the main extension on the phone and 5709 is the extra line on the phone.
- The KASU dump may have multiple entries for each main extension. This would represent Lines 3, 4, 5 and beyond. The order they appear on in the KASU is the order they appear on the users phone
The Call Forwarding is one of the most important of all.
- 1712 is the extension that the forwarding is for.
- 5712 is the forward busy extension.
- 5701 is the forward no answer extension. If you could see the entire dump it would become obvious pretty quickly that 5701 is also the voicemail pilot. We will check for this and set a VM profile. 1701 and 1702 are also VM pilot’s you will see me check for.
Lastly we have the pickup group dump. We will do two things with this dump. First, we will identify our pickup groups and assign them to our phones. The second is generate an import file with out new pickup group’s for BAT.
Let’s take a peak at the dump:
ADD-PUGRP: 1,1845&1848&3025&3200&3840&4027&4029; ADD-PUGRP: 1,4033&4034&4039&5845&5848&7295&8279; ADD-PUGRP: 1,8416;
- Pretty simple, the first number is the pickup group. In this case they are all for pickup group 1.
- All the other numbers separated by ampersand represent the extensions. Two ampersands is a range.
This should give us everything we need to move onto coding this badboy up. There is going to be a bunch.
The code is quite large and is attached as rolm_9006_convert.rb. There is inline comments explaining the areas of each code piece and what it does. One thing you will see me do is set some static values. Like Device Pool, Device CSS and Partition. That because these values are typically always the same per site.
The basic flow is this.
- Read in each of the 5 regen files and parse out the main pieces.
- Build 2 main arrays of hashes in ruby. One array represents the phone and its first line, the second array holds all of the extra lines.
- Methodically match all of the fields together to fill out the array
- 2 generate function which transfer the array’s of hashes into a readable csv
You can find it here ROLM 9006 CONVERT
This is a really powerful tool for converting huge clients, something I have made my name in the industry on doing. I have used this method to convert all types of PBX’s and there are many other tools I have built around this such as:
- Active Directory / LDIFDE export matching on telephone number and description. This allows us to match AD accounts to phones in LDAP integrated environments. It also allows us to generate call managed users as well as Unity Connections Imports.
- Cleanup routines – For example many old PBX’s have the idea of ‘rollover’ extensions where CUCM has call waiting. I always do lots of cleanup and translations in my real code.
- Agent / Skill Group / ACD Pilot Information – In previous installs I have extracted all this to generate the mass of a UCCX or UCCE installation.
- Other PBX – I have tools like this for lots of PBX’s on the market and every time I come to a customer I am migrating with over 500 agents on their old PBX, I usually code it up.
- Custom TAPS utilities to help people placing phones quickly provision them
There was some key people long ago in helping me develop this process. However the main two individuals were Jerry Steinhaur from Berbee and Patrick Nowicki from CDW. They helped me by proving it could be done, and helping me read these archaic PBX’s.
I am also including a file of a finished BAT file generation so people can see what that looks like. Client specific information has been removed.
Pickup Groups BAT – HERE
Phone BAT – HERE
I would love to hear some feedback on this, I spent a long-time writing this blog.
3 responses to “The Art of Converting Large Customers to Cisco”
I recall the phenomena and that you guys did an AMAZING job. Your tenacity in pursuing this solution kept the project on target and attributed to its overall success. It would have been a grueling process had we only depended on unreliable station reviews over the massive footprint and scope of the project.
This is an awesome post. I’m in the process of converting a pretty large Avaya system and this would have been great to use to get all the phones batted in.
Is it possible to get the code for a Nortel conversion? I’d like to try your conversion process out on a small 1500 user system, thanks.