9 Migrating Legacy Data to BRM Cloud Native

Learn how to migrate data from your legacy database to the Oracle Communications Billing and Revenue Management (BRM) cloud native database.

Topics in this document:

About Migrating Legacy Data

You migrate legacy data to the BRM cloud native database using Conversion Manager. Conversion Manager can migrate the following types of data: account data, service data, product offering data, billing data, account hierarchy data, and balance data. See "Understanding Conversion Manager" in BRM Migrating Accounts to the BRM Database for more information.

The high-level steps for migrating legacy data to the BRM cloud native database include the following:

  1. Understanding the data in your legacy system and deciding how to convert it to the database.

  2. Mapping the data in your legacy database to the BRM database. To do so, you create XML files that are validated by the Conversion Manager XSD schema files.

    See "Mapping Legacy Data to the BRM Data Schema" in BRM Migrating Accounts to the BRM Database.

  3. Migrating the data to the BRM database by running the pin_cmt utility through a brm-apps job.

    See "Loading Legacy Data into the BRM Database".

Loading Legacy Data into the BRM Database

You load legacy data into the BRM cloud native database in a multistep process:

  • Import your legacy data into a staged area of the BRM database

  • If necessary, recover and reload any failed load processes

  • Deploy the data from the staged area to the production area of the BRM database

You load legacy data by running the pin_cmt utility through the brm-apps job. For more information about the utility's parameters and syntax, see "pin_cmt" in BRM Migrating Accounts to the BRM Database.

To load legacy data into the BRM database, do the following:

  1. Ensure that BRM cloud native is running.

  2. (Optional) Modify the pin_cmt utility's connection and performance parameters. To do so, edit the infranet-properties-brm-apps ConfigMap (configmap_infranet_properties_brm_apps.yaml):

    1. Under the file's cmt_Infranet.properties section, edit the pin_cmt parameters.

    2. Run the helm upgrade command to update the BRM Helm release:

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

      where:

      • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

      • OverrideValuesFile is the file name and path to your override-values.yaml file.

      • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

  3. Import your legacy data into a staged area of the BRM database:

    1. Add the following lines to the oc-cn-helm-chart/brmapps_scripts/loadme.sh script:

      #!/bin/sh
      
      cd /oms/apps/pin_cmt; pin_cmt -import -file XML_input_data_file  stage_ID
      cd /oms/apps/pin_cmt; pin_cmt -import_custom -file XML_custom_data_file  stage_ID        
      exit 0;

      where:

      • XML_input_data_file is the file name and path to the XML file containing the mapping between the legacy and BRM databases.

      • stage_ID is the identity of the staging area.

      • XML_custom_data_file is the file name and path to the XML file containing the mapping between your legacy database and new storable classes in the BRM database.

    2. Move the XML_input_data_file and XML_custom_data_file files to the oc-cn-helm-chart/brmapps_scripts directory.

    3. Enable the pin_cmt utility and brm-apps job. In your override-values.yaml file for oc-cn-helm-chart, set the following keys:

      • ocbrm.cmt.enabled: Set this to true.

      • ocbrm.brm_apps.job.isEnabled: Set this to true.

    4. Run the helm upgrade command to update the BRM Helm release:

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace
  4. Check for load processes that failed and, if any did, recover and reload the processes:

    1. Check the cmt.pinlog file for load failures.

    2. In the cmt.pinlog file, retrieve the batch ID for each failed load process.

    3. Add the following lines to the oc-cn-helm-chart/brmapps_scripts/loadme.sh script:

      #!/bin/sh
              
      cd /oms/apps/pin_cmt; pin_cmt -recovery load batch_ID
      exit 0;

      where batch_ID is the batch ID you retrieved from cmt.pinlog.

    4. Run the helm upgrade command to update the BRM Helm release:

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace
  5. Deploy your data from the staged area to the production area of the BRM database:

    1. Add the following lines to the oc-cn-helm-chart/brmapps_scripts/loadme.sh script:

      #!/bin/sh
                
      cd /oms/apps/pin_cmt; pin_cmt -deploy DOM stage_ID
      exit 0;

      where DOM is the billing cycle's day of the month. Only those accounts with the specified stage ID and DOM are deployed.

    2. Run the helm upgrade command to update the BRM Helm release:

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

After accounts are deployed, BRM cloud native starts their billing cycles, applies any cycle fees, and, in multischema systems, updates the uniqueness table in the primary database schema.