+

Search Tips   |   Advanced Search

Migrate to a v9.0 stand-alone application server

Use the migration tools to migrate from a WebSphere Application Server v7.0 or later stand-alone application server profile to a v9.0 stand-alone application server.

See Overview of migration, coexistence, and interoperability and Migration considerations.

Tip: Before migrating a WAS v7.0 or later stand-alone application server, 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. See backupConfig command. Note the exact name and location of this backed-up configuration.

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.

To migrate a WAS v7.0 or later configuration on one machine to v9.0 on another machine, use the alternate procedure described in Migrate to a v9.0 stand-alone application server on a remote machine.

For transitioning users: The following products previously required separate migration tools but are now migrated as part of the standard migration procedures:

For more information about these changes, see What is new for migration.trns

For help, read Troubleshoot migration.


Tasks

  1. Stop all of the WAS v7.0 or later application servers running on the node.

    Use the stopServer command from the app_server_root/bin directory. See stopServer command for more information.

    (Linux) For example, issue the following commands to stop server1 and server2 on the Linux operating system:

    ./stopServer.sh server1
    ./stopServer.sh server2
    

    If security is enabled, specify the -user and -password parameters on the stopServer command.

    We can migrate a WAS v7.0 or later node without stopping it; however, we must stop the node before we can start the v9.0 node that we are installing. It is not necessary to have the node running to migrate its configuration. The migration tools can retrieve all the configuration data while the node is stopped.

  2. Install WAS v9.0.

    See Install and configure the application serving environment for more information.

  3. Create a WAS v9.0 profile using the Profile Management Tool or the manageprofiles command.

    See Manage profiles using the graphical user interface or manageprofiles command for more information.

  4. Save the configuration for our source installation by running the WASPreUpgrade command, specifying the migration backup directory name and the v7.0 or later installation root directory.
    /opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90server1 /opt/WebSphereV70 
    -oldProfile current70Server
    

    For more information and additional parameters, see WASPreUpgrade command.

    The WASPreUpgrade tool saves from the following directories to the specified directory.

    • bin
    • config
    • installableApps
    • installedApps (or an alternate directory specified by the user)
    • properties

  5. Restore the configuration from your source environment to the v9.0 profile by running the WASPostUpgrade command, specifying the migration backup directory.
    /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90server1 
    -oldProfile current70Server -profileName 90ProfileName -resolvePortConflicts incrementCurrent 
    -backupConfig TRUE -username myuser -password mypass
    

    For more information and additional parameters, see WASPostUpgrade command.

    The WASPostUpgrade tool copies the environment in the backup directory to the WAS v9.0 stand-alone application server installation.

    When migrating a stand-alone application server from v7.0 or later to v9.0, we can choose a stand-alone application server node already registered with an administrative agent as the target of the migration.

  6. 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.

    For Compute Grid or Feature Pack for Modern Batch applications, also verify that the job scheduler was migrated correctly and that we can dispatch jobs to the servers that host your batch applications.

    To verify the job scheduler migration, restart the application server where the job scheduler is configured. After the server restarts, access the job management console through a web browser.

    To verify that the servers that host your batch applications work correctly:

    1. Verify that the batch applications on the migrated server are started. Examine the server logs for any errors.

    2. Verify that we can dispatch batch jobs to the migrated server by submitting a job from the migrated job scheduler server. We can submit the job using the Job Management Console, the WSGrid utility, the EJB interface, or the web services interface.


Related:

  • Install and configure the application serving environment
  • Migrate product configurations
  • Migrate to a v9.0 stand-alone application server on a remote machine
  • Use the migration tools
  • Manage profiles using the graphical user interface
  • WASPreUpgrade command
  • WASPostUpgrade command
  • manageprofiles command
  • stopServer command
  • backupConfig command
  • WASMigrationAppInstaller command