Planning for migration

Doing a thorough planning before migrating to the latest version of WebSphere® Portal will have a direct impact in the effort invested during the actual migration. Become familiar with the environment you are migrating to (target environment). Also make sure that the environment you are migrating from (source environment) is up to date with fixes and meets the requirements for migration.

Prerequisites: What's changed; Unsupported and deprecated features

The following sections provide a starting point for your migration planning. Consider each migration planning unique to the environment you are migrating.

Before diving into more detailed planning, here are some additional migration considerations:

Take into account new development environment needs.
Education and cultural changes.
Contemplate different migration approaches and the impact on your business.
What is contained within migration and what is not.
Deprecated functionality.
Vendor software unique to your environment and how it might interact with the new version of WebSphere Portal.

Supported migration paths
Migration is supported between equivalent offerings. For example, you can migrate from WebSphere Portal Enable Version 7.0 to WebSphere Portal Enable Version 8.0, but not from WebSphere Portal Express Version 7.0 to WebSphere Portal Extend Version 8.0.
Hardware considerations
There may be cases where you will be doing a remote migration to a new hardware configuration. This new server may have different requirements from the current environment you are migrating from. Generally, here are some key points to consider.
Operating systems considerations
There might be cases where you migrate not just to a newer version of WebSphere Portal but also to a different operating system version. In that case, there might be a different set of system requirements and considerations to keep in mind.
Target environment
Installation planning of the target environment must be part of your overall migration planning. There are some considerations to keep in mind when you install WebSphere Portal and you plan to do a migration from your existing installation.
Configuring JVM heap size from command line
There are a number of factors to consider when migrating to a new version of a Java Virtual Machine. There may be new features supported and others deprecated.
High availability systems
There are a number of ways in which you can migrate WebSphere Portal to a newer version. Some migration scenarios might offer a higher availability percentage over another. There are some scenarios where the migration might be done in parallel while your source environment remains in production. Other scenarios might require the production system to be disconnected just before going live with the newly migrated system. Depending on your needs on high availability systems, you might choose one approach or another.
Clustered environments considerations
Special considerations for adding secondary nodes after you completed a clustered migration. The ConfigEngine.bat enable-profiles task is not supported on a clustered Portal node.
Distinguished names; Migration
If you are using LDAP in your source environment, make sure that the wkplc.properties file is properly configured. You might have a configuration what is working but it might not be supported after migration. Short distinguished names (DN) are not supported. Make sure that the properties files in your source environment are set with the fully qualified distinguished names.
Local migration
There are a few migration combinations that can be considered local migration depending on the availability of the environment being migrated. At a minimum, you have two distinctive options with this migration path. You can perform a local migration taking offline the source environment or you can maintain both source and target environments coexisting. Depending on the migration path you choose, there might be additional factors to consider
Remote migration
A remote migration scenario is when your source and target environments reside on different machines. There are certain platforms, like z/OS, where remote migration is not supported.
Portal farm migration
Portal farm, from a migration perspective, it is similar to a stand-alone environment. The main difference is that you have several, although identically configured, stand-alone environments to migrate.
HTTP Server migration
As part of your WebSphere Portal migration, you may also need to migrate your HTTP Server and plug-in.
Backup and recovery
Backup and recovery of data files and databases is an essential operation for any business system, particularly for data and applications that run in production environments. Create and follow a plan for backing up and recovering data on all tiers of your IBM WebSphere Portal deployment. IBM Installation Manager must also be included in backup and recovery planning. If you back up the WebSphere Portal file structure and then install a fix pack, the WebSphere Portal and IBM Installation Manager become out of sync after you restore the WebSphere Portal file system. This condition is not recoverable.

Parent topic: Migrating

Related concepts:

Migration overview

Migrating Portal on AIX IBM i Linux Solaris Windows

Migrating Portal on z/OS

Related tasks:

Setting up the target environment

Post-migration activities

Deploying new functionality in a migrated portal

Related reference:

Deploying new functionality in a migrated portal on z/OS