Portal Upgrades: Best Practices

Question
IBM® WebSphere® Portal upgrades can be a very combersome undertaking. This document is meant to provide a basic set of what to do and what not to do when performing Portal upgrades.

Failure to observe these points, particularly in the 'What NOT to do' section can result in an unusable system and often results in complete reinstalls.

Answer
What to do:

* Ensure you have a working backup of your environment. This includes a full file structure backup AND a full database backup. Having only one or the other is no better than having no backup at all. Portal upgrades cannot be uninstalled if they fail.

Customers using DB2 on z/OS: When taking the database backup starting 6.0.1.4 and higher fix packs it is sufficient to only take a backup of the data but not the DB2 catalog as separate SQL files are provided to revert changes applied to the database schema during fixpack installation.
* Ensure file permissions are set correctly for UNIX environments. If you are using a non-root user, ensure that the user owns the AppServer directory, the PortalServer directory and the profile directory. Ensure that the non-root user has full access to the /tmp directory.
* If the upgrade fails, fix the problem with the upgrade and finish it before attempting anything else with the system (unless you decide to restore a backup).
* Ensure you have followed all of the 'Before You Begin' steps from the upgrade instructions.



What NOT to do:

* If upgrading a clustered environment, upgrade the primary node first. DO NOT upgrade a secondary first.
* If upgrading a clustered environment, DO NOT upgrade cluster nodes simultaneously.
* If an upgrade fails, DO NOT attempt to apply a different fixpack on top of a fixpack failure. This is the most common action that results in a complete reinstall.
* Do NOT upgrade a node that is federated but not clustered. Create a cluster first, even if it is just one node.
* If an upgrade fails, DO NOT attempt to further configure the Portal server (reconfigure secuirty, transfer the database, etc) until you have resolved the upgrade failure.
* When restoring a backup, DO NOT simply overwrite the existing WebSphere directory with a backed up one. You run the risk of corrupting the environment since overwriting the directory might not remove new files that had been laid down by the failed upgrade.