Migrate and coexisting

 

+

Search Tips   |   Advanced Search

 

Overview

Migrating involves collecting the configuration information from a previous release of a WAS product and merging it into a configuration for a new release. Coexisting involves running a new release of a WAS product on the same machine at the same time as you run an earlier release or running two installations of the same release of a WAS product on the same machine at the same time.

See...

The migration tools basically save the existing WebSphere configurations and user applications in a backup directory and then process the contents of this backup directory to migrate the configurations and your applications from previous WAS releases to the latest release.

If you have a previous version of WAS, decide whether to migrate the configuration and applications of the previous version to the new version. Migration does not uninstall the previous version. The earlier release is still functional. If you run the earlier release at the same time as the WAS V6.1 installation, the two versions are coexisting.

To support coexistence, provide non-default port assignments during profile creation. Note that for migration scenarios involving the possibility of rolling back to the previous version, you can choose to have the same port definitions and run either one version or the other.

For help in troubleshooting problems when migrating, see Troubleshooting migration.

For information on migrating to V6.1, see Migrating product configurations. For more information on coexistence among releases, see Coexistence support.

 

Procedure

  1. Prepare to migrate or update product prerequisites and corequisites to supported versions.

  2. Install the WAS V6.1 product.

  3. Migrate your WAS V5.x or Version 6.0.x product configuration to V6.1. You have the choice between migrating the configuration automatically using the migration tools or manually.

    • Use the migration tools to automatically migrate the configuration.

      The following two ND migration scenarios are possible:

      • Automated migration with all-node upgrade

        In this scenario, you use the migration tools to migrate the deployment manager as well as all of its managed nodes. There are the following advantages and considerations with this approach:

        • Advantages

          • You copy the old configuration automatically.

            This includes all resource definitions, virtual host definitions, security settings, cluster definitions, and so forth.

          • You recreate the same exact V5.x or 6.0.x configuration in Version 6.1, including the node definitions, server definitions, and deployed applications by default.

          • You can have a mixed-node configuration.

          • You can enable support for script compatibility.

        • Considerations

          • You should have a good idea of how long it will take to migrate the configuration before you begin.

          • You should migrate within a maintenance window.

      • Automated migration with mixed-node utilizationThis scenario involves the following activities:

        • You use the migration tools to migrate the deployment manager only.

        • You add V6.1 nodes.

        • You move your applications to V6.1 as they are tested on Version 6.1.

        • You remove a V5.x or 6.0.x cell when it is no longer needed.

        There are the following advantages and considerations with this approach:

        • Advantages

          • You copy the old configuration automatically.

            This includes all resource definitions, virtual host definitions, security settings, cluster definitions, and so forth.

          • You recreate the same exact V5.x or 6.0.x configuration in Version 6.1, including the node definitions, server definitions, and deployed applications by default.

          • You can have a mixed-node configuration.

          • You can enable support for script compatibility.

          • You can move applications iteratively.

        • Considerations

          • You should have a good idea of how long it will take to migrate the configuration before you begin.

          • You should migrate within a maintenance window.

    • Manually migrate the configuration...

      • You start with a clean slate and build up a new environment for Version 6.1.

      • Ideally, you would use an existing set of administration scripts to set up the complete V6.1 environment.

      • You move your applications to V6.1 as they are tested on Version 6.1.

      • You remove a V5.x or 6.0.x cell when it is no longer needed.

      Consider the following points related to manually migrating the configuration:

      • Advantages

        • You can reuse the scripts for maintenance, replication, and disaster recovery.

        • You can refactor the topology if you desire.

      • Considerations

        • A complete set of administration scripts is a significant investment.

        • You must address script incompatibilities and changes before you migrate.

        • You cannot have a mixed-node configuration.

  4. Set up multiple versions of WAS to coexist.

    No runtime conflicts can exist for multiple instances and versions of WAS to run at the same time on the same machine. Potential conflicts can occur with your port assignments.

    1. Run V5.x or 6.0.x and V6.1 together
    2. Run two concurrent V6.1 profiles
    3. Create more than one V6.1 profile on the same machine

Overview of migration, coexistence, and interoperability
Premigration considerations
API and specification migration
Programming model extension migration

 

Related tasks

Migrating Web server configurations
Creating profiles through the graphical user interface
Task overview: Installing

 

Related Reference

Port number settings in WAS versions