IBM Verify

For some reasons there is no documented way of moving your environment in case of new servers - but the procedure for migrating is the best option and will work IIRC with some (undocumented) tweaking. My best advice is to raise an IBM Support case and probably also involve IBM on this challenge as this will probably require some help from larger IBM team.

Under normal circumstances I would have recommended moving to IVIG V11 - but this is probably not an easy option due to the RDBMS being Oracle. The container version uses PostgreSQL (if the DB is container based) - but external Db2 is also an option - but that requires a move from Oracle which is always a challenge....

Thank you very much for the information, @Franz Wolfhagen . As always, it is much appreciated.

Tentatively I have some success! I followed the instructions in #1 in my original post, but then I installed 10.0.2, which DOES see that it can upgrade from 10.0.0. And so far it looks like a success. I need to do more testing, but this seems like it works so far.

So you CANNOT simply move version 10.0.0 to a new set of servers. However, if you move 10.0.0 to those servers, then upgrade to 10.0.2 on top of the install (before starting any application servers), that appears to work great.

Hello, 

I've never tried to achieve something like this but this is what comes to my mind. I would also install a fresh copy of WAS servers but instead of pointing out to old LDAP and Oracle DB, I would use empty fresh instances just for once, so the installation finishes as it should. Later, like in an event of LDAP IP or DB user password change, I would try to use runconfig.exe to switch to the already existing ldap and database. That should upgrade the data sources and ldap configurations, similar to the process mentioned here. https://www.ibm.com/docs/en/sim/7.0.2?topic=administration-passwords-system-users. Since the application installed in was is the same version (10.0) with your old Ldap/db's expected version runconfig's update should be able to point it to old infrastructure. If this doesnt work, and hosts names are buried elsewhere some dns name <-> ip changing is the next thing that I can think of.

Anyway,  I'm curious if your last approach worked without any issue. This is a big task, hope it works. 

I meant to update this but got busy.

My last approach DID work, with a tweak required. The steps I went through are:

1. Install new WAS servers and configure clusters.
2. Stop your old WAS servers.
3. Clear the SIB. This is really important! You can actually clear it after you complete the install/upgrade, but you should do it at this point.
4. Copy /opt/itim directory from old 10.0.0 dmgr server to new dmgr server, and the same for the second server.
5. Run the 10.0.2 install on the new dmgr server. STOP when it brings up the Identity Manager System Configuration tool.
6. Don't kill or exit the process, just don't move forward because you need to manually edit a file that was copied to the new server at some earlier point in the install. The file you need to edit is /opt/itim/config/was/deployEba.py. That script tries to delete the ITIM Service Center, and will error out and never install the service center if you don't do this step. Edit the script and delete the first "if" statement and the body of the if. The if statement is:
   
   if oldeba.find("noeba") < 0:
   ...
   
   Delete that line and the approximately 64 indented lines below it. They simply aren't needed. Copy/save the file.
7. Once you've made the above change, continue verifying the values in the Identity Manager System Configuration tool and click Continue.
8. The install will complete, and you'll have a brand new cluster with all of your old data.
9. Start the ITIM application and the Service Center BLA.

In going through this, what I found is that the 10.0.2 installer WILL let you run in again over the top of an existing 10.0.2 install (as opposed to the 10.0.0 installer, which bombs out). So what this means is that if you wanted, you could first upgrade your system to 10.0.2, and then move it over if you wanted. However, you will still need to go through the steps above (including manually editing the deployEba.py script), but it would be an "upgrade, then move", which would allow you to do more apples-to-apples testing/validation after the fact.

Thanks for documenting the steps - I hope this will help others. 

I seems to remember I had related problems with the EBA installing IVIG 10 some years ago - there I solved it by installing it manually using the WAS console - probably not the best way as it would have been better to find the root cause so that others did not have to counter this problem - but alas time does not always allow deep diving into problems that you can fix....