Trunks during Call Manager migration

[poidogpon]

We are going to be building a new UC 9.x cluster (3 Call Managers, 2 Unity connection, Presence.) for a customer that is already running  7.x. We would like ot build them side by side, and move users over ot the new cluster in an ordered fashion. Allowing communication between the 2 clusters as we migrate. I am looking for suggestions and tips on how to pull this off smoothly by anyone that has done this already. Thanks.

[Richard Simmons]

Hi,

I looked into this recently for a client, it can get quite messy!

You will need intercluster trunks between the two clusters, depending on how you are planning on migrating you will probably find you have overlapping dial plans i.e. the same extensions exist in both clusters.

You can approach this in a number of ways, you can have a cluster access code so you will need to prefix dialling numbers between clusters.

If you can migrate numbers in batches ie 1000-1999 then you can have specific route patterns for those ranges pointing to the ICT

You could also apply call fowards on the extensions that havent been migrated to the other cluster, this does take quite a lot of administration/BAT updates on both clusters.

There are no easy options and i'm sure there are at least another dozen ways of completing this.

Hope this helps in someway!

Regards,

Richard

[George Thomas]

+1 to Richard. I would try to avoid this if possible since there is a lot of work. Especially if you shared lines, hunt group, pickgroups etc. They need to be migrated at once. BLF SD etc will not work. Of course its possible with proper planning but its just a lot of work.

[Richard Simmons]

Also I should have mentioned Gateways, you'll need to consider how you route calls, do you send them to the old cluster and then route them from there or configure the gateway on both clusters (H.323 or SIP trunks), you would need to double up on dial-peers to have inbound calls routing to either cluster.

As George says, this is one to avoid, you would put more time and effort into planning this than you would doing a "big bang" migration.

[poidogpon]

Unfortunately the "big bang" option is not on the table for us. This is a medical center with about 8 remote locations all coming back to the cluster for their services. If we don't duplicate extensions, then just trunk between the 2 clusters, can  we avoid the issues you're talking about.

[Richard Simmons]

Would you be completely changing the extension or just increasing the number of digits? Would that have a knock-on effect on DDI's? and you would then need to implement translation patterns to retain the existing dial plan.

You may be best migrating one site at a time, i assume that each site has an extension range eg 1XXX to 8XXX. You would then have the ICT in place between the 2 clusters and once site one is migrated add a route pattern to the current cluster for 1XXX point to the ICT, on the new cluster you will need to a route patter [2-8]XXX and point that to the ICT.

This will retain the existing dial plan and users will not notice as they will dial the extension as they did before.

Depending on how your gateway is connected for PSTN connectivity you will need to make changes on there for calls to be routed to the new cluster and for transcoding and conferencing hardware to be available

[Ayodeji Okanlawon]

I have done this for a very larger customer (over 10,000 users) and the migration is still on going. We still have some users left on the old cluster and I do agree that it can be messy

You don't have to worry about over lapping dial plan since these are separate clusters..

The key thing to do in terms of migration users and call routing are these

1. When a site is migrated, you need to move all the phones for that site into a new partition eg (migrated_pt) ensure that this partition is not accessible from any of the devices left on the old cluster

If you dont do this, users on the old cluster wont be able to call the migrated sites..

2. You then need to create a route pattern for the migrated site and point that to the ICT for the new cluster

3. You should use BAT to do an export for any site you want to migrate, you can then use excel to filter data before re-importing them back to the new cluster.

4. You can keep your gateway on the old cluster and all your calls will be routed via the ICT to the new cluster, this shouldnt be a problem. This will keep the gateway centralized and I think its the easiest of the options.

5. You will need to create route patterns for sites that you have not migrated on the new cluster so that people on new can call user son old cluster.

6. Ensure you have PVDMs for media resources such as MTP as when calls start traversing ICT, you may need MTP for supplementary services.

[David Hailey]

In terms of call routing, this is definitely do-able.  In fact, I've been doing a similar migration for a customer with 4 disparate clusters (and a lot more sites) and consolidating down to a new centralized architecture for a few months. You will have logistics to deal with - such as shared lines, hunt groups, etc. That much is a given.  How much work it is for you depends a bit on the dial plan and how much planning you put into it.  I cutover single/entire sites at once from the legacy clusters to the new one including any PSTN gateways.  For the most part, that's not something you can get away from.  When I do that, I create what I call a Park partition on the legacy clusters.  Really this is just a partition where you can park the old numbers/patterns for a site but it's not in any of the CSS visible to other users/devices on the cluster. Then I add the appropriate pattern(s) necessary to route all calls from the remaining devices across an ICT to the new cluster.  On the new cluster, my dial plan then has default route patterns that route any calls that don't resolve locally to the appropriate legacy cluster via ICT.  Having a number of healthcare customers, I can see how a flash cut migration may be difficult for you to schedule.  Technically, it's not a problem but from a business perspective - it can be difficult to approve or work around logistically.  So, for what it's worth - yes, you can totally do what you need to do using the temporary ICT approach.

Hailey