Best Practices (transitioning Mitel to Cisco)? 3

[MitelInMyBlood]

Before I go about reinventing the wheel, has anyone put together a list of bullet items or a transitioning plan when you win the battle (keep your job) but lose the war (Mitel is out, Cisco is in)? The system is too large to even talk about doing a flash cut (1700 users, 2000 lines). Migrating individual users (or even whole departments) looks like it's going to require a lot of extension-specific routes in both systems so users not-yet migrated can still call back & forth between the two systems. Any ideas or best practices?

My initial thoughts are to establish intermachine trunks on the gateways first then move all the externally facing PSTN trunks (Bell, Sprint etc) to the Cisco.

Just feeling a little overwhelmed right now and looking for moral support (or a shoulder to cry on)



Original MUG/NAMU Charter Member

 

[actswitch]

Mate, if you're wishing for a cardiac arrest it must be bad! If it's any consolation, on my project we moved the IT and HR departments over to Cisco and was then told to stop. The company have blamed the recession and a lack of funds, but I belive the negative feedback from the end users is the real reason. At the moment I am upgrading their old LX controllers to brand new MXe raided ones, so we'll be around for a while yet.

Stick that up your chuffer Cisco!

 

[MitelInMyBlood]

This is what I'm hoping will happen, we'll transition a department or two, preferably start with something high-profile, like Marketing and HR, then step back and wait for the fireworks.

I'm an old fart, I'll be 64 in May, been in comms since Boy Scouts, got my 1st class FCC license in 1964, been doing Mitel phones "in-house" for a Fortune-50 company since '86. I'm just too freakin' old for this kind of crap but too young to get Medicare and I am scared to death what the "chosen one" and his band of mental midgets in Washington have up their sleeves in store for folks like me.

Original MUG/NAMU Charter Member

 

[SXWizard]

Get a Mitel 5360 color phone and fire up the MXe with release 4.0 and show the big shots (I use the term loosely) and other persons of influence what they will be giving up. Also, ask the CFO to do a return on investment for the CIsco vs upgrading the Mitel to IP. The Cisco won't fare very well if he looks at the real costs down the road.

 

[Chieft]

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.

 

[MitelInMyBlood]

Chieft: Thanks for your input. We are just a couple weeks away from "launch" and presently attending ACUCW1 training since we have lots of Mitel experience and zero Cisco. ACUCW2 would have probably bben a better course to start with but ACUCW1 will give us the necessary skills to perform MACS, which in a 1600-user office is realistically much of the day-to-day work. There is a VAR coming in to help with the launch and we're supposed to have a couple extra 'grunts' to do the grunt work of physically going to every workstation.

The hill (mountain) to climb is we have 1600 users and our mgmt has made it one of their (and our) "goals" to have all 1600 up and running by Dec 31 and we still have not yet started. The system is still sitting on palets waiting for us (2 of us) to return from "training". The gear isn't even uncrated yet. Looks like there'll be plenty of overtime this summer and fall.

The rollout includes UC and we had hoped to leverage that to use "Presence" indications in lieu of BLF appearances. Unfortunately the phone rollout happens first then UC later, so now it looks like several instrument types we had initially chosen will actually be inadequate (too few line keys) for the Admins. More money. Lots more. Also only the 6-line and 8-line sets support Cisco's equvalent of PKM modules. Translation: Even more money. Even with 50% off MSRP on instruments this is way over the budget number it would have taken to do it with Mitel.

My users are coming from 14-button backlit SS4150 and SS4025 sets and 3/4 of them will wind up with 2-line non-backlit greyscale display phones. (7942G) I hope I'm wrong but I don't think these are going to be well-received, especially when they see the 7945G & 7965G color sets that Sr. mgmt will be getting.



Original MUG/NAMU Charter Member