Wrangler OPA Deep Dive - CUCDM to Kurmi

wrangler-03 - Copy.png

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

 

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
“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.”
 
 
2e99782e-d2a8-4163-99d5-5b0fa9b51675.png

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 and does not require services!

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
9f11db96-8f76-4047-922b-e8249aed0c41.png

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

Find orphaned objects and any dependencies to allow for easy cleanup of redundant config once the migration is complete

Find manual dial plan changes easily so that the work arounds are identified and migrated appropriately 

Track model changes

  • what dial plan objects were pushed for which site
  • if the model was updated multiple times
  • when the system was initialized 

Object Browser 

Export any data you need from CUCDM in easy to use web based excel reports

Data Extraction

Easily extract any info from the CUCDM API such as

  • ENT (dial plan customization)
  • Trunks - aggregation and 3rd party
  • Users
  • Devices
  • Number ranges
  • Location configuration
20d0ca7d-0772-4775-9444-4db1462cc68c.png

Rollback

All changes made by Wrangler can be rolled back - at a customer, location or object level

Wrangler OPA - Migration Process

 

1. Select Customer and name the migration

 

 

 

2. Wrangler then scrapes all data from CUCDM and compares with CUCM

3. Mapping and Rename of objects 

  • Line CSS

  • Device CSS

  • Partitions

  • Dial Plan

  • ENT

  • CUCM

  • Trunks

  • Media Services

4. Preview the Migration 

Wrangler checks all the mappings are completed and there are no namespace conflicts

5. Site Checks

  • Users
  • Devices
  • Lines
  • Number ranges
  • DIDs
  • ENT

6. Customer checks

  • Admins
  • Trunks
  • Route Patterns 
  • Customer ENT

7. Migration Log

8. Migration Report

9. Migrate Remaning Site(s)

 

....and the migration is complete!

Now for the testing and validation

Zane EnglandComment