Tuesday, September 7, 2010

Moving Lotus Connections to New Hardware

View Comments

Recently, I was asked what it would take to move a Lotus Connections deployment to new hardware. Not sure if this is valuable to anyone else, but I figured I would document it here just in case anyone else needs it.

Note: The awesome people at ISSL put this together, and with their permission, I'm including here.

The estimated duration will depend on several factors. Regardless, you will have to perform a full install of an empty system in the new environment to prepare for the migration. Other estimates are dependent on how the different environments are configured:

Pilot Version to Production Version: If the source environment is Lotus Connections Pilot Version, you will need to follow the detailed instructions in the information center to perform the data migration: http://publib.boulder.ibm.com/infocenter/ltscnnct/v2r0/topic/com.ibm.connections.25.help/c_pilot_migrate_overview.html

I have done this migration with one customer - it took about a day or two to complete, then there were a couple of days of setting up administration/product configuration specific to the new environment

Production Version to Production Version, same DB type, same LDAP: This is the simplest migration possible, which basically involved copying the shared file system and performing a native DB restore of the Connections databases, which should take a few hours. if there are any administrative or product configuration differences, they may take a couple of days to complete.

Production Version to Production Version, different DB type, same LDAP: A bit of a blend of the two migrations listed above - instead of using native database restored, you would either use the DB Wizard or manual scripts and migration utilities to move from the source DB type (ex.: Oracle) to the destination DB type (ex.: DB2). This type of database migration ay add a couple of days to the overall effort - and you have to be especially careful to validate that the scripts/utilities complete successfully

Production Version to Production Version, same DB type, different LDAP: This is a very complex migration if there is pre-existing data. There is no supported way to migrate data from one LDAP type to another and retain all of the non-Profiles user data. If they want to take this approach, it could take several weeks to design, develop and test the raw SQL scripts to perform the data conversion

blog comments powered by Disqus