Introduction

Migration is typically a time-consuming process, the main concern of which is the down time. In this article we introduce a migration process that can minimize the down time. Even if our process is not 100% applicable to your case, you can customize it according to your actual environment.

Migration phases

IBM Connections 4.0 has three main phases that must be considered for migration: Database migration, IBM WebSphere Application Server (WAS)-side migration, and Content Store migration. Figure 1 illustrates how to perform the migration for each of the parts, using either the Migration tool or manually. But how do you choose which method to use?

Figure 1. Three phases of migration

• Database side. If you have a GUI, it's recommended to use Database Wizard; if you do not have a GUI, you can choose either the silent way or manual way. Note, however, that the Homepage database is special, and it will take much more time to upgrade than the other databases.

Migration steps

Now that you have a general idea about the migration process, let's discuss the specific migration steps we've compiled that will minimize down time. Basically, they are as follows:

1. Save your customization. This is very important. You should back up all your customizations, including those in configuration files, templates files, and in the customization folder.
2. Copy the 4.0 migration tool into the 3.0.1.x deployment, into <IC_HOME>/migration.
3. Export applications data from 3.0.1.x, using a command like this:

4. Install and configure a new WAS instance on the new system.
5. Prepare a new location for the 4.0 Content Store; we want to make sure the old Content Store could still be in use.
6. Install a 3.0.1 test database on a new instance, transfer the 3.0.1.x database to the test database, and update it to 4.0. This test database will be used for the install verification and other configuration verification.
7. Install IBM Connections 4.0 on the new system or the same system as 3.0.1.x, if your server is powerful enough.
8. Back up the 4.0 installation and create a backup copy of the 4.0 WAS Deployment Manager (DMgr) profile directory.
9. Keep the 4.0 nodes shut down but the DMgr in running status.
10. Copy the exported applications data to the new 4.0 system under <IC_Home>/migration/work.
11. Import the application data into 4.0, using a command such as;

12. Restart DMgr and start the 4.0 nodes and cluster, after you have ensured that the nodes have been synchronized.
13. Verify the newly installed environment works properly. You will need your test database at this stage. If you have any other post-install configurations such as SSO, you can continue to use this test database for verification.
14. Shut down the 3.0.1.x deployment. (You haven't needed to shut down the 3.0.1.x deployment until now, so what's left is the Content Store and production database migration.) Because we need to make sure all data will be migrated to 4.0, they must be done after 3.0.1.x has been shut down.
15. Copy over the 3.0.1 Content Store to the 4.0 Content Store:

• For in-place database migration for the production 3.0.1.x database, it's very important to always back up your database before the migration.

• In the final cut over, modify JDBC to point to the production database.

Note that this is not a complete list of steps. There are still many post-migration steps if you have more customizations that are not handled by the migration tool. Refer to the Post- migration tasks topic in the product documentation to complete them.

As noted above, in this process you don't need to shut down the 3.0.1.x deployment at the start, which has shortened the down time greatly. If, however, you don't have a new system to use, check your system to see whether it is powerful enough to host two running deployments. If so, then you can implement the same process on the same system. It's just like another running instance on the same system.

Minimizing search-index building time

Another best practice is to shorten the time it takes to build the search index. If you have a large number of users and a large amount of content in the shared Content Store, it will take a long time to build the search index, and it's even likely to fail.

Building the search index can be separated into two parts:

(1) Building the index for Content Store, Activities, Files, and Wikis, depending on the Content Store;
(2) Building the index for database information. All the rest of the features' search indexes are built based on database information. It's suggested to use the manual method for dealing with such a large-content situation.

Once you have finished the WAS-side migration, you can build the search index based on the database information, although that is not the final data. After the final database migration, you can use this search index and just built the delta for these indexes.

But how can you build the search index without referencing the Content Store? To do this, disable the automatic search indexing when the search server starts up by disabling all the schedulers. Then you can run backend SearchService commands to start the building index tasks to build your indexes for all features except Activities, Files, and Wikis. Refer to the SearchService commands topic for more details.

In this way, you don't need to wait for the final day to build the search index, as some of the work is finished beforehand. Once you have finished the Content Store migration, you can build the search index for Activities, Files, and Wikis, using the backend SearchService commands. You can then enable the automatic search indexing after all these have finished.

Conclusion

Although the process we've outlined here may not match your situation exactly, it provides a good guide that you can use as a reference. Migration is a complex process, so make sure to plan it carefully before you start.

Tell us what you think

Please visit this link to take a one-question survey about this article:

Resources

developerWorks IBM Connections product page:
http://www.ibm.com/developerworks/lotus/products/connections/

IBM Connections documentation:
http://www.ibm.com/developerworks/lotus/documentation/connections/

IBM Connections Forum:
http://www-10.lotus.com/ldd/lcforum.nsf

About the authors

Jing Yao is a Staff Software Engineer working with the IBM Connections Install in Shanghai, China. She has four years of experience in install and migration technology and has extensive knowledge of WebSphere Application Server deployment and configuration. You can reach Jing at yaojing@cn.ibm.com.

Xiang Jun Fan is a Software Engineer at IBM's China Software Development Lab in Shanghai. He's been a member of the Lotus Connections Functional Verification Test (FVT) team since March 2009 and is responsible for Connections migration from the 3.0 release. Before that, he worked on software development for the telecom industry for two years. You can reach Fan at xjfanxj@cn.ibm.com

Bill Kilduff is an Executive Architect based at IBM's New York City office working in IBM's internal IT system, into which IBM Connections is deployed and used by all IBM employees. He has rich experience in Connections maintenance and migration. You can reach Bill at bill_kilduff@us.ibm.com.