Cluster Consolidation Considerations

This page provides some additional information to the wrangler_ WxC-DI Migration User Guide for Cluster Consolidation migrations specifics only.

Single Consolidated Migration (recommended option)

In a single consolidated migration of two or more source CUCM clusters, all source clusters together with the target cluster are defined in a single Wrangler UCMC migration. The migration can occur in stages as required per site, but all the planned source clusters to be consolidated will need to be discovered in the same session, noting that a rediscovery can take place anytime to cover any changes in source or target over time.

The Single Consolidated migration option can be performed using Map or Template migration but not Clone migration. Sample below shows a Map migration, but the same process would be used for Template/ Simplified Dial Plan migration option.

The only difference being that a Template or Simplified Dialplan migration will push a standardized dial plan to target rather than a dial plan required to be preconfigured in target as per the Map option.

Prerequisites for Map migration

For Map migrations (selected by Map - Map Source Dialplan to Existing Target Dialplan option from Dialplan Configuration field), it is a requirement that a Dialplan has already been configured in the target UCMC cluster to allow for mapping of source clusters Dialplan objects to the target Dialplan.

To start a Map migration

1. Select the CUCM source interfaces of CUCM’s to be consolidated in the Source Clusters CUCM Cluster Publishers fields

2. Select CUCM target interface target in the Target Clusters CUCM Cluster Publishers field as per single migration.

3. Name the migration in Target Customer Name field.

4. Enter Countries in Initial Countries field.

5. Select required Dialplan migration option from Dialplan Configuration drop down, noting that Clone - Clone Source Dialplan migration option, whilst can be selected is not supported for Consolidated cluster migrations.

Open

On Completion of Initial Discovery/ Allocation/ Validation, in addition to any issues experienced with a single cluster migration, any duplicates between the source clusters will be displayed

Open

Review the duplicates against the CUCM clusters. Many of the duplicates will be default items in CUCM, such as most of the Phone security Profiles, Phone Button Templates etc. and if it states that configuration is identical, any cluster can be selected to be used by clicking on the Select Cluster blue button, and selecting from the drop down which source cluster to be used for the migration.

Once the cluster has been selected, the Select Cluster button will change to View Bulk Change, this button can be selected to , if required, view the bulk change that was performed when selecting the cluster.

If a duplicate object needs to be investigated before selecting the cluster to use, this would be relevant if unique configuration between the duplicates, then the individual objects may be investigated by selecting the Review Duplicates button, which will bring up a new view listing the individual duplicate objects.

from here select the duplicates individually by clicking on Edit link which will bring up the detailed view of the object in Object Browser.

In the object browser, investigate the configuration differences between the individual duplicate objects. Decision needs to be made how to deal with the duplicates. If a particular version of the individual object is not to be used, then from the object page of the duplicates set the Ignore as source toggle to Yes, this duplicate will then not be used for the migration.

If the duplicate needs to be migrated, best course of action is to corrected in the source cluster, then perform a new discovery.

When all the duplicates and all other issues* have been have been rectified as required, select Re-Validate Migration

Once all issues have been rectified, the Prepare Sites header will display all sites. select Sites to be migrated from the Sites menu

When sites have been selected go back to Issues from main menu and select Re-Validate Migration

Attend to any issues flagged after the revalidation, then Re-Validate Migration again.

Select Preview Prepare, followed by Start Migration, this will start the preparation of all objects ready for loading

When this is completed, select the Continue Migration button

The migration has now progressed to pre load stage, select the Re-Validate Migration button

The migration will now progress to validate sequencing of objects for loading and also flag any duplicates between the selected source cluster/objects and the target cluster.

On completion of validation any sequencing issues are displayed and dealt with by selecting the Move Obj To “Before Any Sites Loaded” or View X Dependant Object button. This is described further in the Migration User Guide wrangler_ WxC-DI Migration User Guide

Any duplicates here may be reviewed by selecting the Review Duplicates button to investigate further before selecting appropriate copy; or

Selecting the Ignore Source button to ignore the source object and leave target as is, or the Update Target button to update the target duplicate with configuration from the source duplicate object.

When complete, select the Re-Validate Migration button

Now ready to load target, select Preview Load button, followed by Start Migration button

Staged Migration

If for some reason, a single consolidated migration as per above can not be performed, it could be that not all source clusters that are to be consolidated can be accessed at the time of the first discovery or such, a possible approach is to perform a single migration first. Then using this migration as the consolidated dialplan for further migrations.

There are a number of variations to this option.

1. The Initial migration as Clone Migration or Template/ Simplified Dial Plan migration with this used as master dialplan for consecutive (mapped) migrations

2. A new dialplan could be deployed manually (or by engineer developed tools). The initial and consecutive migrations could then be performed as separate Mapped migrations.

3. Separate Clone Migrations but to the same target. This would not be a recommended option as the target cluster would end up with a separate dialplan for each source cluster migrated.