Migrate a V6.1.x clustered environment
Migrate an WebSphere Portal V6.1.x clustered environment involves the high-level steps outlined here. Migration occurs on a per cluster basis rather than a per node basis. To achieve high availability migration, the portal site must have a multiple cluster topology already in place.
Before performing the migration tasks listed below, ensure that you have installed the required files to prepare and install the WAS V7 Deployment Manager on a dedicated system. For detailed instructions in this information center, locate the section on setting up a cluster and then see the topic on preparing the WAS Deployment Manager for particular OS.
1. Upgrading the ConfigEngine tool on primary and secondary nodes
Upgrade the portal server ConfigEngine tool from V6.1 to V7,
2. Preserve custom table spaces in a clustered portal
To use assigned custom table spaces from the earlier portal in the new portal, you need to update table space and index space property files for the database table.
3. Update V6.1.x database schemas
Database schemas that you used with IBM WebSphere Portal V6.1.x need to be updated for use with the new portal server primary node.
4. Update the configured DB2 for z/OS driver
If WebSphere Portal is configured to use IBM DB2 Universal Database™ for z/OS®, you need to update wkplc_dbdomain.properties to specify a type 4 database driver and then ensure that WebSphere Portal uses the new driver.
To migrate properties, upgrade database domains, and apply other updates that are needed to bring the node profiles to the V7 level, run the upgrade-profile task on the primary node and the secondary nodes.
6. v6.1 Web content post migration tasks
Once you have completed the WebSphere Portal migration steps, you need to perform these additional steps to complete web content migration.
7. Configure resource management and site management in a cluster
To ensure that the portal can retrieve metadata information for resource management on remote systems after migration, configure the Resource Manager portlet with information about the remote system and the settings used to handle communication with the system.
8. Update custom themes and skins with hardcoded context root references in a cluster
If you have developed custom themes or skins that contain hardcoded references to the portal's context root, this can cause problems if the context root is changed. This is particularly an issue after migration because the context root is modified during migration, causing hardcoded references to break. Rather than modifying custom themes and skins manually each time you change the context root, you can update themes and skins to remove the hardcoded references and instead use dynamic references that work properly regardless of the context root.
Parent
Migrate V6.1.x on a V7 application server
Plan checklist: V6.1.x portal on a V7 application server
Related tasks
Prepare for migration
Migrate V6.1 search components
Migrate a stand-alone portal that runs on a V7 application server