Migrating directory numbers from one CUCM cluster to another

[Grayson Wells]

I have two clusters, one with CUCM v7.0 and one with CUCM v8.5. We have an inter-cluster trunk setup between the two and are migrating users from the old system to the new one. Calls can be made between clusters just fine. I need a way to seemlessly transition from one cluster to the other. Most of the directory numbers are created in the v7.0 cluster. If I create all the directory numbers for a building in the new cluster in preparation to migrate them over, then they won't be able make calls between clusters anymore. This is the case because if the DN's are created in the new cluster than calls to that DN will always be routed locally within the cluster. So the DN's can't exist in the cluster until the exact moment they are migrated or there will be a loss of service. For example, if phone number A in the old cluster makes a call to phone b in the new cluster, it works perfectly fine because all calls in the new cluster are routed back to the old cluster. However, if phone number A is created in the new cluster in preparation for a move calls can't be made between the two because when phone B tries to answer the call it won't be able to get back to the old cluster because the new cluster sees that directory number as existing locally. Does anyone know of a better way to migrate? Or a way to create all the DN's and device profiles in the new CUCM but disable them until I am ready to migrate them?

[Anthony Holloway · Accepted solution]

I'm not sure how automated you are looking to get.  There's always AXL: load up a file full of phones to migrate, and it connects to both clusters peforming the necessary tasks.  You sit back and drink your coffee.  But, if programming is not your strong suit...

Have you thought about creating a partition on the new cluster called something like "Staging_PT", and build your phones, with DN's in the Staging partition?  Then at the moment of migration use the Bulk > Update Lines to change the Route Partition for those DN's.  To clarify, the Staging partition would not be in any CSS.

Additionally, you could do the same on the old cluster, but move the DN's into a partition called "Moved_PT".  Again, Moved partition is not in any CSS.

During the small amount of downtime: Any line with CFUR to Voicemail will work out nice.  Lines without a CFUR destination will just ring busy.

So the process could look like this:

1. Build the phones in the new cluster, DN's in the Staging_PT
2. Bulk change the DN's on the old cluster to Moved_PT
3. Bulk change the DN's on the new cluster to Internal_PT (or whatever you use)
4. Point the phones to the new TFTP server

EDIT: I suppose the TFTP change will take the longest, so maybe start that at step 2.

[James Hawkins]

Hi,

I have used a similar approach to that suggested by Anthony to move phones beween a CCM 4.1 and CUCM 7.1(5) cluster and it works really well.

I was a bit worried that changing the DN partition would mess up the user primary line and IPCC line fields but they pick up the changes just fine.

You also need to remember to move any hunt pilots, UCCX triggers etc. between the partitions as well and to update your route patterns pointing between clusters.

I would also update the phone firmware on the old cluster to match that running on the new cluster before the change as this will reduce the outage time.

[Grayson Wells]

Thanks Anthony, that's probably the best suggestion I have heard.

[Gustavo Moreschi]

Hi Anthony,

I have a situation where we will migrate half of the sites from an old CM 7.1.5 to a new cluster 8.6. It is about 1000 ip phones (half of the sites we need to migrate to new cluster). What's the best way to do that route calls between clusters without changing the dial plan we have today? We need to route those calls not only for those sites we will migrate (for test purpose), but also those sites will stay on the old cluster 7.1.5. For instance: we have for each site about 9 RP, and about 20 TP.

Any help is much appreciate. Thanks!

[Grayson Wells]

Well... I'm not a voice expert, but if you migrate blocks of DN's at a time then you could configure a route that would send that specific block over your inter-cluster trunk. The call manager is going to choose the most specific route in the dial plan (assuming that user has access to the route, meaning it is in his/her calling search space).

For example, if you migrate 615-412-3300 through 615-412-3399, then you could write a route that sends 615-412-33XX over the ICT. That would take precedence over the other routes in your dial plan because it is more specific, just like configuring static routes on a router.

Also, why would you migrate to 8.6? Why not go to a version 9 call manager? I ask because I am at a new job now and I am probably going to be deploy voice this year and that will be version 9.