Overview of migration, coexistence, and interoperability

The goal of migration is to reconstruct your earlier version of WebSphere® Application Server in a Version 8.5 environment. Coexistence allows you to create a mixed-version environment that is not in conflict and allows the nodes of all versions to start and run at the same time. Coexistence also facilitates rollback and allows one or the other version to run at one time. Interoperating is exchanging data between two coexisting product installations or between products on different systems.

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 Migration Toolkit.

Supported configurations: These tools are intended for use with the full WebSphere Application Server profile; they are not required or supported for use with the Liberty profile.
[AIX Solaris HP-UX Linux Windows]

Introduction

WebSphere Application Server Version 8.5 can coexist with Version 6.1 or later. Depending on the previous version of WebSphere Application Server, port conflicts might exist that must be resolved. See Coexistence support, Configuring port settings, and Running multiple application server versions for more information.

WebSphere Application Server Version 8.5 migration leverages the existing configuration and applications and changes them to be compatible with the WebSphere Application Server Version 8.5 environment. Existing application components and configuration settings are applied to the Version 8.5 environment during the migration process.

If you use an earlier version of WebSphere Application Server, the system administrator might have fine-tuned various application and server settings for your environment. It is important to have a strategy for migrating these settings with maximum efficiency.

You can perform incremental migration of your WebSphere Application Server Version 6.1 or later configuration by running the migration tools multiple times, each time specifying a different set of profiles.

Incremental migration of your WebSphere Application Server usually involves operating your system in a mixed cell release environment. Migration in this environment involves node migrations at various times and as such, may result in mixed cells running for extended periods of time until migration is complete.

A cell can contain nodes from different WebSphere Application Server versions. A WebSphere Application Server Version 8.5 mixed cell can contain nodes that support WebSphere Application Server Version 8.5 and Version 6.1 or later. A mixed cell environment can exist in two ways:
  1. You perform incremental node migration of your existing system.
    1. You migrate the deployment manager to Version 8.5. The deployment manager has to be at the level of the highest node version. If you have nodes of the previous version, then this migration of the deployment manager creates a mixed cell at the highest version of WebSphere Application Server.
    2. Then when you migrate one node at a time to this new highest version, the cell becomes a cell at the highest version of WebSphere Application Server.
      Note: This cell cannot be at a higher version than the deployment manager.
  2. You migrate the deployment manager to Version 8.5 and then federate older version nodes to the new version deployment manager. This form of migration is supported for only Version 6.1 or later nodes.
    1. First, you migrate the deployment manager to Version 8.5. The deployment manager has to be at the level of the highest node version.
    2. You then can federate nodes from Version 6.1 or later to the new highest deployment manager version.
    Avoid trouble: This method of incremental migration leaves your system in a mixed cell environment with nodes administered by a Version 8.5 deployment manager. Your migration planning should eventually include migrations of all nodes to the Version 8.5 level to ensure consistent administration of the nodes.

Existing functions continue to work in a mixed cell environment. You should be able to perform reasonable operations, such as run existing applications, perform management operations, such as addNode, create mixed cluster, configure the system, call MBeans, and deploy applications. New function support in a mixed cell environment can be decided on a case by case basis - based on function, priority and available resources.

Avoid trouble: When running in a mixed-cell environment, clients might suddenly encounter a situation where the port information about the cluster members of the target cluster has become stale. This situation most commonly occurs when all of the cluster members have dynamic ports and are restarted during a time period when no requests are being sent. The client process in this state will eventually attempt to route to the node agent to receive the new port data for the cluster members, and then use that new port data to route back to the members of the cluster.

If any issues occur that prevent the client from communicating with the node agent, or that prevent the new port data being propagated between the cluster members and the node agent, request failures might occur on the client. In some cases, these failures are temporary. In other cases you need to restart one or more processes to resolve a failure.

To circumvent the client routing problems that might arise in these cases, you can configure static ports on the cluster members. With static ports, the port data does not change as a client process gets information about the cluster members. Even if the cluster members are restarted, or there are communication or data propagation issues between processes, the port data the client holds is still valid. This circumvention does not necessarily solve the underlying communication or data propagation issues, but removes the symptoms of unexpected or uneven client routing decisions.

Migration involves the following main steps:
  1. Test your applications in a non-production WebSphere Application Server Version 8.5 environment, and make any changes to the applications that are necessary to ensure that they run in that environment.
  2. Migrate those applications and your configuration to Version 8.5.

    You can complete this task by using the migration tools that are included with the product.

Use the migration tools to migrate applications and configuration information to the new version as described in Migrating product configurations. Read Migrating product configurations with migration tools for more information.

[AIX Solaris HP-UX Linux Windows]The Migration wizard provides a graphical user interface to the migration tools. The Migration wizard can call the migration tools, or you can run them directly.

Important reference articles for this migration include the following articles:

If you neither migrate nor coexist with an earlier version of WebSphere Application Server, you are choosing to ignore the previous installation and you can run only one version at a time because of conflicting default port assignments. It is possible for both versions to run at the same time without conflict if you use non-default ports in one version. To set up coexistence with WebSphere Application ServerVersion 6.1 or later, ensure that unique ports are selected during profile creation for the Version 8.5 installation. To set up coexistence with an existing installation of Version 8.5, select Install a new copy of the V8.5 Application Server product during installation.

You can resolve conflicting port assignments by specifying port assignments for coexistence during profile creation, by wsadmin scripting, or by using the Servers > Application Servers > server1 > Ports administrative console page to ensure that WebSphere Application Server Version 8.5 can run with an earlier version. For more information about wsadmin scripting, see wsadmin scripting tool.

Coexistence processing changes the following configuration files:
  • virtualhosts.xml[AIX Solaris HP-UX Linux Windows]
    • HTTP transport port
    • IBM® HTTP server port
    • HTTPS transport port
    • HTTP administrative console port
    • HTTPS administrative console secure port
  • serverindex.xml[AIX Solaris HP-UX Linux Windows]
    • Bootstrap address
    • SOAP connector address
    • Data Replication Service (DRS) client address
      Deprecated feature: This port is deprecated and is no longer used in the current version of WebSphere Application Server.
    • Secure Authentication Service (SAS) Secure Sockets Layer (SSL) ServerAuth listener address
    • Common Secure Interoperability Protocol Version 2 (CSIV2) SSL ServerAuth listener address
    • CSIV2 SSL MutualAuth listener address
    • Administrative console port
    • HTTP transport port
    • Distribution and Consistency Services (DCS) unicast address
    • Administrative console secure port
    • HTTP transport secure port
    • Service Integration Bus (SIB) endpoint address
    • SIB endpoint secure address
    • SIB MQ endpoint address
    • SIB MQ endpoint secure address

For more information, see Port number settings.

Consider the following issues in a migration or coexistence scenario:
  • Conflicting context roots when attempting to share the same web server.

    Follow the procedure in Migrating web server configurations to learn how to configure a web server for sharing between WebSphere Application Server versions.

  • [AIX Solaris HP-UX Linux Windows]If your deployment manager is configured to run as non-root, follow the instructions in Migrating non-root configurations to root to change the ownership and file permissions of the deployment manager directories after running the WASPostUpgrade command.

    This task must be completed before you start the WebSphere Application ServerVersion 8.5 deployment manager.

    Read WASPostUpgrade command for more information.

  • [AIX Solaris HP-UX Linux Windows]If your node agent or application server has been configured to run as non-root, follow the instructions in Migrating non-root configurations to root to change the ownership and file permissions of the node directories after running the WASPostUpgrade command.

    This task must be completed before you start the WebSphere Application Server Version 8.5 node agent or application server.

    Read WASPostUpgrade command for more information.