Here is a small sampling of the file.
I added a single line for each artifact type:
|DATA SOURCES||AS_User_Profile||Name:source.us.oracle.com, Host:idm.us.oracle.com, Port:3060||COMPATIBLE||The data store LDAP entry name source.us.oracle.com will be modified to source.us.oracle.com(AS_User_Profile).|
|AUTHENTICATION SCHEMES||10g Authentication||Description: Migrated: 10g Authentication scheme.||COMPATIBLE_WITH_ LESS_FEATURES||Some of the challenge parameters will not be migrated. Post migration actions will be required to modify the authentication scheme as per Oracle Access Manager 11g. Missing challenge parameters are: [name: form ,value: /login.htm, name: creds ,value: userid password domain authtype customPlugin, name: action ,value: /access/login.cgi, name: path ,value:/|
|HOST IDs||sourceHostID||Host:Port source.us.oracle.com& source.us.oracle.com:80& source.us.oracle.com:443||COMPATIBLE|
There are three modes of execute for the migration tool; these are COMPLETE, INCREMENTAL and DELTA. DELTA mode is new in PS1 and is not the same as INCREMENTAL. When planning your policy migration strategy one of the things you will need to decide is whether you are planning to co-exists with OAM 10g. If so, the policies in OAM 10g may change and you may need to push changes to your new OAM 11g environment. The DELTA mode is used in this scenario. INCREMENTAL mode is used when you only want a sub-set of the artifacts from 10g. Keep in mind that if you migrate single policy domain, all dependencies for that policy domain will also be migrated.
Once you have evaluated the report, the next step is to prep your OAM 11g environment. Now, I have never seen a migration attempted only once. Undoubtedly, you may need to run the migration tool multiple times due to testing/issues etc. Running the tool multiple times for the same data set against the same 11g environment is not recommended. Even if you remove all the data from the 11g environment, you may still see some unintended side effects. My recommendation is to make a clean back-up of the environment. Once you have installed OAM 11g (including the patch), make a back-up if the domain home directory. You may also need to modify the setDomainEnv.sh script to increase the JVM heap size as described here in section 11.17.2.
If the migration fails or has issues, here are the steps to get back to a clean state:
1) Shutdown the Weblogic Admin server.
2) Drop and create the OAM 11g Schema using Repository Creation Utility (RCU). Make sure you create the schema using the same schema name and password.
3) Remove the domain home directory and recover by copying the back-up directory. If you changed the JVM properties, make sure the changes exists after you copied from the back-up directory.
4) Run the configureSecurityStore.py script to re-associate OAM to the database policy store.
This will allow you to quickly re-run the migration tool against the same domain you initially created. Instructions for running the migration script is documented here. Depending on your data set; the actual policy migration could take hours. Running the script again without following the steps I outlined above will more than likely waste more of your time. Trust me.