WAS v8.0 > Migration and coexistence > Distributed operating systems > Overview

Migrating and coexisting application servers

Migration involves collecting the configuration information from a previous release of a WAS and merging it into a configuration for a new release. Coexisting involves running a new release of a WAS and an earlier release simultaneously on the same machine.

If we 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.

• For stand-alone application server migrations and for deployment-manager migrations in which you do not choose to disable the previous dmgr during migration, the earlier release is still functional.

• For federated-node migrations and for deployment-manager migrations in which you do choose to disable the previous dmgr during migration, the earlier release is disabled after migration completes successfully. We can re-enable the earlier version using the migrationDisablementReversal.jacl script.

If you run two different versions of the application server at the same time, the two versions are coexisting. For example, if v6.1 and 8.0 application servers are running on the same machine, they are coexisting.

To support coexistence, either use the -portBlock and -replacePorts options when you migrate a profile or resolve port conflicts manually so that the two releases do not attempt to use the same ports. Any ports bound when the first profile starts will prevent the second profile from starting because the port is in use. No port changes are required if only one release of the profile is active at any given time.

You have the choice between migrating the configuration automatically using the migration tools or manually.

Automatically migrate the configuration

Read Migrate product configurations with migration tools for more information.

The following two WAS ND migration scenarios are possible:

• Automated migration with all-node upgrade

  In this scenario, you use the migration tools to migrate the dmgr as well as all of its federated 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 v6.x configuration in v8.0, including the node definitions, server definitions, and deployed applications by default.

    • We can enable support for script compatibility.

      Read WASPostUpgrade command for more information.

  • 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 utilization

  This scenario involves the following activities:

  • You use the migration tools to migrate the dmgr only.

  • You add v8.0 nodes.
  • You move the applications to v8.0 as they are tested on v8.0.
  • You remove v6.x nodes from the cell when they are 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 v6.x configuration in v8.0, including the node definitions, server definitions, and deployed applications by default.

    • We can have a mixed-node configuration.

    • We can enable support for script compatibility.

      Read WASPostUpgrade command for more information.

    • We 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

Migrate the configuration manually involves the following activities:

• You start with a clean slate and build up a new environment for v8.0.
• Ideally, you would use an existing set of administration scripts to set up the complete v8.0 environment.
• You move the applications to v8.0 as they are tested on v8.0.
• You remove a v6.x cell when it is no longer needed.

Consider the following points related to manually migrating the configuration:

• Advantages
  • We can reuse the scripts for maintenance, replication, and disaster recovery.
  • We can easily refactor the topology if you desire.

• Considerations
  • A complete set of administration scripts is a significant investment.
  • We must address script incompatibilities and changes before you migrate.
  • We cannot have a mixed-node configuration.

Migrate web server plug-ins as described in Migrate web server configurations.

Optional: Set up multiple versions of WAS to coexist.

No runtime conflicts can exist for multiple instances and versions of WAS if they are going to run at the same time on the same machine. Potential conflicts can occur with your port assignments. Read Port number settings in WAS versions for more information.

• Set up the system to run v6.x and v8.0 together as described in Set up v6.x, v7.0 and v8.0 coexistence.

• Set up the system to run two concurrent v8.0 profiles as described in Set up v8.0 coexistence.

• Create more than one v8.0 profile on the same machine as described in the "Managing profiles using the graphical user interface" article in the information center.

Related

Overview of migration, coexistence, and interoperability
Premigration considerations
Migrate API and specifications
Migrate web server configurations
Install the product and additional software
Manage profiles using the graphical user interface
Port number settings in WAS versions
Knowledge Collection: Migration planning for WAS

+

Search Tips   |   Advanced Search