We upgraded from 4.3 to 9.1 recently 22 sites across Europe which contained a mixture of CME and CUCM standalone clusters. The best way to do this would be install a brand new CUCM 10.5 cluster alongside your existing 4.3 cluster. Create an ICT between the two clusters and think about the dial plan calling between the two clusters. If you are making changes to the new dial plan (I suggest moving to an e.164 numbering plan if you are not already using it) then plan out new shortdials between clusters. Use Extension Mobility wherever possible as it makes the whole migration a lot easier. To move each site, generate an Excel Spreadsheet using the BAT.xlt template to capture all of the required information for a BAT Import of Device Profiles and Users. Populate each sheet as you go and import them through BAT. It is a bit more work, but old clusters are not always pretty, they have lots of dead config which you don't know about. This way the end result means that you have a perfectly clean 10.5 cluster. Feel free to bounce ideas off me, I've still got a lot of the BAT Sheets I used and can answer your questions on the Dial Plan. You need to spend some time working on the Dial Plan beforehand else it will start going wrong from Day One.
I have similar situation :we are not able to change the dial plans because of out PSTN trunks are not in organised way its supposed to be ;
CUCM 7.1 is end of sale and end of support migrating to CUCM10.5 and UCCE 10.5
I have scenario where this client has 4 digit dial plans (4 digit EM users) and PSTN E1 trunks calls for back office DDI range and call center Toll free number are scatterd and shared with E1 traunks it very difficult to segregate the back office ddi range trunks and toll free call center trunks ,becasue of this we left all E1 trunks on the old gateways and move first back office less mission critical and then to call center with new gateways at the end,for back office they still use ICT trunk between old cucm 7.1 to new cucm 10.5
we have 7 buildings and around 10k users among them are 500 agents and these agents wants extention mobility and agents move around the building
all the 7940/7960 device firmware upgrade is done;by pointing to new TFTP server on 10.5 cluster and its done now
now what i am facing the difficulties is how to find the how many users are there in each building and migrate building by building,only things i facing issue how to find the users or perhaps mac address of one building ,registered ip by dhcp scope...!!!
i have done full export import now ,created ICT trunk and now i can call from new cluster 10.5 to old cluster 7.1 but other way round is actuall migration user
1.what you suggest on this do we need to adapt building by building or full back office users migration ?
2.building by building how to find users and mac address ? specifially UCCE users and UC Users in same building
3.if you suggest full back office one week end then how much time it consumes what options we have is it can i change new dhcp scop 150 and all back office users to point to new TFTP server ?
4.my only worry if i find UC users and UCCE users building wise then i can move building by building
5.if i know building A moved then i will apply call farword unregisterd users for that specific building via ICT #xxxx ,once all the buildings are done then finally move all the agents parallelly all E1 trunks to new gateways and switch of the old cluster ....
waiting for your early reaply ,please copy email@example.com
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...