Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mass Phone Upgrade (Digital to IP)

Status
Not open for further replies.

IntermixMatt

Vendor
May 16, 2013
9
US
I'm prepping to perform a partial phone upgrade for my largest customer. We'll be upgrading 400 Superset 4025 digital phones to 5330e IP phones. The system is currently on MCD5.0 SP2 and we have the option to upgrade to MCD6.0 before we start pushing out phones.

I've attempted to change the device type in User and Device Config: not allowed. I've also attempted to export a set, change the device type, remove the PLID, and import it back: device type error.

I'm a bit worried that I'll have to delete and reprogram 400 sets (keys, groups, etc) manually. Are there any other options available to me to cut down man-hours?

Any advice is much appreciated.
 
Just went through a similar project. There is no way to turn a 4025 to a 5330e. The best you could hope for is export, then copy and paste the data to a spread sheet for an import.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
 
Renumber the existing DNIC set to something like 2*XXXX (use the Multiline DNIC set form so that VM is not changed). This can be done with an export and import

Create new 5330 with the old number
Create 1 and use as template to create import for all 5330's

Copy Keys (again, export, import)

Set Call rerouting on 5330 (yup you guessed it, export, import)

I just went thru this exercise for 100 stations and it works well.

**********************************************
What's most important is that you realise ... There is no spoon.
 
kwbMitel this is interesting can you give a bit more detail about copying the keys? Not sure what you mean there.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
 
Thanks for the advice guys. I'll run some tests with your process today on a small number of sets. When you did the 100 phones, did you have to deal with any group programming? If so, what was your approach?
 
@LoopyLou:
quite often you find that there are keys on the phones, that if removed and reprogrammed, will change programming that you were unaware of. (Hunt Group Membership, Call Routing, Forwarding, etc.)

A 4025 has less keys than a 5330 so all of the keys can be directly copied via the Multiline Set Key assignment form from 1 phone to the other. Once copied, they can be deleted off of the original set without impacting any special settings.

Typically, I would use an Export and then Import if I'm working with more than 1 set.

@ IntermixMatt re:groups
I left all of the DNIC sets in service until everything shook out. The numbering change made things quite obvious in the group membership forms as the new number stood out clearly and because the original number was part of the new number there was no need to cross reference before adding the new one.


**********************************************
What's most important is that you realise ... There is no spoon.
 
kwbMitel, I appreciate the tips. Preliminary tests are looking good. I'll update this with notes after the installation.
 
Excel is your friend :)

We actually did something similar to kwbMitel's plan, migrating from a 1700-station SX2K to a Cisco Call Manager. Aside from major platform differences, the default Cisco phones that most users received were only 2-line instruments, so we had some rather long faces when users learned they were losing all of their personal speed call buttons. (Cisco's largest instrument is only 8 lines and comparatively expensive).

Still by exporting to spreadsheets we were able to capture all the personal speed calls & provide printouts to users, which was appreciated. The Cisco also accepts batch input from Excel, so as bad as it was, it could have been a lot worse. With some quality time spent with cut-n-paste we were able to put together some batch scripts for input that worked well.

TIP: limit your imports to 100 phones at a time else you'll have a lot of potential rework if you have something wrong someplace.

Fork-lifting the Octel Overture-250 and replacing with Cisco Unity Connection was even easier, as the new system was all LDAP-integrated. Once the phones were built & sync'd with LDAP, UUCXN was able to import them directly via the gui interface, though once more I recommend resisting temptation and only doing 50~100 at a time. Due to the platform differences our prep time for each batch of 100 averaged 3 days, so it was very important to keep departments together while making sure to have routes in both boxes to allow cross-platform calls (and prevent routes from looping).

Lessons learned, if we had it to do over, we should have moved the DID/DDI trunks first, because through platform idiosyncracies we lost inbound caller-ID when users moved to the Cisco and they didn't get it back until everyone was moved over (a 4 month project). Had we moved the trunks first, Mitel users would have lost CallerID but then regained it as soon as each was migrated. By moving the trunks last it initially gave the new system a black eye and we spent several hours explaining and then re-explaining to higher-ups what the issue was and why and when they could expect relief. They weren't very happy, but it was what it was.




Original MUG/NAMU Charter Member
 
Do you get any issues with remumbers to 2*XXXX if its picked up on other phones?

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top