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

 

[pablo100]

hey, first of all, take a deep breath and have a stiff drink.

It is not completely out of this world to 'cut over' 1700 users to another system over a weekend, or any other time period for that matter.

First of all, some questions:

1. The existing Mitel system, is it a brilliant, fantasticly reliable, easy to use Sx2000 TDM swtich, or a ip 3100/3300?

2. Lines, are they ISDN30e, T1,DASS/DPNSS, or other?

3. Customer wiring infrastructure, CAT5e or something else?

4. Existing data/Lan infrastructure. Is it Cisco router based, what Lan switches is the customer using? Layer 2/3, is POE a possible upgrade?

If you were replacing a TDM SX2K, my thinking would be to install the Cisco Callmanager and phones alongside the SX2k (users would have two phones on their desk, much as like a large broadcasting corp. in the UK has at the moment in the UK) with Qsig/DPNSS links between the two, program all of the incoming and outgoing trunks on the Cisco, and, Test as much as you can exhaustively over a period of time, paying attention to your users feedback with regards to feature comparison between the two systems.

All the best, and keep us posted on your progress.

If you can't beat them, join them.

 

[LoopyLou]

No best practises that I know of. You seem to be on the ball with it. As you say you need to connect the two systems. The problem is servicing the users on both systems. You should have the PSTN and Voicemail where ever the bulk of the users are because the number of connections you have between the two systems will dictate how many users can be serviced on the system without both the above. So if you move 500 users for example, to the Cisco you still have 1200 on the Mitel, so that is where PSTN and VM should be. If you have enought PSTN links you might be able to split them between systems as a interm step.

 

[kwbMitel]

First Off, My condolences.

Best practice, keep it simple. Don't try to do too much over the link.

Link via Qsig trunks.

If you can convince the powers that be, keep applications separate. This includes VM. Cisco phones have Cisco VM and Mitel has Mitel VM and never the twain shall meet. Integration of VM over Qsig is fraught with grief. (not saying it's not possible mind you)

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[MitelInMyBlood]

Thanks all.

The Mitel is SX2000 TDM, redundant main control & expanded pers.

We -do have- a 3300 MXe (Rls 9. somthing) on site that we've been playing with.

There are 40 wiring closets in the building, 200 pr to each from the MDF (ADC High density frame, proprietary punch down). House cables are all 200 pr conventional 26 ga telephone cable, 8 binders. Plans are to eventually abandon this infrastructure.

Horizontal (voice) cabling from each wiring closet to the floor is Cat5E, but fanned and punched down on 66 blocks, all 4 pair each. Plans are to abandon this infrastructure as well.

Horizontal DATA cabling is all in patch panels below new Cisco POE switches. There are at least TWO cat5E data drops to each workstation and office. In some larger offices there are a total of FOUR cat5E data drops.

All data drops are "hot" (plugged into the POE switch) whether they are used or not. Yes, that means there are a lot of wasted ports, though I believe this will work to our benefit.

VoiceMail today is on a separate (Octel) system hosted on the SX2K. In addition to plain vanilla voice mail there are many (about 200) menu trees and specialized apps on the Octel. Going forward user's voice mail will be hosted on a Cisco Unity system. My thinking is leave folks' voice mail where they are now until they get new phones. That should reduce some of the intermachine traffic but will kill the ability to forward voice mail messages back & forth. Sorry, users will just have to suck it up.

I really do not want to ever have two instruments on anyone's desk, so when the Grim Reaper comes to change their phone, that will be that.

The Cisco phones will have their MAC addresses hard-coded in the call manager for reasons I'm not sure I understand. I don't know if that's a limit/requirement of the CM, just that's what we've been told is how it will be done. That sounds to me like a genuine PITA as it means we'll have to physically open every phone or break down every case of phones and then keep track of who we give each one to.

Going forward not everyone will be receiving a physical phone in place of their Mitel phone. Some (as yet undetermined) number of users will be getting softphones (CUP-C clients) and USB headsets. I expect there will be a LOT of pushback on that, as wired headsets cause user fatigue and wireless USB headsets cost more than giving the user a physical instrument. That should prove interesting.

We're wrestling with how best to do the trunking (provisioning) between the Mitel & Cisco during the transitioning phase. Yes, QSIG for sure, here's the rub: Mgmt is wanting to roll out the Cisco to entire departments at a time, but over the past 20 years the number blocks have become horribly fragmented (because everyone gets to keep their number when they move). Mgmt's plan would require explicit ARS entries between the two systems for every person that moves. OUR (tech's) idea is to roll-out the Cisco across fully contiguous number blocks, 100 at a time. That of course will screw-up key appearances for the admins and call pickup groups and will have us running all over the building replacing phones, but is most intuitive from an intermachine routing standpoint. I'm looking for others' input on this.

Mgmt. thinks going forward with IP phones will eliminate MACS. Well certainly it will eliminate the MDF and riser room wiring changes, but I think we're still going to find ourselves physically moving a lot of phones, for a couple reasons: Cooties and attrition.

In this day of heightened awareness of disease NOBODY want's anyone else's phone unless it's been dipped, sanitized, fumagated and put through an Autoclave. It's a fact that many women are slobs. Several of their handsets are caked in makeup and hairspray, and "stink" of the various mixtures of whore-dip that encrust them. Fingernail filings in and around the keypad, etc. Yeccchhhht! As for attrition, our company, like many big companies is a revolving door of retirees, terminations and new hires. Even with 1700 instruments we don't have enough to put a phone everywhere (vacant cubes, etc) and so depend on a certain amount of churn to shuffle our inventory around. To equip every workstation with a phone would take close to 2000 instruments. That's 300 more phones that weren't in the bid.



Original MUG/NAMU Charter Member

 

[Waldosworld]

1. PRI's to both systems. 1st inbound on the 2k. Adjust ARS to create seperate trunk groups and use lists to balance.
2. A simple ARS route where the first digit + the balance for extensions be programmed on both systems across QSIG links.
3. As you deprogram and reprogram the what was a valid extension becomes a valid ARS route on the 2K. Until the sets are deployed on the Cisco you have a valid ARS to send to the 2K if it calls come in on the other PRI.
The trick here is as the Cisco gets more populated than the 2K swap the PRI links.
4. Voicemail is the tricky thing here as msg waiting types may become an issue. Also if trying to keep one the original voceimail system and calls hit the 2k transferred to the new Cisco only to be forwarded back to the voicemail on the 2K will use 2 channels unless release link trunks is optioned on the 2K.

 

[MitelInMyBlood]

Thanks Waldosworldfor the suggestion.
A problem we're expecting or anticipating (and trying to avoid) is how to handle the random "unassigned" number within a contiguous block of numbers so that an errant call doesn't loop and diminish your intermachine trunk resources. I realize we can control this on the Mitel with max forward hops, but unsure if that event is shared w/the Cisco.

I'm simply looking for the best way to avoid having to make a blue-bazillion extension-explicit ARS entries on either system while still allowing valid extensions on both systems to still call one another. Programming a "range" or contiguous block of numbers in ARS is going to cause an unassigned number in the middle of that range to spin.

.

Original MUG/NAMU Charter Member

 

[Opsmgr06]

Have done something similiar with a large cluster 5000 users plus going to Call Manager,for TDM to CM Q-Sig integration works well and we used SIP Trunking MN3300 to CM integration as well both with no real issues only CM configuration stuff.
unfortunately individual routing is the best way forward,
but in this case moved all users to to SIP Gateway MXe via OPS then deleted the entries against the MXe and hand cranked the individual ARS routes across to the CM.
The only engineer concern is that you will get a point where the shift of lines from Mitel to Cisco will be critical when you reach the halfway mark as Waldosworld has mentioned, you risk congestion caused by the internal traffic alone.So an analysis of traffic by department would help you plan their migration.
In short this is the same scenario as to most swap outs or phased migrations to new systems its not generally fun and the programming gets more inventive as you get closer to the new system becoming fully operational.

 

[pablo100]

With regard to the MAC address problem that was raised in the earlier posting, from new, the Cisco 79xx srs phones are delivered in overpacks of 8 and the MAC adresses are printed on the outside of the carton in the form of a barcode.

In the past i have used a barcode scanner ( available here in the uk for around £35 ) to scan-in the MAC adresses to an excel spreadshhet. Most of the commercially available barcode scanners have a built in keyboard emulator and, when pluggrd in to PC usb port, appear to the pc as a keyboard device.

keep us informed, sad to see the demise of a perfectly brilliant PABX that happens to be my personal favourite with regard to repairing the cards day in day out...........

 

[MitelInMyBlood]

Again thanks

Having to hard-code MAC addresses for every instrument then take care during physical deployment to hand the right instrument to the right user seems terribly unintuitive - first thought that comes to mind is what a POS! There also seems to be a huge feature gap in that the system at first glance seems not to offer feature access codes. That is going to bite the analog Polycom users in the conference rooms. Looks like it's supported in CM Express, why not in CM? (or did I miss something?)

Original MUG/NAMU Charter Member

 

[MitelInMyBlood]

Opsmgr06 I have a question for you. Since ours is a business critical daily operation, with small admin staffs each supporting large numbers of users (key appearances, a variety of different rollover rules (admin first then VM or VM first then zero-out to admin, BLFs on PKMs, etc) I really don't think it prudent for us to even attempt a flash-cut over a weekend. I would think Monday AM we'd be swampped with issues. What do you think?

I'm also a little unsure about eating this elephant, ie, where to start?

Working with contiguous blocks of numbers has been vetoed. The directive is "by department" which of course means explicit ARS routes and as you say, monitoring traffic and realizing when it's time to swing the PSTN trunks from one system to the other. I see opportunities for lots of overtime, but not looking forward to it.





Original MUG/NAMU Charter Member

 

[Opsmgr06]

MitelInMyBlood, I have been your position a few times now and despite previous experiences it still becames very painful.
I would firstly setup a test group on the Call Mangler and connect upto the Mitels with either Q-sig or SIP, and assess the loss of functionality between the two systems so you are fully "armed" with the facts (end users do complain bitterly when something is taken away from them or it changes)
From this "gentle exercise" is would allow you to gauge all aspects of all potential "elephants" in the room, and then pass this up to the person who championed this project to do the politics angle and leave you to do the engineering to plan your migration.
Given previous experience and how good your CM guy is you can do nearly 50 sets a day with a team of 4, and that is providing handsets are all built.
The real issue for you will be the key appearances/blf etc as this will more than likely not work between the two systems, so the basis of your interoperability test will decide who goes first i.e. the easiest to migrate.
I also changed the mitel extn from 2000 to 20#00 and put a # infront of the name as well so if a rollback was required to the mitel, it could be done very quickly.

I hope this is of some help

 

[actswitch]

My deepest condolences MIMB. Since telephony became part of the data world IT managers have mistakenly believed that Cisco offer the best solution. They all seem to be brainwashed by the ‘C’ word. I have installed both Mitel and Cisco PBX’s, and the Mitel is far, far superior.
Opsmgr06 makes a very valid point. Key appearances, BLF’s and secretary/manager setups are notoriously flakey on the Call Manager. But hey – you can get your phone to play the Muppet theme tune!

Anyway, rant over. I have a London based customer in a similar position to yourself with a Mitel network converging over a period of time to Cisco. We have 4 x Q-sig links between the two networks and a 4 digit disparate numbering scheme. To overcome massive ARS programming we have put the onus on the user. We created an ARS route to Cisco of 700 + 4 digits, digit modification absorbs 3. If a user is extension 1234, he call forwards his phone to 7001234. Voila! And it’s easy to roll back. You could invoke this yourself with 3rd party call forwarding. The PSTN links will stay on the Mitel until all the users have been migrated.

Another way that may work is to create ARS wildcards. For example, if all your extensions are 1xxx, 2xxx and 3xxx create ARS entries to the Cisco of 1+3, 2+3 and 3+3. The Mitel will look at a dialled number, check internal numbering first, if that fails check ARS routing = match. I may be teaching my Grandma to suck eggs here.

Good luck mate, keep us informed of your progress.

 

[kwbMitel]

MIMB:

I was going to suggest something very similar to what Actswitch suggests. In my version however, I would experiment with the feasibility of using Clustering to link to the Cisco. I've never tried to cluster to a Non-Mitel but I believe it is possible and it would simplify your ARS immensely.

My other suggestion would be to relax your stance regarding not having 2 devices on the desktop. This way you can fully test the Cisco set and leave yourself an easy fallback position.

Once testing is complete the next step is to renumber the Mitel Set (easiest method is to add digits, my personal favorite is 9*XXXX) Then add the DN into the remote directory and physically remove the Mitel set. By leaving the Mitel programming in place you can refer back to the programming should any functionality issues arise after the fact.

Last step is to remove the Mitel programming at your leisure.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[kwbMitel]

Ignore the cluster part. Just checked, can't be done after all.

This being the case I would setup an ARS route with 4 leading digits followed by 4 digits. Remote directory programming unfortunately cant be used but speedcalls can.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[modulistic]

God that sounds terrifying.

 

[MitelInMyBlood]

Terrifying is an understatement. This is a 1700 user system. Only one guy in the shop has ever been to any CM training and that was on CM Rls 2 many years ago. He has never had occasion to use any of his training and so has forgotten most of it.

4 techs to do 50 sets a day? Jesus, this will take forever. We have 2 techs, not 4. Cisco CM Administrator training has been offered so I think there's a starting point. Cisco's major VAR will be there to "assist" with initial system installation/commissioning but not the handsets. Compounding things, business must continue and that includes Mitel MACS to pull us off-task just long enough to lose our place.

For those who must know, this "fiasco" started when our CEO concidentally sat next to John Chambers at some executive soiree in New York a few months ago. Geeze, couldn't they have talked about the weather or their golf game?

Thanks to Opsmgr06 and actswitch for your input. You've given me some ideas. The feature gap (complete lack of dialpad feature access codes) will be most painful. Second-most will be trading out 14 button sets for 2 button sets and explaining why someone gets an 8 button set and the next guy doesn't and getting users accustomed to being forced to do things in a minute or two through a web GUI on the PC that they used to be able to do in a couple seconds with ease on the TT pad of their phone and explaining to them in ways they can understand, that this is progress. I especially can't wait for the first time a power blip resets the core routers in the computer room. (that happens about once every 12~15 months) Then suddenly phones that never ever went down before will be down and so too will their computers be down concurrently. But remain focused, this is progress.

Having Mitel sitting alongside Cisco on the desktop looks like it will probably will be necessary, tho it means visiting every desktop twice. PSTN Inbound trunks will indeed remain on the Mitel until we issue "VOL DISMOUNT SYSUSER" and throw the breakers.

Maybe in the middle of all this God will have mercy on me and send me home with a heart attack so I can go on Disability & take early retirement.

I feel most sorry for my end-users. I've known several of them for more than 20 years and I won't be able to look them in the face without them seeing it in my eyes and in the expression on my face. Their trusted phone guy is screwing them and giving them a piece of garbage.


Original MUG/NAMU Charter Member

 

[tlpeter]

My opinion!

If my boss desided to go for Cisco then i would be gone!


ACS IP Office or is it ACSS
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[SXWizard]

So sorry for your loss. Your last post is right on!.
I think you're right with the 2 phone approach unless you can get the entire company to shut down and take a 2 week vacation. (Might be easier to get a new CEO.)
Too bad you never had a chance to actually use the 3300. It would have been so easy to go to IP with the 3300 and the SX2000 together.

 

[sterling5005]

We used to carry both (Cisco no logner).

Best practice is to transition from Cisco to Mitel not the other way around.