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.
Why and when to perform this task
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.
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_name/temp directory. You can use the restoreConfig command to restore the backup, if required.
Steps for this task
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 WebSphere Application Server node to a V6 stand-alone Application Server:
startNode.sh
Occasionally, for example after rebooting an Application Server machine, you must restart the nodeagent server on the Application Server node, by running the startNode command from the profile_name/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.
Result
You can use the migration tools to migrate from one version of WebSphere Application Server to another.What to do next
Return to Migrating and coexisting to continue.