Portal V6.1.x on application server V6.1 stand-alone: Using copies of source database domains to minimize downtime
To keep the earlier portal environment in production and reduce the amount of downtime during migration copy the earlier portal server JCR and Release domains. Connect to the domain copies and then update the new portal server with 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 Portal profile.
About this task
Important:
- Copying the source portal JCR and Release domains is a recommendation but not a requirement. If you point the new portal server to the source portal domains, you cannot use the JCR and Release domains with the earlier portal server.
- During migration, the Community and Customization domains are upgraded to their new definitions required by the new WebSphere® Portal release. This migration might break the compatibility with the source portal server. Carefully check the requirements for the source portal server if you plan to use the earlier portal server until migration is finished.
- There will be a major schema change in the JCR database that might cause the JCR database to triple in size. Take this into consideration when you create the new copies of the database, and ensure that there is enough disk space for the new copies.
- (DB2® only): When you migrate a source portal to a target portal that uses a different driver type, reconnect all of the affected domains. For example, the source portal is using DB2 with Type 2 drivers for all domains. You plan to use a Type 4 driver type for all of the domains in your target portal. In this case, you must reconnect all of the database domains that use the connect-database command.