This assumes you are familiar with the basic usage of the Gateway Migration Utility and that you are using an arguments file with an encoded password to connect to your API Gateway. This also assumes you have migrated out a service into an XML file named example.xml.
The migrateIn command is used to import the service, policy, or folder into an API Gateway. In this example, the service in example.xml is imported into the API Gateway.
GatewayMigrationUtility.sh migrateIn -argFile example.properties –bundle example.xml -results result.xml
After running the migrate in command, if the Gateway Migration Utility believes that the migrate in was successful, the following will be displayed.
Migrate in successful
One of the most common issues that is not always obvious is that NewOrExisting was used in the migrate out action, and the service or policy or folder exists in the target API Gateway, and thus, the service or policy or folder will not be updated. This can be seen in the results file.
The solution is actually quite simple. Instead of using NewOrExisting, use NewOrUpdate. When NewOrUpdate is used, you should see a different action taken in the results file.
If you used the manageMappings command to update a mapping, and you used the -outputFile option, you will need to use the -map option when migrating in followed by the XML file that was created by manageMappings.
GatewayMigrationUtility.sh migrateIn -argFile example.properties –bundle example.xml -results result.xml -map bar.xml
The -test option can be used to test the migrate in without actually migrating in.
/path/to/GatewayMigrationUtility.sh migrateIn -argFile example.properties –bundle example.xml -results result.xml -test