"Best Practice" migration to CUCM 6.1

andy_vvc2 · ‎08-01-2008

Hi all,

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 muchly

Ayodeji Okanlawon · ‎08-01-2008

Hi,

To accurately help answer some of yoru questions...I need to know if after migrating users to the new system, You have deleted their extensions and moved them over to the new system..

If this is the case here is what you can do...

Use a gatekeeper ( a cisco IOS feature) To centralize and route calls between the old cluster and the new one...

So for internal calls to users in the new system from the old system...

do the following:

1. Create a RP for their extensions..

2. Assign the RP to the gatekeeper.

For external calls...

Create your dial-peers for the new users/old users extension...on your voice gateway..and send it to the gatekeeper. The gatekeepr will then route it to the appriopriate callmanager.

You can use your existing Voice gateway as a gatekeeper, so you dont need to but any additional piece of hardware. You will just make sure your ios can give you this functionality.

You will also create RP on the new system for extensions of the old system and send it to the gatekeeper. The gatekeepr will then route it to Callmanager 3.3.

ICT has no intelligence to do such things.

HTH, pls rate useful posts

Please rate all useful posts

andy_vvc2 · ‎08-06-2008

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)

db5767 · ‎08-06-2008

I've recently completed a similar migration.

(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.