Wrangler OPA Deep Dive - CUCDM to Kurmi

Using Wrangler OPA to migrate from CUCDM to Kurmi

Migrating between UC systems manually is difficult and time consuming. One of our first products that we built was Wrangler to make on-premise migration to HCS easier have a look here for more details.

We worked closely with Kurmi to extend Wrangler to support migrations from CUCDM to Kurmi and this blog post is a deep dive of the process

“With Yarnlab’s Wrangler, migration is fully automated, using data extracted from both CUCDM and CUCM, flexible hierarchy mapping to Kurmi, and test automation with Testmate,”

“Migrating existing customers is key for service providers and is especially fluid since Kurmi has developed APIs and specific workflows to facilitate it. This combination makes it easier to decommission the former domain manager.”

 

To do this we spent a lot of time looking at what data we needed to extract and how! As well as solve many of the anticipated challenges

  • Extracting data from both CUCDM and CUCM

  • Comparing the deployed dial plan to the CUCDM model  to find any manual dial plan changes

  • Develop a method for dial plan co-existence between CUCDM and Kurmi so that the migration can be staggered and have safe roll back

  • Migration of CUCDM8 ENT dial plan customizations 

  • Manipulate the current hierarchy as it is now flexible in Kurmi such as flattening to just be two level - Customer | Location (department) or to add greater depth if necessary

  • Support changes in dial plan types i.e. G1 to Type 4 (with linked locations

  • Automatic migration of UC systems info - cluster/IP address(NAT and Real)/Credentials/etc

  • Detailed pre-migration validation reports and checks

  • Migration of CUCDM administrators (customer/location)  and RBAC mapping

  • Customer deployment timeline that shows the CUCDM8 model used when the location was added and other changes to the model

  • Dialing forest comparison to ensure that all prefixes are dialable before migrating

  • Flexible schema mapping to suit customized Kurmi scenarios

  • Usage analysis via CDR to find what services are used and which ones should be tested

  • Renaming of CUCM configuration item such as SIP trunks and media services

  • Integrated UC health check including DB replication and CUCM group resiliency - UC Status Page

  • Moving users, devices and features to new dial plan (hierarchy)

  • Maintaining and mapping the billing meta data as well as customer and site information (addresses etc)

  • Clean-up of redundant CUCDM8 configuration data in CUCM

  • Automated dial plan testing for co-existence and post migration testing - Testmate Migration bundle

 

To do the migration we use the Kurmi APIs to build a whole new dial plan and then link the dial plans so that extension/FNN and e164 dialing on net works with full interop between the dial plans

This allows for migration of individual sites and the end result is a new dial plan that is fully managed by Kurmi

 

 

...and finally a migration that is product based

Now the details

Migration Process - High Level

  1. Operator using the Wrangler interface select the required inputs

  2. Wrangler extracts CUCDM8 Metadata

  3. Wrangler extracts CUCM configuration

  4. Build migration model

  5. Site creation - Wrangler creates new site in Kurmi

  6. Migration

    1. Wrangler triggers the migration between old and new sites

    2. Wrangler cleans up old CUCDM data

  7. Testmate powered Test Automation

 

Legacy Data Reporting - CUCDM8

We started with looking at the history for this customer and to check if there will be any problems with the migration

as you need to know what you don't know - i.e. what has been done through the lifetime of this customer 

To do this we want to find all the objects pushed by CUCDM and why!

Doing a clean up at this point also helps remove the configuration clutter before starting a migration, what this means is to clear out the old configuration (or what was left behind when a location failed during deployment).

This also provides a way to track all the objects in CUCM so that once the migration is complete all the CUCDM config can be removed.

Customer History

Find when sites were added and removed

 

Now for the testing and validation

Previous
Previous

Analyze with pre_yarn

Next
Next

UC Migration Automation and Standardization