Migrate to a v9.0 stand-alone application server on a remote machine
Use the migration tools to migrate from a v7.0 or later to a v9.0 stand-alone application server on a remote machine.
Note that this procedure will NOT work to migrate WAS from one OS, such as AIX, to another OS, such as Linux. This procedure only works if source OS matches the target OS.
To ensure that the operating system is supported by WAS v9.0, visit the following site for the most current list of supported hardware and software: WAS system requirements.
Read Overview of migration, coexistence, and interoperability and Migration considerations.
Tip: Before migrating a WAS v7.0 or later stand-alone application server on a remote machine, use the backupConfig command or our own preferred backup utility to back up our existing configuration to be able to restore it to its previous state after migration. Note the exact name and location of this backed-up configuration. See backupConfig command.
Rather than specifying individual parameters on migration commands, we can specify the -properties file_name.properties parameter to input a properties file. See Define our migration through properties.
For help in troubleshooting problems when migrating, see Troubleshoot migration.
Typically, we can use the WASPreUpgrade and the WASPostUpgrade migration tools to upgrade from v7.0 or later to v9.0 on the same machine. However, some scenarios require that we migrate the v7.0 or later configuration on one machine to v9.0 on a different machine. One of these scenarios is when we install new machines for our v9.0 environment but need to migrate our existing v7.0 or later configuration from other machines.
The WASPreUpgrade command saves the existing v7.0 or later configuration into a migration-specific backup directory. The WASPostUpgrade command uses this directory to add the old configuration settings to the new v9.0 environment.
For transitioning users: WebSphere Virtual Enterprise and Intelligent Management previously required separate migration tools but are now migrated as part of the standard migration procedures.trns
Tasks
- Install WAS v9.0 on the target machine. Install the same features as the earlier release if they are available. For more information, see Install and configure the application serving environment.
- Create the remote migration .jar file. This .jar file contains the files necessary to run the WASPreUpgrade command on a system which does not have WAS v9.0 installed.
We must create the remote migration .jar file on the same operating system and architecture as we installed the source. Because the archive generated contains operating system specific code, it only executes on this architecture.
- Identify the operating system and architecture of the source profile. If the operating system and architecture of the source profile is different from the operation system or the architecture of the target profile, then install WAS v9.0 on a system that matches the source profile before creating the remote migration jar. Once we have generated the remote migration jar, it will work on any system which matches the operating system and architecture.
- Create the remote migration .jar.
- In the command prompt, enter: cd $WAS_HOME/bin/migration/bin
- To create the .jar file, run: createRemoteMigrJar.bat(sh) -targetDir <dir_for_the_remote_migration_jar> . This creates the following file: WAS_V90_OS.arch_RemoteMigrSupport.jar. For example: WAS_V90_windows.amd64_RemoteMigrSupport.jar
- Prepare the remote system for the WASPreUpgrade command.
- Send the .jar file to the system where your source profile resides.
- Extract the file to a temporary location.
- Change directories to the bin directory in the temporary location.
We are now ready to run the WASPreUpgrade command against the source profile. However, do not issue this command until we are told to do so in a later step.
- Save the current deployment manager configuration by running the WASPreUpgrade command on the source host. See the steps about saving and archiving the configuration data in Migrate cells across operating systems using the command-line tools.
- Copy the migration_specific_backup directory from the WAS v7.0 or later machine to the v9.0 machine.
Use the ftp command, shared storage, or some other mechanism to copy the directory to the new machine.
- Use the Profile Management tool or the manageprofiles command to create a WAS v9.0 profile.
- Add the WAS v7.0 or later configuration to the v9.0 configuration.
Use the WASPostUpgrade command in the app_server_root/bin directory of the v9.0 installation to add the v7.0 or later configuration to the v9.0 configuration.
(UNIX)
./WASPostUpgrade.sh /filepath/migration_specific_backup(Windows)WASPostUpgrade C:\filepath\migration_specific_backupSee WASPostUpgrade command for more information.
The WASPostUpgrade tool records information specific to each enterprise bean it deploys in the migration_specific_backup/WASPostUpgrade.log file.- Verify that the configuration and applications were migrated correctly.
If the configuration was migrated correctly but any applications were not installed, we can run the WASMigrationAppInstaller command to install only the applications that were not migrated. See WASMigrationAppInstaller command.
- Modify the configuration using the WAS v9.0 administrative console.
- Change user IDs and passwords to match security requirements.
We might have to change user IDs and passwords if they are not identical to those in use on the v7.0 or later 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.
We have migrated WAS from v7.0 or later to a remote v9.0 machine.
Migrate product configurations Use the migration tools Migration Toolkit on WASdev. WASPreUpgrade command WASPostUpgrade command WASMigrationAppInstaller command