Migrating and coexisting application servers

Migrating involves collecting the configuration information from a previous release of a WebSphere® Application Server and merging it into a configuration for a new release. Coexisting involves running a new release of a WebSphere Application Server and an earlier release simultaneously on the same machine.

Before you begin

Supported configurations Supported configurations:

This topic is about configuration migration, such as migrating deployment managers and federated nodes in a network deployment environment. The Application Migration Toolkit for WebSphere Application Server provides support for migrating applications from previous versions of WebSphere Application Server to the latest product version. For information about migrating applications, read more about the Application Migration Toolkit.

sptcfg

Read Overview of migration, coexistence, and interoperability and Premigration considerations. For resources to help you plan and perform your migration, visit Knowledge Collection: Migration planning for WebSphere Application Server.

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 WebSphere Application Server releases to the latest release.

If you have a previous version of WebSphere Application Server, you must 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 deployment manager 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 deployment manager during migration, the earlier release is disabled after migration completes successfully. You 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 Version 6.1 and 8.0 application servers are running on the same machine, they are coexisting.

To support coexistence, you must either use the -portBlock and -replacePorts options when you migrate a profile or you must 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.

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

About this task

For information on migrating to Version 8.0, read Migrating product configurations. For more information on coexistence among releases, read Coexistence support.

Procedure

  1. Update product prerequisites and corequisites to supported versions.

    Refer to the IBM® WebSphere Application Server supported hardware, software, and APIs site for current requirements.

  2. Install the Version 8.0 product.

    Read the "Installing the product and additional software" article in the information center for more information.

  3. Migrate your WebSphere Application Server Version 6.x product configuration to Version 8.0.

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

    • Use the migration tools to automatically migrate your configuration.

      Read Migrating product configurations with migration tools for more information.

      The following two WebSphere Application Server, Network Deployment 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 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 Version 6.x configuration in Version 8.0, including the node definitions, server definitions, and deployed applications by default.
          • You 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 deployment manager only.
        • You add Version 8.0 nodes.
        • You move your applications to Version 8.0 as they are tested on Version 8.0.
        • You remove Version 6.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 Version 6.x configuration in Version 8.0, 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.

            Read WASPostUpgrade command for more information.

          • 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 your configuration.
      Migrating your configuration manually involves the following activities:
      • You start with a clean slate and build up a new environment for Version 8.0.
      • Ideally, you would use an existing set of administration scripts to set up the complete Version 8.0 environment.
      • You move your applications to Version 8.0 as they are tested on Version 8.0.
      • You remove a Version 6.x cell when it is no longer needed.
      Consider the following points related to manually migrating your configuration:
      • Advantages
        • You can reuse the scripts for maintenance, replication, and disaster recovery.
        • You can easily 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. Migrate web server plug-ins as described in Migrating web server configurations.
  5. Optional: Set up multiple versions of WebSphere Application Server to coexist.

    No runtime conflicts can exist for multiple instances and versions of WebSphere Application Server 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 WebSphere Application Server versions for more information.




In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Feb 6, 2014 11:51:09 PM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-dist&topic=tmig_prev
File name: tmig_prev.html