To clarify some of the confusion around local and remote clone version-to-version migrations in WebSphere traditional, we felt it would be helpful to put out this preview of a new procedure we are working on documenting. Be sure to check out the full version-to-version migration documentation here. As you go through this guide, note that it is unnecessary to perform a migration from WebSphere Application Server to Version 8.5.5 to 9.0. If you are already running on WebSphere V8.5.5, you get the same support duration as V9 without migrating.  See what's new in the latest V9 release, but before you start any WebSphere traditional migration, take a look at Liberty as your migration target.

Clone migrating cells using the command-line tools
Clone migrating cells to new host machines using the command-line tool

---

Clone migrating cells using the command-line tools

You can use the command-line tools to migrate a cell from a previous version of WebSphere® Application Server to Version 9.0.

Before you begin

Review the migration planning information at Knowledge Collection: Migration planning for WebSphere Application Server.

Tip
Rather than specifying individual parameters on migration commands, you can specify the -properties file_name.properties parameter to input a properties file. For more information, see Defining your migration through properties.

This scenario covers clone migrating cells on the same host. If you intend to migrate cells to a different host, see Clone migrating cells to new host machines using the command-line tool.

For a standard clone migration, see Migrating cells using the command-line tools.

About this task

The cell configuration consists of a deployment manager with one or more nodes, a web server, and an application client. All ports are migrated forward into the new configuration. This procedure assumes that the previous configuration is running.

Avoid trouble
Ensure that your setting for the maximum number of open files is 10000 or greater. If the number of open files is too low, this can cause various migration failures.

For transitioning users
The following products previously required separate migration tools but are now migrated as part of the standard migration procedures:
- WebSphere Extended Deployment Compute Grid or Feature Pack for Modern Batch
- WebSphere Virtual Enterprise or Intelligent Management

Procedure

1. (Optional) Back up the deployment manager and all old nodes. In case of failure during the migration, save the current deployment manager and node configuration to a file that you can use later for recovery purposes by using the backupConfig For more information, see backupConfig command.
   1. Change to the deployment_manager_profile_root/bin directory.
   2. Run the backupConfig command with the appropriate parameters and save the current profile configuration to a file.
      For example:
      /opt/WebSphereV70/profiles/v70dmgr01/bin/backupConfig.sh /mybackupdir/v70dmgr01backupBeforeV90migration.zip -username myuser -password mypass -nostop

1. 3. For each node in the configuration, change to the node_profile_root/bin directory.
   4. Run the backupConfig command with the appropriate parameters, and save the current profile configuration to a file.
      For example:
      /opt/WebSphereV70/profiles/v70node01/bin/backupConfig.sh /mybackupdir/ v70node01backupBeforeV90migration.zip -username myuser -password mypass -nostop

2. Install WebSphere Application Server Version 9.0 in a new directory. For more information, see the installation documentation.

3. Create the target deployment manager profile by running the manageprofiles command with the appropriate parameters. The target deployment manager profile is a new deployment manager profile that will be the target of the migration.
   

   Avoid trouble
   The Version 9.0 deployment manager profile nodeName and cellName must match the previous Version 7.0 or later nodeName and cellName. If the Version 9.0 deployment manager cellName or nodeName are different, the migration will fail.

   For example:
   /opt/WebSphereV90/bin/manageprofiles.sh -create -profileName v90dmgr01 -templatePath /opt/WebSphereV90/profileTemplates/management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName -hostName mydmgrhost.company.com

4. Save the current deployment manager configuration to the migration backup directory by running the WASPreUpgrade command from the new deployment manager profile bin directory.
   The WASPreUpgrade command does not change the Version 7.0 or later configuration. For more information, see WASPreUpgrade command.
   

   Note
   If you are migrating from Version 8.0 or later to Version 9.0 and your profile is a deployment manager, the Version 8.0 profile is stopped when you run the WASPreUpgrade command. The deployment manager is only started before WASPreUpgrade completes if you provide -keepDmgrEnabled true on the command line or specify the corresponding option in the migration wizard.

1. 1. Run the WASPreUpgrade command, specifying the migration backup directory, the Version 7.0 or later installation root directory, and the deployment manager profile name.
      For example:
      /opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90dmgr01 /opt/WebSphereV70 -oldProfile v70dmgr01 -keepDmgrEnabled true -username myuser -password mypass

      Note
      for a same release migration include -allowSameRelease true.

1. 2. Review warnings or errors in the console output and WASPreUpgrade logs.
      

      After the WASPreUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the WASPreUpgrade.old_Profile.timestamp.log and WASPreUpgrade.trace log files for any warnings or errors.
      
      If there are errors, fix the errors and run the WASPreUpgrade command again. Check whether the warnings affect any other migration or runtime activities on Version 9.0.
      
      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

5. Restore the previous deployment manager configuration that you saved in the migration backup directory by running the WASPostUpgrade command.
   If you use the options that are shown in the following example, all ports are carried forward, and all applications are installed.
   
   For more information, see WASPostUpgrade command.

1. 1. Run the WASPostUpgrade command, specifying the -clone TRUE paramter.
      For example:
      /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90dmgr01 -oldProfile v70dmgr01 -profileName v90dmgr01 -clone TRUE -setPorts generateNew -username myuser -password mypass

It is important to specify the -clone TRUE parameter if you want to continue to use the old profile after it is migrated. If you specify a clone migration for the deployment manager, you must also clone all of its federated nodes. Specifying a clone migration automatically sets -keepDmgrEnabled to true.
      
      When you create profiles, only one profile is considered the default profile per installation.
      You can identify the default profiles by looking in the profileRegistry.xml file in the WAS_HOME/properties directory. The source profileRegistry.xml is copied to the migration backup directory as part of the WASPreUpgrade command.
      

      Avoid trouble
      Always specify the -oldProfile and -profileName parameters when you run the WASPostUpgrade command.

1. 2. Review warnings or errors in the console output and WASPostUpgradeAfter the WASPostUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the migration_backup_dir/logs/WASPostUpgrade.target_profile_name.timestamp.log and migration_backup_dir/logs/WASPostUpgrade.target_profile_name.trace log files for any warnings or errors. If there are errors, fix the errors and run the WASPostUpgrade command again. Check whether the warnings affect any other migration or runtime activities on Version 9.0.
      
      If the configuration was migrated correctly but any applications were not installed, you can run the WASMigrationAppInstaller command to install only the applications that were not migrated. For more information, see WASMigrationAppInstaller command.
      
      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

6. Back up the Version 9.0 deployment manager configuration to a file by running the backupConfig command on the Version 9.0 deployment manager.
   

   Avoid trouble
   This is an important step in the cell migration plan. If there are any node migration failures, you can restore the cell configuration to the point before the failure, apply remedial actions, and attempt the node migration again.

1. 1. Change to the deployment_manager_profile_root/bin directory
   2. Run the backupConfig command with the appropriate parameters.
      For example:
      /opt/WebSphereV90/profiles/V90dmgr01/bin/backupConfig.sh /mybackupdir/ v70toV90dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass

7. Start the Version 9.0 deployment manager.
   1. Change to the new Version 9.0 deployment manager profile bin directory.
   2. Run the startManager command.
      /opt/WebSphereV90/profiles/v70toV90dmgr01/bin/startManager.sh

1. 3. While the deployment manager is running, check the SystemOut.log file for warnings or errors.
      

      Note
      This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

8. For Compute Grid or Feature Pack for Modern Batch, verify that the job scheduler was migrated correctly and that you can dispatch jobs to the previous version servers that host your batch applications.
   To verify the job scheduler migration, after the deployment manager restarts, access the job management console through a web browser.
   
   To verify that the previous version servers that host your batch applications work correctly:

1. 1. Verify that the batch applications on the migrated server or cluster are started. Examine the server or cluster logs for any errors.
   2. Verify that you can dispatch batch jobs to the migrated server by submitting a job from the migrated job scheduler server. You can submit the job by using the Job Management Console, the WSGrid utility, the EJB interface, or the web services interface.

9. Migrate application client installations.
   Migrate client resources to Version 9.0-level resources.

1. 1. Install the WebSphere Version 9.0 application client.
      For more information, see the installation documentation.

1. 2. Run the Version 9.0 WASPreUpgrade command to save the application client security settings to a migration backup directory.
      For example:
      /opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup/v70clientToV90 /opt/AppClientV70

1. 3. Run the Version 9.0 WASPostUpgrade command to restore the application client security settings to the new Version 9.0 client.
      For example:
      /opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup/v70clientToV90

10. Migrate nodes.
    Use the migration tools to migrate the previous versions of the nodes in the configuration to Version 9.0. Perform the following procedure for each node that you plan to migrate to Version 9.0.
    

    Avoid trouble
    You must use the same source node name but a different temporary cell name for each node that you migrate to Version 9.0.

1. 1. Ensure that the Version 9.0 deployment manager is running.
   2. Create the target node profile. Run the manageprofiles command with the appropriate parameters to create a new managed profile.
      For example:
      /opt/WebSphereV90/bin/manageprofiles.sh -create -profileName node1 -templatePath /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name -cellName tempCellName -hostName mynode1host.company.com

      Avoid trouble
      The Version 9.0 nodeName must match the previous Version 7.0 or later nodeName. If the Version 9.0 deployment manager nodeName is different, the migration will fail.

1. 3. Run the WASPreUpgrade command to save the current node configuration information to a migration backup directory. Specify a new directory for the backup files, the installation root directory, and the node profile.
      For example:
      /opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90node1 /opt/WebSphereV70 -oldProfile 70node1

1. 4. Review warnings or errors in the console output and WASPreUpgrade logs.
      Check the WASPreUpgrade console output for the following messages: Failed with errors or Completed with warnings.
      
      Look in the following logs for warnings or errors:
      - migration_backup_dir/logs/WASPreUpgrade.old_profile.timestamp.log
      - migration_backup_dir/logs/WASPreUpgrade.trace
      
      If the WASPreUpgrade command completed with Success, then checking the logs for errors or warnings is not necessary.

1. 5. Run the WASPostUpgrade command to restore the saved node configuration into the new Version 9.0 managed profile. Specify the -clone TRUE parameter, the -newDmgrHostname parameter, and at least one of the -newDmgrSoapPort or -newDmgrRmiPort parameters, filling in the appropriate values. Do not clone federated nodes unless the deployment manager was also cloned.
      For example:
      /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90node1 -profileName node1 -oldProfile 70node1 -username myuser -password mypass -clone TRUE -newDmgrHostname myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879 -setPorts generateNew

1. 6. Review warnings or errors in the console output and WASPostUpgrade
      Check the WASPostUpgrade console output for the messages Failed with errors or Completed with warnings.
      Look in the following logs for errors or warnings:
      - migration_backup_dir/logs/WASPostUpgrade.target_profile.timestamp.log
      - migration_backup_dir/logs/WASPostUpgrade.target_profile.trace
      

      Note
      If the WASPostUpgrade command fails, you might have to restore the Version 9.0 deployment manager from the backupConfig file. If the WASPostUpgrade processing ran the syncNode command, the deployment manager is aware that the node was migrated. The node cannot be migrated again until the deployment manager is restored to the state before the node migration.

      If the configuration was migrated correctly but any applications were not installed, you can run the WASMigrationAppInstaller command to install only the applications that were not migrated. For more information, see WASMigrationAppInstaller command.
      
      If the command completed with Success, then checking the logs for errors or warnings is not necessary.

1. 7. Check the Version 9.0 deployment manager SystemOut.log file for warnings or errors.
      

      Note
      This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. You can also use HPEL in conjunction with your native z/OS logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

1. 8. Start the migrated Version 9.0 node agent.
      /opt/WebSphereV90/profiles/v70toV90node1/bin/startNode.sh -profileName currentNode1Name

1. 9. Check the Version 9.0 deployment manager and node SystemOut.log file for warnings or errors.
   10. Synchronize the cell.
   11. Stop all the application servers on the Version 9.0 migrated node.
   12. Start the appropriate application servers on the Version 9.0 migrated node.
   13. For Compute Grid or Feature Pack for Modern Batch, verify that the job scheduler was migrated correctly and that you can dispatch jobs to the migrated servers that host your batch applications.
       To verify the job scheduler migration, after the migrated application servers or clusters restart, access the job management console through a web browser.
       
       To verify that the Version 9.0 servers that host your batch applications work correctly:

1. 1. 1. Verify that the batch applications on the migrated server or cluster are started. Examine the server or cluster logs for any errors.
      2. Verify that you can dispatch batch jobs to the migrated server by submitting a job from the migrated job scheduler server. You can submit the job by using the Job Management Console, the WSGrid utility, the EJB interface, or the web services interface.

1. 14. Save the Version 9.0 profile configuration to a file by running the backupConfig command with the appropriate parameters.
       For example:
       /opt/WebSphereV90/profiles/node1/bin/backupConfig.sh /mybackupdir/ v70toV90node1.zip -username myuser -password mypass -nostop

Each time that you run the backupConfig command, use a new backup file name.

1. 15. Save the deployment manager configuration to a file by running the backupConfig command with the appropriate parameters.Before you run the command, change to the deployment_manager_profile_root/bin directory on the Version 9.0 deployment manager host.
       

       Note
       For each node migrated, back up the Version 9.0 deployment manager configuration to a new backup file.

       For example:
       /opt/WebSphereV90/profiles/v70toV90dmgr01/bin/backupConfig.sh /mybackupdir/ v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass

       Note
       If you are migrating a node to a different host, refer to the information about migrating nodes in Migrating cells to new host machines using the command-line tool.

11. Migrate plug-ins for web servers.
    The product supports several different web servers, as described in the system requirements. For installation information, see the documentation for your web server type and version.

1. 1. Ensure that the Version 9.0 deployment manager is running.
   2. Update the version of the web server plug-in that is used in the cell.
   3. For all application servers in the cell that you want to be served by the web server, create a new web server definition for web server plug-in.For more information about creating web server definitions, see Implementing a web server plug-in.
      
      
      

---

Clone migrating cells to new host machines using the command-line tool

You can migrate cell configurations from a previous version of WebSphere® Application Server that is hosted on one machine to an instance of WebSphere Application Server Version 9.0 that is hosted on a different machine. The source and target host machines do not need to run the same operating system.

Before you begin

Supported configurations
This topic is about profile configuration migration. To migrate your applications to the latest version, use the WebSphere Application Server Migration Toolkit.

Review the migration planning information. See Knowledge Collection: Migration planning for WebSphere Application Server.

Tip
Rather than specifying individual parameters on migration commands, you can specify the -properties file_name.properties parameter to input a properties file. For more information, see Defining your migration through properties.

This information describes migrating cells to a different machine. For information on migrating cells on the same machine, see Migrating cells using the command line tools.

About this task

This task describes how to migrate each profile in a cell configuration from a previous version of WebSphere Application Server to WebSphere Application Server Version 9.0 hosted on a different machine. The cell configuration consists of a deployment manager with one or more nodes, a web server, and an application client. All ports are migrated forward into the new configuration.

If WebSphere Application Server Version 9.0 is not installed on the source host machine, you must generate a remote migration .jar file on the target host machine that matches the operating system of the source machine. The remote migration .jar file provides the source host with the Version 9.0 WASPreUpgrade tool, which you use to create the migration backup directory for the profile.

The WASPreUpgrade command must be run from the target WebSphere Application Server release. The source machine will not have the new version of the WASPreUpgrade command. You must do one of the following actions:

- OPTION 1: Install the target product version on the source machine
- OPTION 2: Create the remote migration .jar file (which is really the WASPreUpgrade command and files needed to support running, including Java, collected from the target installation).
Once you have the remote migration .jar file, you can run it on the source machine.

Note
This OPTION 2 is easier as a full install is not needed. Once the archive is created it can be used for many source machines. However, if the target and source machines are on different operating system architectures, then option 1 is required since the remote migration archive is operating system architecture specific.
When the multiple source machines all have the same operating system architectures but different from the target machine, then only one source machine needs to have the target release installed. From that one source machine, the remote migration jar can be created and used on the other source machines.

This procedure assumes that the previous configuration is running and that you are migrating all profiles to a different host machine.

Avoid trouble
Ensure that your setting for the maximum number of open files is 10000 or greater. If the number of open files is too low, this can cause a variety of migration failures.

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.

Restriction
Remote migration from IBM® i or z/OS is not supported.

Procedure

1. Back up the deployment manager and all old nodes.In case of failure during the migration, save the current deployment manager and node configuration to a file that you can use later for recovery purposes.
   1. Change to the deployment_manager_profile_root/bin directory.
   2. Run the backupConfig command with the appropriate parameters and save the current profile configuration to a file.
      For example:
      [Windows]
      previous_version_app_server_root\v70dmgr01\bin\ backupConfig.bat \mybackup_old_host\v70dmgr01backupBeforeV90migration.zip -username myuser -password mypass -nostop
      
      [Linus|AIX|Solaris|HP-US]
      previous_version_app_server_root/v70dmgr01/bin/backupConfig.sh /mybackup_old_host/v70dmgr01backupBeforeV90migration.zip -username myuser -password mypass -nostop
      
      where mybackup_old_host is the location where the configuration restore points are stored.

1. 3. For each node in the configuration, change to the node_profile_root/bin directory.
   4. Run the backupConfig command with the appropriate parameters and save the current profile configuration to a file.
      For example:
      [Windows]
      previous_version_app_server_root\v70node01\bin\backupConfig.bat \mybackup_old_host\v70node01backupBeforeV90migration.zip -username myuser -password mypass -nostop
      
      [Linus|AIX|Solaris|HP-US]
      previous_version_app_server_root/v70node01 /bin/backupConfig.sh /mybackup_old_host/v70node01rbackupBeforeV90migration.zip -username myuser -password mypass -nostop

2. Install WebSphere Application Server Network Deployment Version 9.0 onto each target host in a new directory.
   For more information, see the installation documentation.

3. Create the remote migration .jar file.This .jar file.
   The contains the files necessary to run the WASPreUpgrade command on a system which does not have WebSphere Application Server Version 9.0 installed.
   

   Avoid trouble
   You must create the remote migration JAR file on the same operating system and architecture as you installed the source. Because the archive that is generated contains operating system specific code, it runs only on this architecture.
   If the operating system or architecture differs between the source and target systems, you can create the remote migration JAR file without specifying the -includeJava option. Set the JAVA_HOME environment variable to a compatible Java™ version 7 or later installation on the source system prior to running the WASPreUpgrade command. If you want to use the -includeJava option, you must create the remote migration JAR file on the same operating system and architecture as you installed the source.

1. 1. 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 you must install WebSphere Application Server Version 9.0 on a system that matches the source profile before creating the remote migration jar. Once you have generated the remote migration jar, it will work on any system which matches the operating system and architecture.
   2. Create the remote migration .jar.
      1. In the command prompt, enter: cd $WAS_HOME/bin/migration/bin
      2. To create the .jar file, run: createRemoteMigrJar.bat(sh) -targetDir <dir_for_the_remote_migration_jar>. This creates the following file: WAS_V90_OS.archjar. For example: WAS_V90_windows.amd64_RemoteMigrSupport.jar
   3. Prepare the remote system for the WASPreUpgrade
      
      1. Send the .jar file to the system where your source profile resides.
      2. Extract the file to a temporary location.
      3. Change directories to the bin directory in the temporary location.
         You are now ready to run the WASPreUpgrade command against the source profile. However, do not issue this command until you are told to do so in a later step.

4. Create the target deployment manager profile.
   The target deployment manager profile is a new deployment manager profile that is the target of the migration.
   

   Avoid trouble
   The Version 9.0 cell and node names must match the cell and node names in the previous configuration. If you create cells and nodes with new cell and node names, then the migration will fail.

   To create a deployment manager profile, run the manageprofiles command with the appropriate parameters.
   For example:
   [Windows]
   version_9_install_root\bin\manageprofiles.bat -create -profileName v70toV90dmgr01 -templatePath app_server_root\profileTemplates\ management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName -hostName mydmgrhost.company.com
   
   [Linus|AIX|Solaris|HP-US]
   version_9_install_root/bin/manageprofiles.sh -create -profileName v70toV90dmgr01 -templatePath /opt/WebSphereV90/profileTemplates/ management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName -hostName mydmgrhost.company.com

5. Save the current deployment manager configuration to the migration backup directory.To save the current deployment manager configuration to the migration backup directory, run the WASPreUpgrade The WASPreUpgrade command does not change the old configuration.
   1. Run the WASPreUpgrade command with the -machineChange true parameter to save the current deployment manager configuration to a migration backup directory.
      For example:
      [Windows]
      <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90dmgr01 app_server_root -oldProfile 70dmgr01 -machineChange true
      
      [Linus|AIX|Solaris|HP-US]
      <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90dmgr01 /opt/WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      
      where mybackup_old_host is the directory to which the profile configuration files are copied in preparation for the migration to the new host.
      If you are migrating from Version 8.0 to Version 9.0 and your profile is a deployment manager, Version 8.0 profile is stopped when WASPreUpgrade runs. The deployment manager is only started before WASPreUpgrade completes if you provide -keepDmgrEnabled true on the command line or specify the corresponding option in the Migration wizard.
      

      Avoid trouble
      If you specify -machineChange true, you must update the job manager URL for all resources (such as other deployment managers or application servers) that are managed by the job manager function of the Version 8.0 deployment manager after the migration.

1. • Review warnings or errors in the console output and WASPreUpgrade logs.
     After the WASPreUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the following log files for any warnings or errors:
     - mybackup_old_host/v70toV90dmgr01/logs/WASPreMigrationSummary.log
     - mybackup_old_host/v70toV90dmgr01/logs/WASPreUpgrade.timestamp.log
     - mybackup_old_host/v70toV90dmgr01/logs/WASPreUpgrade.trace
     
     If there are errors, fix the errors and run the WASPreUpgrade command again. Check whether the warnings affect any other migration or runtime activities on Version 9.0.
     
     If the command completed successfully, it is not necessary to check the logs for errors or warnings.

6. Archive the backup directory created by the WASPreUpgrade command.
   

   Avoid trouble
   Do not use the Windows archive tool because it is not compatible with a WebSphere Application Server migration.

1. 1. Use the archive tool of your choice to create a compressed file of the backup directory.
      For example:
      cd /mybackup_old_host /opt/WebSphereV70/java/bin/jar -cf v70toV90dmgr01.jar v70toV90dmgr01/

1. 2. Move the archived file to the target machine.
   3. Create a directory on the target machine and extract the archived file to the new directory.
      For example:
      mkdir /mybackup_new_host cd /mybackup_new_host /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar

where mybackup_new_host is the directory to which you are migrating your files.

7. Restore the previous deployment manager configuration.
   Run the WASPostUpgrade command from the new deployment manager profile bin directory to restore the previous deployment manager configuration that you saved in the migration backup directory. If you use the options shown in the example, all ports are carried forward, and all applications are installed.

1. 1. Run the WASPostUpgrade command to restore the saved deployment manager configuration into the new Version 9.0 deployment manager profile.
      For example:
      [Windows]
      version_9_install_root\bin\WASPostUpgrade.bat \ mybackup_new_host\v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile 70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE -keepDmgrEnabled TRUE -clone TRUE -username myuser -password mypass
      
      [Linus|AIX|Solaris|HP-US]
      version_9_install_root/bin/WASPostUpgrade.sh / mybackup_new_host/v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile 70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE -keepDmgrEnabled TRUE -clone TRUE -username myuser -password mypass
      
      where mybackup_new_host is the directory from which the source profile configuration files are migrated.
      If you want to continue to use the old profile after it is migrated, specify the -clone TRUE parameter. If you specify a clone migration for the deployment manager, you must also clone all of its federated nodes.

1. 2. Review warnings or errors in the console output and WASPostUpgrade logs.
      After the WASPostUpgrade command is complete, check the console output for Failed with errors or Completed with warnings Then, check the following log files for any warnings or errors:
      - mybackup_new_host/v70toV90dmgr01/logs/WASPostMigrationSummary.log
      - mybackup_new_host/v70toV90dmgr01/logs/WASPostUpgrade.target profile name.timestamp.log
      - mybackup_new_host/v70toV90dmgr01/logs/WASPostUpgrade.target profile name.trace
      
      If there are errors, fix the errors and run the WASPostUpgrade command again. Check whether the warnings affect any other migration or runtime activities on Version 9.0.
      
      If the configuration was migrated correctly but any applications were not installed, you can run the WASMigrationAppInstaller command to install only the applications that were not migrated. For more information, see WASMigrationAppInstaller command.
      
      If the command completed successfully, it is not necessary to check the logs for errors or warnings.
      

      Avoid trouble
      After the WASPostUpgrade command completes successfully, do not start the new deployment manager. You must complete a few more steps before starting the new deployment manager.

8. Save the Version 9.0 migrated deployment manager configuration to a file by running the backupConfig command on the Version 9.0 deployment manager.
   

   Avoid trouble
   If you encounter a node migration failure, you can restore the cell configuration to the point before the failure. You can apply remedial actions and the attempt the node migration again.

1. 1. Change to the deployment_manager_profile_root/bin directory
   2. Run the backupConfig command with the appropriate parameters and save the Version 9.0 profile configuration to a file.
      For example:
      [Windows]
      version_9_profile_root\profiles\v70toV90dmgr01\ bin\backupConfig.bat \mybackup_new_host\v70toV90dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass
      
      [Linus|AIX|Solaris|HP-US]
      version_9_profile_root/profiles/v70toV90dmgr01/bin/backupConfig.sh / mybackup_new_host/v70toV90dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass
      
      where mybackup_new_host is the location where the configuration restore points are stored.

9. Start the Version 9.0 deployment manager on the new host.
   1. Change to the new Version 9.0 deployment_manager_profile_root/bin directory.
   2. Run the startManager
   3. While the deployment manager is running, check the SystemOut.log file for warnings or errors.
      

      Note
      This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. You can also use HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

      Check the warnings to see if they affect any node migration or runtime activities when the Version 9.0 deployment manager is started.

1. 4. Ensure that the Version 9.0 deployment manager starts successfully.

10. Migrate application client installations.
    If the source WebSphere Application client is Version 7.0, you also must run the WASPreUpgrade and WASPostUpgrade commands to migrate the existing security settings.

1. 1. Identify all client hosts that you must migrate.
   2. Install the WebSphere Version 9.0 application client.
   3. Run the Version 9.0 WASPreUpgrade command to save the Application client security settings to a migration backup directory.
      For example:
      /opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup_client/v70clientToV90 /opt/AppClientV70

1. 4. Run the Version 9.0 WASPostUpgrade command to restore the Application client security settings to the new Version 9.0 client.
      For example:
      /opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup_client/v70clientToV90

11. Migrate nodes.
    

    Important
    These steps apply to cross-machine migrations only. If you are not completing a cross-machine migration of a node, see the information about migrating nodes in Migrating cells using the command-line tools. Ensure that the Version 9.0 deployment manager is running. For each node that you plan to migrate to Version 9.0, perform the following steps.

    Avoid trouble
    For the migration to be successful, you must use the same source node name but a different temporary cell name for each node that you migrate to Version 9.0 or later.

1. 1. Install WebSphere Application Server Version 9.0 onto each target host.For more information, see the documentation about installing an application-serving environment.
   2. Create the target node profile. Run the manageprofiles command with the appropriate parameters to create a new managed profile.
      For example:
      [Windows]
      version_9_install_root\bin\manageprofiles.bat -create -profileName node1 -templatePath \opt\ WebSphereV90\profileTemplates\managed -nodeName currentNode1Name -cellName tempCellName -hostName mynode1host.company.com
      
      [Linus|AIX|Solaris|HP-US]
      version_9_install_root/bin/manageprofiles.sh -create -profileName node1 -templatePath /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name -cellName tempCellName -hostName mynode1host.company.com

1. 3. Use the remote migration .jar file that you created for migrating the deployment manager to make the WASPreUpgrade command available on the current node machine.
      

      Note
      This step needs be done only if the source node and deployment manager are not on the same machine, and this step can be done only if the machine architecture is the same.

      For more information, see step 3 of this scenario, Create the remote migration .jar file.

1. 4. Run the WASPreUpgrade command with the -machineChange true parameter to save the current node configuration to a migration backup directory. Choose a new directory for the backup files.
      For example:
      [Windows]
      <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90node1 \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
      
      [Linus|AIX|Solaris|HP-US]
      <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90node1 /opt/WebSphereV70 -oldProfile 70node1 -machineChange true

1. 5. Check the WASPreUpgrade console output for error and warning messages.You might find the following messages: Failed with errors or Completed with warnings. Also, look in the following log files for error or warning messages:
      • myback_old_host/v70toV90node1/logs/WASPreMigrationSummary.log
      • myback_old_host/v70toV90node1/logs/WASPreUpgrade.timestamp.log
      • myback_old_host/v70toV90node1/logs/WASPreUpgrade.trace
        
        If the WASPreUpgrade command is successful, you do not need to check the log files for error or warning messages.

1. 6. Use the archive tool of your choice to create a compressed file of the backup directory that was created by the WASPreUpgrade command.
      For example:
      cd /mybackup_old_host /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/

1. 7. Move the archived file to the target machine.
   8. Create a directory on the target machine and extract the archived file to the new directory.
      For example:
      mkdir /mybackup_new_host cd /mybackup_new_host /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      
      where mybackup_new_host is the directory from which the profile configuration files are migrated.

1. 9. Run the WASPostUpgrade command to restore the saved node configuration into the new Version 9.0 managed profile. If you cloned the deployment manager, you must also clone all federated nodes. Specify the -clone TRUE parameter and the new deployment manager host name and SOAP or RMI port. Do not clone federated nodes unless the deployment manager was cloned.
      For example:
      [Windows]
      version_9_install_root\bin\WASPostUpgrade.bat \ mybackup_new_host\v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -username myuser -password mypass -clone TRUE -newDmgrHostname myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
      
      [Linus|AIX|Solaris|HP-US]
      version_9_install_root/bin/WASPostUpgrade.sh / mybackup_new_host/v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -username myuser -password mypass -clone TRUE -newDmgrHostname myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879

1. 10. Check the WASPostUpgrade console output for the following messages.
       You might find the following messages: Failed with errors or Completed with warnings. Also, look in the following log files for errors or warning messages:
       - mybackup_new_host/v70toV90node1/logs/WASPostMigrationSummary.log
       - mybackup_new_host/v70toV90node1/logs/WASPostUpgrade.target_profile_name.timestamp.log
       - mybackup_new_host/v70toV90node1/logs/WASPostUpgrade.target_profile_name.trace
       

       Note
       If the WASPostUpgrade command fails, you might need to restore the Version 9.0 deployment manager from the backup configuration file. If the WASPostUpgrade command processing ran the syncNode command, then the deployment manager is aware that the node has been migrated. The node cannot be migrated again until the deployment manager has been restored to the state before the node migration.

       If the configuration was migrated correctly but any applications were not installed, you can run the WASMigrationAppInstaller command to install only the applications that were not migrated. For more information, see WASMigrationAppInstaller command.

1. 11. Check the Version 9.0 deployment manager SystemOut.log file for error or warning messages.
       

       Note
       This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. You can also use HPEL in conjunction with your native z/OS logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

1. 12. Start the migrated Version 9.0 node agent.
   13. Check the Version 9.0 deployment manager and node SystemOut.log for error or warning messages.
   14. Optional: Synchronize the cell if the auto-synchronization process is not enabled.
   15. Start the appropriate application servers on Version 9.0 migrated node.
   16. Run the backupConfig command and save the Version 9.0 profile configuration to a file.
       For example:
       [Windows]
       version_9_profile_root\v70toV90node1\bin\backupConfig.bat \mybackup_new_host\v70toV90node1.zip -username myuser -password mypass -nostop
       
       [Linus|AIX|Solaris|HP-US]
       version_9_profile_root/v70toV90node1/bin/backupConfig.sh /mybackup_new_host/v70toV90node1.zip -username myuser -password mypass -nostop
       
       Each time you run the backupConfig command on a specific node, use a new backup file name.

1. 17. Save the deployment manager configuration using the backupConfig command.
       On the Version 9.0 deployment manager host, change to the deployment_manager_profile_root/bin directory. Run the backupConfig command and save the Version 9.0 profile configuration to a file.
       For example:
       [Windows]
       version_9_profile_root\v70toV90dmgr01\bin\backupConfig.bat \mybackup_new_host\v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass
       
       [Linus|AIX|Solaris|HP-US]
       version_9_profile_root/v70toV90dmgr01/bin/backupConfig.sh /mybackup_new_host/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass
       

       Note
       For each node that you migrate, back up the Version 9.0 deployment manager configuration to a new backup file.

1. 18. Repeat the previous steps for additional nodes.

12. Migrate plug-ins for web servers.
    The product supports several different web servers, as described in the system requirements. For installation information, see the documentation for your web server type and version.

1. 1. Ensure that the Version 9.0 deployment manager is running.
   2. Update the version of the web server plug-in that is used in the cell.
   3. For all application servers in the cell that you want to be served by the web server, create a new web server definition for web server plug-in.For more information about creating web server definitions, see Implementing a web server plug-in.

Results

You used the migration tools to migrate the cell configurations from a previous version of WebSphere Application Server to new host machines that run WebSphere Application Server Version 9.0.

---

#WebSphereApplicationServer(WAS)

​​​​