This content has been marked as final. Show 4 replies
A migration is just a rebuild using your same original build process you used in R1. You would need to generate all your XML files from your current production, or environment that has same configuration. Capture all your jar files, custom code, event handlers, same as what you built in production. Then you would follow your same user load process and reconciliation from your targets. You might need to write custom code to poll your current oim instance though for your source data for any targets that are manual or do not have an end system to read from.
Then you also need to identify the gaps that are no longer available in R2 or have changed. You would need to configure your request process to match that of R2 configurations. Configure application instances and all that stuff. Then regression test all your functionality to make sure it works in R2. Then follow the same process for all your stages of environments till you get to production.
Thanks a lot for your response, Kevin.
Do you suggest to upgrade in-place (existing OIM11gR1 to OIM11gR2) in comparison to migrate the configuration to OIM11gR2 in terms of complexity and efforts?
It depends, if your client just spent thousands of dollars to build a new R1 system, chances are, they aren't going to want to rebuild the whole thing again. I would suggest you build a new dev R1 system for them, with the current production configurations and go through the upgrade process. Document the pieces that dont work and what you do to fix them, and if it's feasible, go that route.
Thanks a lot Kevin.