WAS v8.0 > Migration and coexistence > Distributed operating systems > Migrate product configurations > Migrate WAS ND configurations
Migrate to v8.0 federated nodes on remote machines
Use the migration tools to migrate from v6.x to a v8.0 federated node on a remote machine.
Supported configurations:
This topic is about configuration migration, such as migrating dmgrs and federated nodes in a network deployment environment. The Application Migration Toolkit for WAS provides support for migrating applications from previous versions of WAS to the latest product version. For information about migrating applications, read more about the Application Migration Toolkit. Read Overview of migration, coexistence, and interoperability and Premigration considerations.
Typically, you can use the WASPreUpgrade and the WASPostUpgrade migration tools to upgrade from v6.x to v8.0 on the same machine. However, some scenarios require that you migrate the v6.x configuration on one machine to v8.0 on a different machine. One of these scenarios is when you install new machines for your v8.0 environment but need to migrate your existing v6.x configuration from other machines.
If the node that you are migrating is part of a WAS ND cell, migrate the v6.x dmgr to v8.0 as described in Migrate to a v8.0 dmgr or Migrate to v8.0 dmgrs on remote machines before continuing this procedure. The dmgr must always be at the highest release level within the cell.
To ensure that your operating system is supported by WAS v8.0, visit the following site for the most current list of supported hardware and software: WAS system requirements.
If you find that your operating system is not supported for migration to v8.0, read Migrate stand-alone application servers from unsupported operating systems.
The v8.0 WASPreUpgrade command saves the existing v6.x configuration into a migration-specific backup directory. The v8.0 WASPostUpgrade command uses this directory to add the old configuration settings to the new v8.0 environment.
Tip: Before migrating a WAS v6.x federated node on a remote machine, use the backupConfig command or your own preferred backup utility to back up your existing configuration if to be able to restore it to its previous state after migration. Read the "backupConfig command" article in the information center for more information. Make sure that you note the exact name and location of this backed-up configuration.
For help in troubleshooting problems when migrating, read Troubleshoot migration.
Procedure
- Migrate the v6.x dmgr to v8.0.
Read Migrate to a v8.0 dmgr or Migrate to v8.0 dmgrs on remote machines for more information.
- Update any web sever configurations and supporting software.
Read Migrate web server configurations for more information.
- Update any web sever configurations and supporting software.
- Run the WASPreUpgrade on the federated node on the WAS Version 6.x machine.
Perform one of the following procedures:
- Install WAS v8.0 on the v6.x
machine, and run the v8.0 WASPreUpgrade command on the federated node.
Read the the "Installing the product and additional software" and WASPreUpgrade command articles in the information center for more information.
- Perform the following actions.
- Obtain the WAS v8.0 utilities disk.
This disk contains the migration/bin directory. This directory contains a special environment that you can use to run the WASPreUpgrade command without installing v8.0.
- Save the current federated node configuration using the WASPreUpgrade script from the migration/bin directory of the WAS v8.0 utilities disk, which mount on the v6.x machine.
Read WASPreUpgrade command for more information.
- Obtain the WAS v8.0 utilities disk.
In either case, the old machine must support the WAS v8.0 JVM.
Save the configuration in the migration_specific_backup directory on the v6.x machine.
./WASPreUpgrade.sh /filepath/migration_specific_backup /opt/WebSphere/AppServer -machineChange true
The WASPreUpgrade command provides status to the screen and to log files in the migration_specific_backup directory. ASCII log file names start with the text WASPreUpgrade and include a date and timestamp.
- Install WAS v8.0 on the v6.x
machine, and run the v8.0 WASPreUpgrade command on the federated node.
- Install WAS v8.0 on the v8.0 machine.
- Use the Profile Management Tool or the manageprofiles command to create a WAS v8.0 profile on the v8.0 machine.
Restriction: We cannot use the Profile Management Tool to create profiles for WAS installations on 64-bit architectures except on the Linux for zSeries platform. However, you can use the Profile Management Tool on other 64–bit architectures if you use a WAS 32–bit installation.
Read the "Creating profiles using the graphical user interface" article or the "manageprofiles command" article in the information center for more information.
- Copy the migration_specific_backup directory from the WAS Version 6.x machine to the v8.0 machine.
Use the ftp command, shared storage, or some other mechanism to copy the directory to the new machine.
- Optional: Shut down the federated nodes and servers on the v6.x machine.
- Add the WAS Version 6.x configuration to the v8.0 configuration.
Read WASPostUpgrade command for more information.
Use the WASPostUpgrade command in...
WAS_HOME/bin
of the v8.0 installation to add the v6.x configuration to the v8.0 configuration.
./WASPostUpgrade.sh /filepath/migration_specific_backup
WASPostUpgrade C:\filepath\migration_specific_backup
The WASPostUpgrade tool records information specific to each enterprise bean it deploys in the migration_specific_backup/WASPostUpgrade.log file. - Modify the configuration using the WAS v8.0 administrative console.
- Change user IDs and passwords to match security requirements.
You might have to change user IDs and passwords if they are not identical to those in use on the v6.x machine.
- Change other machine-specific information.
The configuration might refer to other software products or configurations that do not exist on the new machine. For example, the old machine might have a database. Modify the data source to point to the database on the old machine.
- Change user IDs and passwords to match security requirements.
- Manually disable the federated node on the v6.x
machine.
When you run the WASPostUpgrade command, the old node agent is stopped on the original machine; but it is still necessary to manually disable the federated node. The simplest way to do this is to rename the serverindex.xml file for the federated node on the old profile to something other than that name. Migration on the same machine renames the file to serverindex.xml_disabled.
This is required to ensure that the old node agent is not started. Having the old release's node agent communicating with the migrated dmgr after the federated node has been migrated is not supported.
- Start the node agent by running the startNode command from the PROFILE_ROOT/bin directory.
- Manually synchronize the node with the migrated dmgr.
If you fail to do so, the node will not be able to communicate with the dmgr and migration will not be able to upgrade the federated node.
Results
You have migrated WAS from v6.x
to a remote v8.0 machine.
Migrate product configurations
Migrate product configurations with migration tools
Related
WASPreUpgrade command
WASPostUpgrade command