I've posted previously around high-level thoughts about migrating from CCM 3.3(3) to CUCM 6.1 (new cluster)
I've been able to spend time with our chosen migration vendor, and things seem to be a lot clearer to me now :o) However, I am still unsure about some things, and was wondering if anyone can suggest any 'Best Practice' solutions?
1 - How do we successfully 'stage' the migration between clusters? I am looking to migrate users via subnets, so we can control the areas that are migrated to 6.1 simply by altering the "option 150" tftp pointer on our DHCP server. However, i'm not sure how best to route callers from the old system to the new. We will use an ICT between them, but how do i structure the ICT so that there is intelligence such that an internal/external call into the OLD cluster will route to a user who is now on the NEW cluster? (ie caller on 3.3 calls an extension that is now on 6.1. What sort of config is needed on the ICT or Route Patterns to point at the new cluster BUT avoid calls falling into a loop and trying to get back over the ICT)
2 - im concerned that we dont have signed XML downloads at present, so any migration (big bang or staged) would not be possible to roll-back from if we needed to. (CCM 3.3 doesnt support signed loads?, so the phones wont be able to talk back to 3.3 if we re-point them at 3.3 in the event of a roll-back)
3 - I will move one of our E1 lines (outbound) into the new cluster by registering the CMM with that CallManager. However, how can i get inbound calls working on the new cluster in a staged migration? I can move an inbound E1 too, but how will our carrier know which extensions have moved to send calls to that E1? Would Inbound have to stay on the old cluster until we fully migrate and move ALL the E1s to the new CUCM 6.1? (using some clever route pattern across the ICT???)
I might have some other migration-related Q's too - sorry! :) I've supported CCM for years but never worked on a migration before, so this is all new territory for me :o(
Thanks aokanlawon. It sounds like a staggered migration of users from 3.3 across to 6.1 might be awkward then, in terms of additional manual config per-user to route calls from one system to the other etc.
I suspect we will go with a 'Big Bang' approach to the migration once we have done some testing with maybe 30 users to ensure 6.1 is setup as we want it.
Trouble is, we have 2000+ users and phones, so introducing Extension Mobility AND 'logged off' phone extensions (used with basic functionality until a user with Extension Mobility logs in) is going to prove challenging i suspect :o)
(1) I'd suggest putting the 6.1 cluster "in front of" the CCM3.3 cluster. Migrate your gateways FIRST. That way, anything not found in the 6.1 system can be automatically translated to forward into the CCM3.3 cluster. Otherwise, expect endless issues with ICT, external/internal calls and such.
(2) As for phone migration, in the 6.1 system I made use of the "Forward Unregistered" to translate/forward over the ICT. Likewise, when moving phones out of the CCM3.3, I created a dummy phone (no DLUs in 3.3) and simply hijacked the DN by putting it into a special partition created for the occassion, concatenated in front of the regular partititions. Make sure you capture all the primary DNs.
(3)...moving the PSTN...see note (1). I strongly recommend migrating the gateways first and routing through 6.1 to get to the CCM3.3 cluster. Anything else and you are bound to have ICT issues.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.