Migration Planning
1: Introduction2: WebSphere Portal/Product Offering Table
3: Changes introduced in WebSphere Portal V5.1
3.1: XML configuration interface changes
3.4: Portlets
3.5: Page object ID displayed if language is not supported
4.1:Tasks using the XML configuration interface
4.2:Tasks using direct database connections
6: Migrating bookmarks and internal URLs not currently supported
1: Introduction
The WebSphere Portal VV5.1 migration process is a combination of automated and manual steps. The automated steps (also referred to as migration tasks) are executed using ANT 1.5.4 scripts. The migration tasks provide optional granularity to allow for small manageable migration steps, rather than an all-or-none behavior. The manual steps that are performed depend on what features are in place on your WebSphere Portal V4.x system or WebSphere Portal 5.x system. Both processes are described in more detail in The migration process.
1:1: Supported migration paths
The following table details the supported migration paths. The left column indicates the current version of WebSphere Portal, and the right column indicates the version of WebSphere Portal to which you can migrate.
If you are migrating from V5.0.2.0 using an External Security Manager first upgrade to V5.0.2.1 before migrating to V5.1.
WebSphere Portal 4.x V 5.1 V WebSphere Portal Enable V4.1.6, 4.2.1, 4.2.2, 5.0, 5.0.1, 5.0.2, 5.0.2.1, 5.0.2.2 WebSphere Portal Enable V5.0 or V5.1 WebSphere Portal Extend V4.1.6, 4.2.1, 4.2.2, 5.0, 5.0.1, 5.0.2, 5.0.2.1, 5.0.2.2 WebSphere Portal Extend V5.0 or V5.1 WebSphere Portal Experience V4.1.6, 4.2.1, 4.2.2, 5.0, 5.0.1, 5.0.2, 5.0.2.1, 5.0.2.2 WebSphere Portal Extend V5.0 or V5.1
All WebSphere Portal versions listed above that are prior versions to V5.1 are sometimes referred to collectively as
previous versionsfor the remainder of this section.
- Migration to WebSphere Portal V5.1 is supported from WebSphere Portal versions 4.1.6 and higher.
- Migrating from one operating system to another is not supported. For example, you cannot migrate from Windows to Linux.
- Migrating across database servers is not supported. This means that data cannot be migrated from DB2 to Oracle or vice versa.
1:2: Cluster environments:
If you are using WebSphere Portal V4.x/5.0.x in a cluster environment, do not migrate the clone nodes to WebSphere Portal V5.1 individually. First, install a stand-alone WebSphere Portal V5.1 that will serve as the new main node for the WebSphere Portal V5.1 cluster. Migrate data from the WebSphere Portal V4.x/5.0.x cluster main node to the WebSphere Portal V5.1 main node. After you have established that migration has completed successfully, create your new clone nodes from the WebSphere Portal V5.1 main node.
2: WebSphere Portal/Product Offering Table
The following table lists software offerings by version number that are shipped with, or supported by, each version of WebSphere Portal.
This information is useful for planning your WebSphere Portal V5.1 installation and migration. For instance, you might find that upgrade your database version before installing WebSphere Portal V5.1.
Some software that is shown in the table is not shipped with WebSphere Portal and must be purchased separately. For the latest information on the software that WebSphere Portal ships and supports, refer to the Information Centers for the respective versions.
Product WebSphere Portal Version
V4.1.6
V4.2.1
V4.2.2
V5.0
V5.0.1
V5.0.2
V5.0.2.x
V5.1
WebSphere Application Server Advanced Edition
4.0 FP4
4.0FP5
4.0 FP5
4.0 FP5
4.0 FP5
5.0 FP1
5.0 FP1
(Enterprise)
5.0 FP1
5.1 FP1 (Enterprise)
WebSphere Application Server Advanced Single Server Editions
4.0 FP4
4.0 FP5
4.0 FP5
4.0 FP5
N/A
N/A
N/A
N/A
N/A
Portal Toolkit
4.2
4.2.5
4.2
4.2.5
4.3
4.2
4.2.5
4.3
5.0
5.0.1
5.0.2
5.0.2
5.1
WebSphere Studio
4.0.3
5.0(4.2 toolkit)
5.0.1 (4.3 toolkit
5.0(4.2 toolkit)
5.0.1 (4.3 toolkit
5.0.1
5.0.1
5.0.2
5.0.2
5.1
Rational Application Developer
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
IBM Cloudscape
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
DB2 Enterprise Edition/Enterprise Server Edition/Workgroup Server Edition/for z/OS
7.2 FP7
7.2 FP7
7.2FP8
7.1 (for z/OS
7.2 FP7
7.2FP8
7.1 (for z/OS
8.1 FP1 (Workgroup Server Edition/Enterprise Server Edition)
7.2 FP7 (Enterprise Edition)
7.2 FP8 (Enterprise Edition)
7.1 (for z/OS)
8.1 FP1 (Workgroup Server Edition/Enterprise Server Edition)
7.2 FP7 (Enterprise Edition)
7.2 FP8 (Enterprise Edition)
7.1 (for z/OS)
8.1 FP1 (Workgroup Server Edition/Enterprise Server Edition)
7.2 FP7 (Enterprise Edition)
7.2 FP8 (Enterprise Edition)
7.1 (for z/OS)
8.1 FP1 (Workgroup Server Edition/Enterprise Server Edition)
7.2 FP7 (Enterprise Edition)
7.2 FP8 (Enterprise Edition)
7.1 (for z/OS)
8.1 FP6 (Workgroup Server Edition/Enterprise Server Edition)
7.2 FP7 (Enterprise Edition)
7.2 FP8 (Enterprise Edition)
7.1 (for z/OS)
Oracle
8.1.7
8.1.7
9.2.0.1
8.1.7
9.2.0.1
8.1.7
9.2.0.1
8.1.7
9.2.0.1
8.1.7
9.2.0.1
8.1.7
9.2.0.4
9.2.0.4
SQL Server 2000
N/A
SP3
SP3
SP3
SP3
SP3
SP3
IBM HTTP Server
1.3.19.3
1.3.19.3
1.3.19.3
1.3.26.1 (included with WebSphere Application Server only)
1.3.26.1 (included with WebSphere Application Server only)
1.3.26.1 (included with WebSphere Application Server only)
1.3.26.1 (included with WebSphere Application Server only)
1.3.28.1 (included with WebSphere Application Server only)
2.0.47.1
IBM Directory Server/Secureway Directory Server
3.2.2
3.2.2
3.2.2
4.1 (IBM Directory Server)
4.1 (IBM Directory Server)
4.1 (IBM Directory Server)
5.1 (IBM Directory Server)
4.1 (IBM Directory Server)
5.1 (IBM Directory Server)
5.1 (IBM Directory Server)
Sun ONE Directory Server (formerly iPlanet)
5.0
5.0
5.0
5.1 FP2
5.1 FP2
5.1 FP2
5.1 FP2
5.2
Novell eDirectory
N/A
N/A
8.6
8.6
8.6
8.6
8.6
Microsoft Active Directory
2000
2000
2000
2000
2000
2000
2000
2000
2003
IBM Lotus Domino Enterprise Server (as appserver)
5.0.8
5.0.8
5.0.9a
5.0.9a
5.0.9a
5.0.9a
5.0.12
IBM Lotus Domino Enterprise Server (as Web server)
5.0.8
5.0.8
5.0.9a
5.0.9a
5.0.9a
5.0.9a
5.0.9a
IBM Lotus Domino Enterprise Server (as LDAP server)
5.0.9a
5.0.9a
5.0.9a
5.0.10
5.0.10
5.0.11
5.0.12
6.0
5.0.11
5.0.12
6.0
Lotus Collaborative Services
4.1.5
4.2.1
4.2.2
4.2
5.0
5.0
5.0.2
Lotus Collaboration Center
N/A
N/A
N/A
5.0
5.0.1
5.0.2
5.0.2
Productivity Portlets
N/A
N/A
N/A
5.0
5.0.1
5.0.2
5.0.2
Lotus Workflow
3.0A
3.0A
3.0A
N/A
N/A
N/A
N/A
Lotus IBM Lotus Team Workplace
2.0.8
3.0
3.0
3.0.1
3.0.1
3.01
3.0.1
IBM Lotus Instant Messaging and Web Conferencing
2.5
3.0
3.0
3.0
3.0
3.0
3.0
3.1
IBM Lotus Extended Search
3.7
3.7
3.7
4.0
4.0
4.0
4.0
WebSphere Site Analyzer/IBM Tivoli Web Site Analyzer
4.1
4.1.2
4.1.2
Tivoli Access Manager
3.9
4.1
4.1
4.1 with fix pack 2 installed
4.1 with fix pack 2 installed
4.1 with fix pack 2 installed
4.1 with fix pack 2 installed
IBM Content Manager
8.1
8.1
8.1
8.2
8.2
8.2
8.2
WebSphere Portal content publishing
4.0.1
N/A
N/A
5.0
5.0
5.0
5.0.2
WebSphere Personalization
4.0.1
N/A
N/A
N/A
N/A
N/A
N/A
3: Changes introduced in WebSphere Portal V5.1
3:1: XML configuration interface changes
complete two manual steps to accommodate the XML configuration interface changes in WebSphere Portal V5.1 from previous versions of WebSphere Portal.
- If you have custom deployment scripts that are written for a previous version of WebSphere Portal, convert these scripts to work with WebSphere Portal V5.1.
- Exported WebSphere Portal previous version configurations must include mapping to the original object IDs. add the include-mapping attribute to the request node of the export request and set its value to true. For example:
<request include-mapping="true">
<portal-action="export">
</request>
Refer to Migration tasks for more information on the migrate-xmlaccess-script command. For a description of the XML configuration interface changes for WebSphere Portal V5.0.2, see XML configuration interface - Changes for WebSphere Portal 5.0.2.
3:2: Access control changes
The access control architecture has changed significantly in WebSphere Portal V5.1. Migration tasks convert the permission-based access control in previous versions of WebSphere Portal to the new role-based access control that is used in V5.1. Because of the fundamental differences in access control between previous versions and V5.1, it is strongly recommended that you thoroughly verify the access to all aspects of WebSphere Portal V5.1 after the migration process is complete. See the Authorization topic for more information about access control.
Permissions that a principal (a user or group) had in previous versions of WebSphere Portal are mapped to the appropriate roles in WebSphere Portal V5.1. The following table illustrates this role mapping.
Permissions in Previous WebSphere Portal Versions V5.1 Roles View User Edit Privileged User Manage Manager Delegate Security Administrator View + Edit Privileged User View + Manage Manager View + Delegate Security Administrator + User Edit + Manage Manager Edit + Delegate Security Administrator + Privileged User (Migration option: Security Administrator + Editor) Manage + Delegate Administrator View + Edit + Manage Manager View + Edit + Delegate Security Administrator + Privileged User (Migration option: Security Administrator + Editor) View + Manage + Delegate Administrator View + Edit + Manage + Delegate Administrator Create No longer necessary. In WebSphere Portal V5.1, principals with the Administrator, Manager, Editor, or Privileged User roles on a resource are automatically allowed to create new resources underneath that resource in the resource hierarchy. The migration process creates inheritance blocks for all User, Privileged User, Editor, Manager, and Delegator roles on each resource. WebSphere Portal V5.1 supports inheritance of access rights by way of the resource hierarchy. Previous versions of WebSphere Portal did not support this type of inheritance. Thus, role blocks are required to ensure that principals do not gain more access rights than they had in previous versions.
Administrator and Security Administrator roles cannot be blocked. As a result, principals that had Delegate permission on a resource in previous versions automatically receive the Security Administrator role on the corresponding WebSphere Portal V5.1 resource and all of its child resources.
It is important that you inspect the access control throughout all aspects of WebSphere Portal V5.1 after completing the migration. Access control might require some changes if the migration process defaults are not suitable in your environment. The fundamental access control differences in WebSphere Portal V5.1 could produce unexpected results.
3.3: Custom themes and skins
The navigation model that is used by themes and skins has also changed significantly in WebSphere Portal V5.1. Any custom themes and skins that are written for previous versions must be modified to accommodate these changes. Refer to Manual migration steps for more information.
3.4: Portlets
Most portlets that are written for previous versions of WebSphere Portal will run unchanged in WebSphere Portal V5.1. However, there are a few exceptions related to packaging, and Struts portlets have to be manually migrated before deploying the portlets on WebSphere Portal V5.1. Refer to Manual migration steps for more information.
3.5: Page object ID displayed if language is not supported
If a page does not support any of the languages determined by the portal language selection process, then the object ID of the page is displayed in the navigation rather than its title. Such an object ID can be, for example, 7_0_5T. For details about the language selection process, see Language determined by the portal.
4: Automated migration tasks
Automated migration tasks are performed by running a series of commands. These commands are explained in more detail in the Run the migration tasks section. Automated migration tasks fall into two categories:
4.1: Tasks using the XML configuration interface
The XML configuration interface utility is supplied with WebSphere Portal. It allows access to portal data in XML format, independent of the underlying physical database that is used by WebSphere Portal.
The migration tasks make use of the XML configuration interface that is supplied with both the previous Portal version and WebSphere Portal V5.1 systems. The version of the XML configuration interface that is supplied with your previous Portal system is first used to extract portal data to XML files. These files are then supplied as input to the WebSphere Portal V5.1 XML configuration interface to import data into the new WebSphere Portal system.
It is possible to install WebSphere Portal V5.1 on the same machine as the previous Portal version. See the section on Software that can be installed on the portal machine under the Plan Considerations topic for coexistence restrictions on other products that are shipped with WebSphere Portal. When both versions are installed on the same machine, however, resource limitations might prohibit them from running at the same time. Therefore, you can also accomplish the migration tasks in two distinct steps: export and import. During export steps, the previous Portal server should be running. During import steps, WebSphere Portal V5.1 should be running.
The following WebSphere Portal artifacts are migrated using the XML configuration interface category of tasks:
- Client configuration: Configuration information for all clients that are supported by WebSphere Portal.
- Themes and skins configuration: Configuration information for custom themes and skins for WebSphere Portal. This configuration information includes locale-specific titles for your themes and skins and information on what skins are allowed for the themes.
The Java server pages, cascading style sheets, and other artifacts that are used to implement your custom themes and skins must be migrated manually.
- Portlet applications and portlets: Migration tasks are provided to facilitate deployment of your custom portlet applications to WebSphere Portal. In addition to the deployment, these tasks also migrate the associated access control information. Refer to the Migrate custom portlet code section of Manual migration steps to determine if update your portlets before deploying them.
In past releases WebSphere Portal supplied multiple portlets for each of the Notes/iNotes functions (e-mail, calendar, and so on). WebSphere Portal includes a single Notes and iNotes portlet. The migration procedures will handle this portlet merge to ensure that all portlet data is maintained during the migration.
- Portal pages, places, and favorites: The corresponding access control is migrated automatically with these artifacts.
- User customizations: Customizations created by privileged users that make changes to a private copy of their page.
- Access control on user groups: Tasks migrate permissions on most user groups within the portal. The XML configuration interface task does not migrate permissions on All Authenticated Users and All Anonymous Users. These permissions must be migrated with a manual procedure that is described in the Migrating remaining access control configuration section.
4.2: Tasks using direct database connections
These tasks use a direct connection to the physical databases in previous versions of WebSphere Portal and WebSphere Portal V5.1 and do not require that WebSphere Portal be running during their invocation.
The following portal artifacts are migrated using this category of tasks:
- Users, groups, and their extended attributes: Previous versions of WebSphere Portal used WebSphere Member Services for managing portal users and groups. WebSphere Portal V5.1 uses the new enhanced version of WebSphere Member Services, now referred to as Member Manager.
If WebSphere Portal is configured to use LDAP, the users and groups information will instead be stored in LDAP and will not need to be migrated. Any other data that is stored in the WebSphere Member Services database would need to be migrated.
- The WebSphere Member Services database must be cataloged locally in order to migrate WebSphere Member Services data to Member Manager.
5: Manual migration steps
Manual migration steps require more specific action than simply running commands. Refer to the Manual migration steps section for more detailed information on portal artifacts that require manual migration.
The following items must be migrated manually:
- Portlets
- Require manual upgrade of struts portlets built with previous Struts Framework to Struts 1.1 RC 1 supported by WebSphere Portal V5.1.
- Require repackaging of Click-to-Action portlets to update the pbportlet.jar.
- Access Control
- Access control for administrative places, pages, and portlets
- Access control for WebSphere Portal and Resource Types
- Credential vault data
- Themes and skins
- The Java server pages, cascading style sheets, and other artifacts used to implement custom themes and skins
- Other
- Property files, markups, and global and service settings are node and version specific and should be replaced by the configuration changes that are made to the WebSphere Portal system.
6: Migrating bookmarks and internal URLs not currently supported
The migration of bookmarks or the internal URLs for previous versions of WebSphere Portal is currently not supported. Support for migrating bookmarks and internal URLs is scheduled to be available in the future.
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.
Rational is a trademark of the IBM Corporation in the United States, other countries, or both.