Manage Migration Mapping Conflicts
This topic describes how to resolve conflicts that can arise when migrating the gateway using the Gateway Migration Utility (GMU).
gateway83
This topic describes how to resolve conflicts that can arise when migrating the
CA API Gateway
using the Gateway Migration Utility (GMU).Migration: Success or Failure?
What Happens
: The mapping actions that you specify with migrateOut
or manageMappings
commands determine how entities are mapped from source to target.Where
: Migration results (success or failure) are saved in an XML file. Results | Next Steps... |
| You can confidently commit your migration. Review < to verify how entities were mapped.results >.xml |
|
|
Example: results.xml
results_xml2

Types of Conflicts
If the migration fails, the
<
can contain these common mapping failures:results
>.xml- Target entity already exists
- Target entity not found
- Unique key conflict (usually name)
- Cannot replace dependency
- Invalid resource when updating an entity
Understanding the results.xml File
The
<
file tells you the mappings actions that were taken, based on the arguments that you have passed during results
>.xmlmigrateOut
or with a mapping.xml
file.Action | Meaning |
UsedExisting | Entity mapped to an existing entity on the target Gateway. Target entity was not updated. |
UpdatedExisting | Entity mapped to an existing entity on the target Gateway. Target entity was updated. |
CreatedNew | New entity was created on the target Gateway. |
Deleted | Entity was deleted on the target Gateway. |
Ignored | Entity was ignored and not imported. |
Fix Errors
If migration fails, follow these steps:
- Open<and search for the string, "errorMessage". For example:results>.xmlerror_message2
- Fix errors or change the mappings using themanageMappingcommand.Always fix thefirsterror in the <results>.xml file (rather than fixing errors from the bottom up). Entities are processed from top to bottom so this method is the most effective way to find the root cause.
- Retest the migration.