Migrate a V6.1.x clustered portal
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. Migrate the dmgr
WebSphere Portal provides a plug-in that enables you to migrate the dmgr and nodes.
After migrating the dmgr, use the IBM WAS v7.0 tools to migrate the primary node and secondary nodes to v7.0.
3. Upgrading the ConfigEngine tool on the primary and secondary nodes
Upgrade the portal server ConfigEngine tool from V6.1 to V7.
4. Use Release and JCR domain copies
To keep the source portal environment in production and reduce downtime when migrating a clustered environment, it is recommended that you copy the earlier portal server Release and JCR domains and then update the target portal server's primary and secondary nodes to use the domain copies.
5. Retaining 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. Complete these updates only after you have upgraded the ConfigEngine tool.
Database schemas that you used with the earlier source portal need to be updated for use with the new target portal. The migration process handles these updates for you automatically. However, if the portal uses IBM DB2 Universal Database™ for z/OSas the backend repository, you can choose to view the SQL scripts that the migration process uses to update the database schemas.
7. Update the 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.
8. Upgrading primary and secondary node profiles
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.
9. 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.
10. Configure resource management for 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.
11. Update custom themes and skins for 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 V6.1 application server
Plan checklist: V6.1.x portal on a V6.1 application server
Related tasks
Premigration tasks
Migrate search components from V6.1
Migrate a stand-alone portal that runs on a V6.1 application server