OAM 11g: The Policy migration Strategy

The purpose of this post is to provide some tips when planning a policy migration from Oracle Access Manager (OAM) 10g to OAM 11g.  Before you begin, I recommend that you install the latest Bundle Patch (BP).  At the time of this writing, the latest BP for OAM 11gR2PS1 is patch 16872730.  Installing this patch will save you lots of time as there has been a few important bugs fixed in this release.  Secondly, take a look at the documentation link here; within the document take note of Table 11-1.  The table the describes what artifacts are compatible from OAM 10g.

The first step is to run a policy migration report on the OAM 10g artifacts.  This report will display all artifacts along with the compatibility mode.  The modes are COMPATIBLE, INCOMPATIBLE, INCOMPATIBLE WITH LESS FEATURES and IGNORE.  The documentation goes over these modes in more details and the report will give you an idea on how much of manual changes you will need to make in your new OAM 11g environment.  The more of the INCOMPATIBLE type modes could mean more manual changes.  The report file can be huge depending on your data set; however, the file itself has a lot of blank spaces due to formatting of the data.  I recommend that you replace say two blank spaces for one in your favourite editor.  This should make it easier to read the file.
Here is a small sampling of the file.

I added a single line for each artifact type:

Artifact Type	Artifact	Details	Compatibility	Message
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:/
RESOURCE TYPES	http		COMPATIBLE
HOST IDs	sourceHostID	Host:Port source.us.oracle.com& source.us.oracle.com:80& source.us.oracle.com:443	COMPATIBLE
AGENTS	sourceWG	Mode: cert	COMPATIBLE
POLICY DOMAIN	Oblix::Resources	/identity	IGNORE

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.