Use copies of source database domains to minimize downtime
When you migrate from WebSphere Portal V6.1.x on IBM WAS V6.1, the recommended way to keep the earlier portal environment in production and reduce the amount of downtime during migration is to copy the earlier portal server JCR and Release domains, connect to the domain copies, and then update the new portal server using the domain copies. The process of connecting to the domain copies must be done after you upgrade the ConfigEngine tool but before you upgrade the V6.1.x profile.
- (Important): Copy the V6.1.x JCR and Release domains is recommended but not required. However, if you choose to have the new portal server point directly to the V6.1.x domains (instead of to copies of the domains), you will not be able to continue using the JCR and Release domains with the earlier portal server.
- (DB2only): When you are migrating a source portal to a target portal that uses a different driver type, reconnect all of the domains that are affected by changing the driver type. For example, if the source portal is using DB2 with Type 2 drivers for all domains and you plan to use a Type 4 driver type for all of the domains in target portal, reconnect all of the database domains using the connect-database command. For more instructions, refer to the "Changing DB2 driver types" topic for OS.
- Use database tools to copy the source portal JCR domain and Release domain.
If you are using IBM DB2 Universal Database™ for z/OS®, review the following considerations:
- If you plan to use the DB2 Administration Tool to copy the database domains, additional steps are required to ensure that the migration process completes successfully. Refer to Technote 1441277 for instructions on using the tool during the migration process.
- Make sure you verify that the databases are not in a COPY PENDING state before you connect to the database copies as described below.
- On the target portal, in WP_PROFILE/ConfigEngine/properties, locate wkplc_dbdomain.properties and then update the jcr.* and release.* database properties to point to the JCR and Release domain copies that you created in the previous step.
If the source portal uses the default Apache Derby database, the migration tools automatically copy the database for you. However, if you have modified or customized the default Derby database, copy the entire Derby directory to a new directory, and then update all database properties to point to the copy of the Derby database. Ensure that derby.DBLibrary is set to use the WAS v7.derby.jar as the JDBC driver class and includes the directory location of the file. For example: derby.DBLibrary=WAS7_root/derby/lib/derby.jar
- If you are migrating a stand-alone local environment, before connecting to the domain copies, change the WAS and WebSphere Portal port numbers by running the modify-ports-by-startport task.
For details, see the topic that explains how to install WebSphere Portal on particular OS. For example, for Windows™, look for the section on setting up a stand-alone server on Windows, and then refer to the topic called Install WebSphere Portal on Windows.
- On the target portal, change to the WP_PROFILE/ConfigEngine and then connect to the copies of the Release domain and JCR domain:
- Windows:
ConfigEngine.bat validate-database-connection -DTransferDomainList=release,jcr
ConfigEngine.bat connect-database -DTransferDomainList=release,jcr
- UNIX™:
./ConfigEngine.sh validate-database-connection -DTransferDomainList=release,jcr
/ConfigEngine.sh connect-database -DTransferDomainList=release,jcr
- i:
ConfigEngine.sh validate-database-connection -DTransferDomainList=release,jcr
ConfigEngine.sh connect-database -DTransferDomainList=release,jcr
Parent
Migrate a stand-alone portal that runs on a V6.1 application server
Previous
Migrate the portal's V6.1 application server profile
Next topic
Retaining custom table spaces