You can directly migrate your IBM Connections to version 4 if your current installation is on version 3.0.1.x. For earlier versions, you must do an incremental upgrade.
The following figure shows the incremental upgrade between various IBM Connections versions.
Before you begin
Ensure that your environment meets the hardware and software requirements for IBM Connections 4.0. If you have a version of IBM Connections that is earlier than version 3.0.1.x, you must migrate it to version 3.0.1.x before migrating to version 4.0.
If you plan to install the new Metrics application, it is recommended to deploy IBM Cognos Business Intelligence before installing IBM Connections 4.0. However, you can defer deploying Cognos and still install Metrics.
Plan and choose your migration strategy depending on your requirement.
Further sections in this chapter will guide you on how you can migrate your IBM Connections environment to 4.0.
Saving existing customization
Before you upgrade your environment, it is very important that you save your customizations from the existing setup. You will have to reapply most of the customizations again manually.
The files that you need to migrate again manually include:
- User interface (customized CSS, JSP, and HTML; labels and strings)
- Header and Footer
- Email notification templates
- Blog themes
- Security role mappings
- IBM Connections Connector for IBM Quickr
- Server whitelist for publishing file attachments from Activities to IBM Quickr
Backing up your IBM Connections environment
It is recommended to back up your databases and applications before starting the upgrade process.
How to take the back up is your choice and you can take a decision depending upon your environment. You can choose between backing up the entire deployment at once or individual applications.
There are several procedures required to migrate your deployment. Your migration strategy determines which procedures you need to follow. An in-place strategy minimizes costs but causes more downtime. It is similar to the side-by-side strategy except that you do not need to deploy new hardware.
The main advantage of using this strategy is that you need minimal new systems. The disadvantages of this method are the down time is longer and if instructions are not followed and an unclean installation is done then the environment can be corrupted.
Use these steps for in-pace migration:
- Save your customizations.
- Create a back-up these elements of your current 3.0.1.x environment:
Copy the migration tool in the current environment under /migration directory.
Export application data.
- IBM Installation Manager data directory
- IC_Home, Installation Manager and SSPShared directory
- WebSphere Application Server profile directory
- profileRegistry.xml file located under WAS_HOME/properties
Shut down your 3.0.1.x deployment and uninstall it.
Clean up all the nodes.
Upgrade database to 4.0.
Upgrade Websphere Application Server to 184.108.40.206.
Delete local content store and anything related with search in shared content store.
Install IBM Connections 4.0.
Create a back-up copy of WAS Deployment Manager profile directory.
Keep the Deployment Manager running but shut down all the nodes.
Copy the exported applications data to the 4.0 environment under /migrations/work.
Import application data using: /migration.sh|bat lc-import -DDMUserid= -DDMPassword=
Restart Deployment Manager.
Start and sync all nodes and start cluster.
- Perform full synchronization of all the nodes.
- Rename migration directory.
- Copy the migration_220.127.116.11_date_time.zip file from the IBM_Connections_Install/IBMConnections/native directory of the installation media, where date and time represent the date and time stamps of the file.
- Extract the file to the IBM Connections 3.0.1.x installation directory. You should get a migration directory at the same directory level as the ConfigEngine directory.
- Open a command prompt on the version 3.0.1.x system, change to the migration directory and run the following command depending on your OS: ./migration.sh|bat lc-export.
- Back up the migration directory to a location outside your 3.0.1.x deployment.
A side-by-side migration strategy minimizes the downtime of your production environment but costs more in terms of hardware resources. The advantage of this upgrade method is that minimum down time is required. The disadvantage is that you will need new systems.
Use these steps for this side-by-side migration:
- Save your customizations.
- Copy the migration tool in your 3.0.1.x environment under /migration.
- Export application data. Refer to in-place migration section for the procedure.
- Install and configure a new WAS instance on your new system.
- Create a new location for 4.0 content store.
- Install 3.0.1 test database on new instance and transfer the 3.0.1.x database to the test database and update 4.0.
- Install IBM Connections 4.0 on the new system.
- Create a back-up copy of the WAS Deployment Manager profile directory.
- Run the Deployment Manager but shut down all the nodes.
- Copy the exported applications data to new system under <IC_Home>/migration/work.
- Import application data using: /migration.sh|bat lc-import -DDMUserid= -DDMPassword=
- Restart Deployment Manager.
- Start and sync all the nodes and start cluster.
- Verify your new setup.
- Shut down 3.0.1.x deployment.
- Copy 3.0.1.x content store to 4.0 content store.
- Perform in- place database upgrade.
- Modify your JDBC and other parameters accordingly.
After updating or migrating IBM Connections, you must manually update any custom fields and customized files that could not be automatically updated or migrated.
- Migrate any JSP, CSS, and string customizations.
- Verify that your Blogs themes are present in 4.0. If not, manually update them.
- Update your customized Community themes.
- Copy the 3.0.1.x version of the profiles-policy.xml file to the 4.0 deployment, overwriting the 4.0 version of the file.
- Copy the customized XSD elements of the 3.0.1 service-location.xsd file to the 4.0 version of the file.
- Redefine customized Profiles fields in the validation.xml file.