Migrate product configurations
Before you begin
You can migrate administrative configurations with the Migration wizard or with the command line migration tools, as this task describes.
If you use an earlier version of WebSphere Application Server, the system administrator might have fine-tuned various application and server settings for your environment. It is important to have a strategy for migrating these settings with maximum efficiency and minimal loss.
You can perform incremental migration of V4.0.x nodes by calling the migration tools multiple times, each time specifying a different configuration file. Various reasons exist for having multiple configuration files. Whatever the reason, migrating one configuration file at a time lets you test applications incrementally before continuing to the next configuration file. You can also perform incremental migration of V5.x instances in the same manner.
Before using the migration tools, consult the V6.0 Release Notes document to understand what fixes you must apply to earlier versions. Applying fixes to an earlier version might also apply fixes to files that have a role in the migration. Apply any fixes to ensure the most effective migration of configurations and applications possible.
The migration tools in V6.0 support migration from the following versions of WebSphere Application Server: V4.0.x, V5.0.x, V5.1.x.
IBM provides a set of migration tools for migrating administrative configurations from V4.0.x, V5.0.x, or V5.1.x to the Network Deployment product.
When you use the migration tools, the overall migration process is:
- Install the V6 product.
- Use the V6 Profile creation wizard to create one or more profiles for a deployment manager, a managed node, or a stand-alone Application Server.
- Start the First steps console.
- Select the Migration wizard on the First steps console.
- Use the Migration wizard to migrate the previous release to the V6 product.
The Migration wizard calls the WASPostUpgrade command line tool. WASPostUpgrade uses the backupConfig command to save the existing V6.0 configuration before performing migration. The results are stored in the profile/temp directory. Use the restoreConfig command to restore the backup, if required.
- Migrate the deployment manager. Select one of the following migration scenarios for information about how to migrate configuration data to a V6 Network Deployment node:
- Migrating V4.0.x to a V6 deployment manager
- Migrating Network Deployment, V5.x to a V6 deployment manager
- Migrating a V5.x managed node to a V6 managed node
- Migrating a V5.x deployment manager configuration instance to a V6 deployment manager profile
Note: The V6 deployment manager must be running whenever you migrate a V5.x deployment manager to it. Also, if you are migrating a V5.x deployment manager, the V6 deployment manager must have the same cell name.
- Migrate V5.x and V4.0.x base WAS nodes.
Select one of the following migration scenarios for information about how to migrate configuration data from a V4.0.x or V5.x Express node or a V4.0.x or V5.x base WAS node to a V6 stand-alone Application Server:
- Migrating V4.0.x of WAS to a V6 stand-alone Application Server
- Migrating V4.0.x of WAS to a remote stand-alone V6 machine
- Migrating V5.x Express to a stand-alone V6 Application Server
- Migrating V5.x of WAS to a V6 Application Server
- Migrating V5.x of WAS to a V6 stand-alone Application Server on a remote machine
- Migrating a V5.x Application Server configuration instance to a V6 Application Server profile
- Migrating from an operating system that is no longer supported
Note: If you are migrating a V5.x managed node to a V6 managed profile, the node names must match.
- After migrating each base node, start each node. Use the startNode.sh or startNode.bat script from the profile/bin directory of each stand-alone Application Server to start the nodeagent processstartNode.sh
Occasionally, for example after rebooting an Application Server machine, restart the nodeagent server on the Application Server node, by running the startNode command from the profile/bin directory. To keep your Application Server nodes running, without having to access the bin directory of each one, use the operating system to monitor and restart the nodeagent process on each Application Server node. (You can also set up the dmgr server as a managed process on the deployment manager node.) For more information, see Automatically restarting server processes.
- Configure the WebSphere Application Server environment after migration, as described in Configuring WAS after migration. This is a way of verifying the results of the migration tools. You can also use Configuration mapping during migration to verify the results of the migration. The topic has a detailed description of how the migration tools migrate objects, and what you should verify.
ResultUse the migration tools to migrate from one version of WAS to another.
What to do nextReturn to Migrating and coexisting to continue.
Network Deployment migrations
Configuring WAS after migration
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.