Reviewing migration results and resolving issues

To successfully complete the data migration, you must resolve any issues that are generated after each DDM run. Your data migration is not complete until you rerun DDM until no errors are generated for that date range. Do not proceed with the migration for the next date range until the previous date range data is successfully migrated without any errors. This page lists the activities that you must perform after you migrate the delta data:

Mismatch entry ID errors

The DDM tool uses a combination of the unique index value defined for that form and the field ID 1 to migrate delta data. The combination of these keys must always point to the same record on the source and the destination servers. If either the index value or the field ID points to a different record on the destination server, an mismatch ID error is generated.

The following code block illustrates an example of the mismatch ID error:

An error occurred with Data 'SLM:Association'
10/21/2016 14:23:12    4476    ERROR    Migrations    14:23:12 : [4]-[9736]-[Merge Entry ID mismatch. Merge option was to return error on ID mismatch. Form : SLM:Association, Existing Id : 000000000013072, New Id : 000000000013870]
10/21/2016 14:23:12    4476    ERROR    Migrations    14:23:12 : [6]-[4111]-[ Migration failed for schema SLM:Association for entry id :000000000013870]

To mismatch entry ID issues, see resolving unique index or mismatch ID errors.

Unique index violations

A unique index violation can happen in the following scenarios:

• The request ID coming from the source server is already being used by another record in the destination server. This can happen if the same record is already on the destination server, but is using a different ID.
• The request ID is not being used, but the GUID (the value for Field ID 179) or the unique indexed field of that form is used by another record in the destination server. This can be caused by test data being created on the destination server that has the same ID as an item being imported.

These situations can occur in the following circumstances:

• Test data is created on the destination server but is not reverted to a clean state.
• An escalation or a process (such as from BMC Atrium Integration Engine, BMC Remedy Distributed Server Option, or the Reconciliation Engine) has not been disabled and the process created these records on the destination server.

The following code block illustrates an example of the error:

ERROR Migrations 07:01:32 : [4][The value(s) for this entry violate a unique index that has been defined for this form schema: CTM:Support Group Alias, entry: SGS000000006670, 2 unique index(es), field(s): 1000000079 1000000293 179]

To resolve the unique index violation issues, see resolving unique index or mismatch ID errors.

To resolve unique index or mismatch ID errors

1. Delete records with duplicate indexes from the destination server:
   
   1. Find the entry ID (Field ID 1) in the error message.
   2. Search the source server for a record with that field ID.
   3. Find the fields and the values of the unique index fields from that form.
   4. On the destination server, run a search with those values (not with Field ID 1).
   5. Review the data and see if the values for Field ID 1 and Field ID 179 are different.
   6. Look for the Last Modified By and Date to see who created or updated the record.
   7. After you confirm that a record is duplicate, delete the duplicate record from the destination server.
2. Run the Delta Data Migration Tool again with the same product selections and date used, so that tool can look into the working folder instruction .xml files and processes only records in forms that had errors.
   Ensure that you choose all the products or applications you selected during the previous run (even if some of them did not contain errors) for the rerun. Otherwise, the working folder is replaced and the Delta Data Migration Tool is not able to process only the records with errors.

Resolving threshold errors

If a form encounters more than a 1000 errors during the delta data migration (DDM) run, then DDM skips migrating data from that form and continues with the next one.

To resolve threshold errors

1. If the error generated is for the missing entry ID, perform the following steps:

   2:15:43 : [6]-[4111]-[ Migration failed for schema BMC.CORE:BMC_BaseElement. Entry missing for entry id :000000000376605]

   1. From your <BMC Remedy Migrator installation directory>, navigate to the DeltaDataMigration folder and open the Configuration.xml file.
   2. Search for the Delta tag and add the following entry:
      

      "threshold = 2000"

      Example
      <delta threshold="2000" work-dir=".\Working" migrator-dir="E:\Program Files\BMC Software\Migrator\migrator">
      

      By default, the threshold value is set to 1000. As a best practice, set the value to greater than 1000 in case of missing entry errors.

2. If other data errors are generated, fix the cause as appropriate.
3. Rerun DDM with the same product selections and date.
   DDM reruns for any failed forms and failed records.

Log files generated by the Delta Data Migration tool

After you run the Delta Data Migration Tool, you will see a Working folder under <MigratorInstallDirectory>\DeltaDataMigration. This folder contains the package and instruction XML files for all your products. Under the Working folder, a Logs folder holds the .html, Compare.xml, and .mgrresult files. These files are discussed below.

The DDM tool creates HTML-based log files, with the following format, by using the package names that have the .html suffix:

<component_name>_compare|migrate_yyyymmdd_hhmmss.html

• Migrate.html
• Compare.html

Search the HTML log files for the following keywords:

• ERROR — Lists the form information and data for a server, API, or SQL error.
• WARNING or WARN — Describes warnings from BMC Remedy AR System that do not stop the package migration.

The DDM tool also creates .mgrresult files and comparison output XML files:

• Migrate script details — The migrate script creates a .mgrresult file for each instruction with the instruction name and suffix _Migrate that includes the results of migrating all the form data (entries). The file lists the number of entries that were migrated for each form and includes the same error information (if any) that the HTML log file contains. Open this file with BMC Remedy Migrator. Examples of BMC Remedy Migrator output file names are:
  • ITSM_Package_Migrate.html — The migrator log file (you will have one of these for each package).
  • Remedy_Service_Request_Management_Migrate.mgrresult — The migrator result file (you will have one of these for each instruction file).
• Compare script details — Apart from the HTML log file, the comparison script also creates an .xml result file for each instruction with the instruction name and suffix _Compare. These files include all data entries that are either different or missing in the destination server. (A comparison that is run after a successful migration should not report any differences in form data, but the report will show differences if a field's data type was changed even if the data is the same.)
  Examples of compare output file names are:
  • ITSM_Package_Compare.html — The compare log file (you will have one of these for each package).
  • Remedy_Service_Request_Management_Compare.xml — The compare .xml result file (you will have one of these for each instruction file).

Known errors and warnings in log files

This section lists the known errors and warnings that might occur in your log files. Check the log files for errors and contact Customer Support as needed for assistance.

You can ignore the following warning in the SRM_Package_Migrate and SRM_Package_Compare HTML files:

You can ignore the following error in the SLM_Package_Migrate, SRM_Package_Migrate, SLM_Package_Compare andSRM_Package_Compare HTML files:

If BMC Atrium Integration Engine or Enterprise Integration Engine is not installed in your servers, you can ignore the following error in the Atriumpackage_Migrate and Atriumpackage_Compare HTML files:

You can ignore the following errors in the BMC Remedy Foundation Elements_Migrate and BMC Remedy Foundation Elements_Compare HTML files:

In versions prior to BMC Remedy ITSM Suite 7.0.3 Patch 010, the form names for these forms and the CFG:Pred-Succ Associations form had a slash (/ ) in their names. This slash (/ ) was changed to a hyphen (-) in BMC Remedy ITSM Suite 7.0.3 Patch 010 and later. Depending on your version, you might see an error for the form name that contains either character. You can ignore this error; the data will be migrated with the form name that matches your server.

If the forms are not on your source server, you can ignore the following errors in the ITSM_Foundation_Migrate and ITSM_Foundation_Compare HTML files:

If the forms are not on your source server, you can ignore the following errors in the BMC Remedy Task_Management_Migrate and BMC Remedy Task_Management _Compare HTML files:

If the forms are not on your source server, you can ignore the following errors in the BMC Remedy Foundation Elements_Migrate and BMC Remedy Foundation Element_Compare HTML files:

If you run a compare report after a successful migration, no data with "state=different" or missing data is expected. The compare report should not report any differences.
The Remedy_Contract_Management_<datetime>_compare.xml output file might report the following differences, which you can ignore, because the source server does not have default value data for the fields listed. However, the destination server does have this data.

<data destination-form="CTR:ContractBase" source-form="CTR:ContractBase" unique-field-id="179"> {{<entry entry-id="000000000000001" id="CO0050560C63F20vnfQwlG06AALAMA" state="different">
<field id="260600003" name="Purchase Cost" state="different" />
<field id="260600004" name="Renewal Cost" state="different" />
<field id="270002042" name="Cost per Asset" state="different" />
<field id="270002043" name="Cost per Component" state="different" />

If you are migrating data from BMC Remedy ITSM version 7.0.02 or 7.0.03 with or without patches, you will see the following errors in the ITSM_Foundation_migrate_<datetime>.html file. This is a known issue that occurs because data migration in the APR:Approver Lookup and APR:SYS-Approval Definition forms is not supported.

The following errors might appear for the APR:Approver Lookup form:

The following errors might appear for the APR:SYS-Approval Definition form:

If you are migrating data from BMC Remedy ITSM version 7.0.02 or 7.0.03 with or without patches, you will see the following errors in the ITSM_Change_Management_migrate_<datetime>.html,ITSM_Change_Management_compare_<datetime>.html, andRemedy_Change_Worklog_DetailDesc_Null_<datetime>_migrate.mgrresult files. You can ignore these errors, because the form does not exist on your source server.

If your source BMC Service Request Management version is 2.2 or 2.2 patch 1, you might see the following errors in the .html log file. You can ignore these errors, because they are benign.

Because the SRD:AuditDisplay form is not to be updated during the delta data period, you can ignore the following errors:

Resolving index issues

You might possibly encounter a mismatch index ID or unique index violation during your DDM. The following section describes how to resolve these index issues:

Benign migration errors

In any form, you might see the following errors, all of which are benign. You can safely ignore them.

The Delta Data Migration Tool is run with a live source server, and you have not yet committed the record ID that the utility is trying to migrate. Therefore, the record ID is not in the source server's database yet.

Troubleshooting BMC Service Level Management issues

If you have stand-alone BMC Service Level Management (no ITSM), you must enable the CTR:ContractBase form in the Remedy_Service_Level_Management.xml file. The CTR:ContractBase form is required for the BMC Service Level Management delta data migration.

Perform the following steps to enable the CTR:ContractBase form:

1. In the C:\Program Files\BMC Software\Migrator\migrator\DeltaDataMigration\Packages\SLM\8.1.02\Remedy_Service_Level_Management.xml file, search for CTR:ContractBase.
2. Update data enabled = true.

Where to go from here