I feel your pain. We are in the middle of doing a similar roll from a seven switch Mitel cluster (6 SX-2000, 1 3300) to Cisco. A couple of key thoughts from our experience may help.
Our first step after installing the CUCM was to move the PSTN lines to the Cisco so Cisco is acting as our gatekeeper to the outside world. All incoming calls are routed first through Cisco. If Cisco does not recognize the number, a generic route pattern in Cisco sends the call to the Mitels. We used N1 PRIs between the two systems.
We moved all users to Unity voicemail within a couple of months of beginning the project. PiMGs are used between the systems for MWI – these require a rolling reset each night.
We also are required to do a department at a time, no interruption of service is allowed, no numbers are to be changed unless the department needs to brought to the corporate norm (5 digit instead of 4, etc). We move between fifty and a hundred users every other day with a team of three. Here is the basic pattern – one person does a walk through discovery verifying phones, cabling, analog devices, and so forth. The programmer takes this information and justifies this with the directory export and presents the amalgamated information to the department for their review and approval. Once approved, no changes can be made until after deployment. The programmer begins developing the BAT (bulk import) files while the first person is training the department’s super users on the Cisco phones. The MAC addresses are scanned into the BAT when it is ready. The person who did the discovery is also making sure that any cabling needed is being done and that the closet has the needed PoE and analog ports and that the UPS is able to handle the new load. The third team member is still working on day to day tasks. After training, the super users are to train their department staff and handle basic use questions including how to set up abbreviated dials through the web interface. Any question the Super Users can’t answer or any thing that isn’t working correctly, the Super User brings to the programmer. Any changes from the approved plan becomes a change order and is dealt with on a as time permits basis.
We plan on deploying up to three sites a week. Currently we are managing to get two done. Mondays are for discovery and training of the following weeks deployment, Tuesday through Thursday are deployment and support, Fridays are for clean up and review as well as all of the other systems we support. Deployments generally take place in the late afternoon and evening – lots of hours, lots of over time.
The day of deployment, two team members deploy phones while the programmer preps the systems by importing the file into Cisco and saving the change file for each device from the Mitel. This save provides all the current phone information including all of the speed dial keys. When most of the phones are plugged in and updated, the BAT file is imported. This is not always perfect but it allows you to set up all your phones at once including every feature on every button. Our current BAT file take up all of the available columns in the Excel file. This does require the all your templates are ready. As soon as the BAT file is imported, the phones will begin to register and any outside call will ring on the Cisco phones. We then delete all of the phones in the BAT file from the Mitel system. Consecutive groups of at least ten are built as route patterns. Single phones are built as speed calls. The speed calls are built as XXXXX to 966XXXXX. The 9 in Mitel sends the call over PRIs to Cisco. In Cisco, we have a translation pattern (96.XXXX) that strips any thing pre-dot coming from Mitel. Cisco recognizes the five digit directory number and routes the call. After each speed call is created, we have to make a directory number in Opsman and sync the Mitel directories. Then all the voicemails have to be adjusted based on whether the person is Unified or no and the MWI must be switched from Mitel to CUCM. Now there is just enough time left to add all of the users to the CCMUser group and associate their devices and permissions.
We began this project in February of 2008, installed the servers by July of 2008, converted several outlying offices as test sites, upgraded the Exchange servers and moved all voicemail users to Unity in January of 2009, upgraded all closets by July of 2009, during this time several new offices were built or acquired and were migrated to Cisco, moved most ACD groups to IPCC by October of 2009, began main corporate campus in earnest in December of 2009. Anticipated completion in December 2010. When finished, we will have converted nearly 12,000 phones from several Mitel, Avaya, and smaller systems onto one Cisco system.
Three absolutes – 1. Get a project charter approved and signed. Do not deviate from the charter. 2. Manage the expectations – tell them what they are getting, what is changing, how it will effect them, and what they can expect as the change is happening. This is not your project. Then tell them again. 3. Start with the basics. Everybody gets the basics. When you are more fluent in the system and the conversion is nearly over, then other services can be considered.
Hope this helps. It is painful. It is possible.
