Migrate a stand-alone portal that runs on a V7 application server
Migrate an WebSphere Portal V6.1.x stand-alone environment on IBM WAS V7 involves the high-level steps outlined here.
1. Upgrading the ConfigEngine tool
Upgrade the ConfigEngine tool on the target portal server from V6.1 to V7.
2. Preserve custom table spaces
If a database domain in the earlier portal server uses assigned custom table spaces that you want to retain for use on the new portal server (instead of using the default table spaces), you need to update the table space property file and the index space property file for the database table. Complete these updates only after you have upgraded the ConfigEngine tool.
3. Update the V6.1.x database schemas
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.
4. Update the configured driver for DB2 for z/OS
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.
5. Upgrading the portal profile
To migrate properties, upgrade database domains, and apply other updates that are needed to bring the profile to the V7 level, run the upgrade-profile task.
6. v6.1 Web content post migration steps
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
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
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 V6.1.x clustered environment