Migration considerations

LDAP

Migration assumes that the earlier installed portal and the new installed portal use the same LDAP server. If the new version of WebSphere Portal does not support the LDAP that you used with the earlier portal server, upgrade the LDAP on the earlier portal server prior to migration.

If the earlier portal and the new portal are configured to use a standalone LDAP user registry, the users and groups in the new portal installation must be the same as the directory users and groups in the earlier portal installation.

External Security Manager

If the earlier portal environment is configured to use an external security manager and has resources that are under the control of the external security manager, you must configure the new portal to use that external security manager before starting migration. Alternatively, you can bring the externalized resources back under WebSphere Portal control in the earlier portal environment prior to migration, and then configure the new portal environment to use the external security manager after migration is complete.

Database

You can migrate from an older version of a database server to a newer version of that database server. Migrating between different database servers is not supported. For example, you cannot migrate from an IBM DB2® Universal Database™ Enterprise Server Edition database server to an Oracle database server.

When you migrate from Version 6.0.x, WebSphere Portal reuses the database tables from the earlier version in the new version. Keep these requirements in mind:

* If you used IBM Cloudscape as the default DBMS in the earlier version, you must transfer your data to a supported DBMS before migrating since the new version does not support Cloudscape.
* If the new portal installation uses the same DBMS as the earlier portal, you must use the same database driver when you connect to the earlier portal's JCR and Customization database domains.

Important: If the new portal installation uses the same DBMS as the earlier portal, you must use the same database driver to connect to the copy of the earlier portal's JCR database domain. For example, if you configured the new portal's release domain to use DB2 with a DB2 Type 4 driver, and the earlier portal's JCR database domain also uses DB2, you must use a DB2 Type 4 driver to connect to the copy of the earlier portal's JCR database domain. If the new portal uses Oracle for the release domain and the earlier portal's JCR database domain uses a different DBMS such as DB2, you do not need to use the same database driver to connect to the copy of the earlier portal's JCR domain.

Virtual portal

You must manually recreate each virtual portal in the new installation before you can migrate its contents. Use the create-virtual-portal ConfigEngine task to create an empty virtual portal with the corresponding name and URL context for each virtual portal that you want to migrate. Virtual portals are then migrated separately, one at a time, after you migrate the portal configuration.

If a virtual portal's admin pages are located under the wps.administration node, WebSphere Portal migration automatically sets these pages to the V6.1 Portal theme. If the admin pages are located under a different page hierarchy, you will need to manually set them to the V6.1 Portal theme following migration. For additional information, see Migrating themes.

If you choose to update a custom virtual portal admin page hierarchy, ensure that the virtual portal's admin page has a unique name assigned to it prior to migration.

Web Content Management

Web Content Management requires a JCR repository of the same version. Even though you might have different version repositories stored in the same database, Web Content Management V6.1 only works with the V6.1 repository.