Plan checklist: V6.1.x portal on a V7 application server

Use the worksheet below to plan migration from WebSphere Portal v6.1.x and identify issues that require special attention. You might also want to print a copy of this document so that you can add own notes to the table below.

Table 1. Checklist for planning migration


Checkpoint Notes User Notes
Infrastructure


Product version and family Which product version and family is deployed in the existing environment?

Which product version and family do you want to migrate to?

Always try to migrate to the latest release of the target version.Migration is supported from the two latest available fix pack levels of v6.1.x and between the same product families (Express, Express Plus, Enable, Extend), and from Express to Enable, Express Plus to Extend, Express to Extend, and Enable to Extend.

For example, if you are using WebSphere Portal v6.1 or 6.1.0.1, and the two most recent fix packs are 6.1.0.3 and 6.1.0.4, upgrade to either fix pack before you can migrate to v7.0.

Migration is not supported to a portal release that contains an enabled feature pack.


Deployment scenario Do you have a standalone server environment or a clustered server environment?

Hardware What hardware does the existing portal run on?

Do you plan to migrate to the same hardware or to new hardware?



Operating system What OS and version does the existing environment run on?

Does the target version that you want to migrate to support that OS and version?

You can migrate from an older version of an OS to a newer supported version of that OS, or from a 32–bit version of an OS to a supported 64–bit version of that OS

Migrate between different OSs is not supported. For example, you cannot migrate from a Windows™ OS to a UNIX™ OS.

WebSphere Portal v7.0 does not support SUSE SLES 9. If earlier portal runs on SLES 9, you need to upgrade to SUSE SLES 10 before migrating to WebSphere Portal v7.0. See the SLES 10 documentation for instructions on upgrading the OS.


Application server


User registry What does the existing portal installation use to store user account information:

  • Lightweight Directory Access Protocol (LDAP)

  • WebSphere Portal database

  • Custom user registry

If you use LDAP, do you plan to move to a different LDAP server?
Perform maintenance cleanup on users and groups as needed before migrating. For example, clean up deleted users and their personalized pages before starting migration.

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.


Database Does the new portal installation support the database that the earlier portal installation uses?

Can the database be upgraded if needed?

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.

If you are migrating from WebSphere Portal configured to use DB2V9, ensure that source environment is running the minimum required level – either V9.1 with Fix Pack 6 or later, or V9.5 with Fix Pack 5 or later.

If you used Derby as the default DBMS in the earlier version, transfer data to a supported DBMS before executing migration steps

WebSphere Portal v7.0 requires the use of type 4 spec 4 database driver.


Database schemas
WebSphere Portal generates SQL scripts that automatically upgrade database schemas during migration.
Web server What HTTP server does the existing installation use?

Does the new installation support this HTTP server?



External security
Supported IBM and third-party security settings are migrated automatically.
Pre-built sample Web sites
If you migrate from V6.1x and optionally installed the sample Intranet and Internet sites for that version, the target portal server can support sample sites from both the earlier version and the new version. However, to ensure that the V7.0 sample sites are available, run the configure-express task after completing migration.
Administration and Maintenance


Backup Do you have a backup plan and schedule in place for the new portal server? Back up the existing portal database before starting migration.
Cleanup and maintenance Have you installed one of the two latest fixpacks to bring V6.1.x portal installation to the required service level for migration?


Have you changed the default settings of the scheduled cleanup service? Changes to the scheduled cleanup service settings are not migrated. If you modified these settings in the earlier portal and want to continue using the same settings in the new portal, update the settings on the new portal.
Customized portal resources


Custom themes and administration Does the earlier portal installation use custom themes?


Does the earlier portal use custom administration themes?


Does the earlier portal use customized administration portlets or pages?


Does the earlier portal use customized global settings?


Have any portal service configurations been customized?

Custom portlets
WebSphere Portal v7.0 uses the IBM WAS portlet container for standard portlets. Migrated portlets that rely on the Java™ Specification Request (JSR) 168 or 286 Portlet API will continue to work unchanged.

Does the earlier portal have any portlets that were developed by using IBM Portlet API? The IBM Portlet API is still supported but it deprecated in WebSphere Portal v6.0 and later.

If you have portlets that use the legacy API, you are not required to convert them to JSR portlets before migrating; however, after you complete migration, converting these portlets is strongly recommended.



Does the earlier portal have custom portlets that use Click-To-Action (C2A)? The pbportlet.jar file must be updated to match the version that WebSphere Portal v7.0 uses.

Do any custom applications in the earlier portal use private IBM APIs? You must update these applications to use the public version of the IBM APIs.

Have you installed and deployed third-party portlets? Third-party portlets must be certified for use with the latest version of WebSphere Portal.
Remote portlets


Search Do you want to migrate custom search collections? Search Web collections that were created in an earlier version of WebSphere Portal can be exported and imported into v7.0. See Migrate web collections from V6.1.
IBM Web Content Manager
Web Content Manager requires a JCR repository of the same version. Even though you might have different version repositories stored in the same database, Web Content Manager V7.0 only works with the V7.0 repository.

If you have any Web Content Manager data that references a Portal Document Manager library, replace the Web content that was stored as a document in the document library before you begin the migration process. See Document migration.


Business portlets
See Deprecated business portlets.
Collaborative portlets
iNotes, Lotus Notes View, and Lotus Document Viewer are migrated with other portlet applications.

For information on deprecated portlets including My Lotus QuickPlaces, Inline QuickPlaces, Domino Document Manager, and Lotus Web Conferencing, see Deprecated collaborative portlets.



Parent

Migrate V6.1.x on a V7 application server


Related tasks


Prepare for migration
Migrate V6.1 search components
Migrate a stand-alone portal that runs on a V7 application server
Migrate a V6.1.x clustered environment
Converting IBM portlets

IBM Software Support, DB2 9

WebSphere Portal detailed system requirements

  Jul 1, 2011 11:03:48 AM Added note about Derby migration - PM42058


+

Search Tips   |   Advanced Search