Overview of migration, coexistence, and interoperability
Introduction
The goal of migration is to reconstruct your earlier version of WAS (WAS) in a nearly identical V6.1 environment. One goal of coexistence is 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; another goal is to create an environment that 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.
WAS V6.1 can coexist with V5.x and V6.0.x. Depending on the previous version of WAS, there might be port conflicts that need to be resolved.
For more information see...
WAS V6.1 migration leverages the existing configuration and applications and changes them to be compatible with the WAS V6.1 environment. Existing application components and configuration settings are applied to the V6.1 environment during the migration process.
If you use an earlier version of WAS, 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 and minimal loss.
You can perform incremental migration of your WAS V5.x or 6.0.x configuration by calling the migration tools multiple times, each time specifying a different set of instances or profiles. Migration involves the following main steps:
- Testing your applications in a non-production WAS V6.1 environment, and making any changes to the applications that are necessary to ensure that they run in that environment.
- Migrating those applications and the configuration to V6.1.
This step can be performed by using the migration tools shipped with the product.
The migration tools migrate applications and configuration information to the new version as described in Migrating product configurations.
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.
The migration from WAS V5.x or 6.0.x to V6.1 is fairly routine.
Important reference articles for this migration include the following articles:
- Create profiles through the graphical user interface or manageprofiles command.
- Migrate servers from multi-broker replication domains to data replication domains
- Comparison of multi-broker versus data replication domains
- Migrate to V3 of the UDDI registry
- Migrate a complete gateway configuration
- Migrate from V5 embedded messaging
- Manage WebSphere V5 JMS use of WebSphere version 6 messaging resources
If you neither migrate nor coexist with an earlier version of WAS, 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 the earlier version. To set up coexistence with WAS V5.x or 6.0.x, ensure that unique ports are selected during profile creation for the V6.1 installation. To set up coexistence with an existing installation of Version 6.1, select the radio button that states "Install a new copy of the V61 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...
Servers | Application Servers | server1 | Ports...on the console page to ensure that WAS V6.1 can run with an earlier version.
Coexistence processing changes the following configuration files:
- virtualhosts.xml
- HTTP Transport Port
- IBM HTTP Server Port
- HTTPS Transport Port
- HTTP Administrative Console Port
- HTTPS Administrative Console Secure Port
- serverindex.xml
- Bootstrap Address
- SOAP Connector Address
- DRS Client Address
- SAS SSL ServerAuth Listener Address (For V6.0.x and previous servers federated in a V6.1 cell)
- CSIV2 SSL ServerAuth Listener Address
- CSIV2 SSL MutualAuth Listener Address
- WC adminhost
- WC defaulthost
- DCS Unicast Address
- WC adminhost secure
- WC default secure
- SIB Endpoint Address
- SIB Endpoint Secure Address
- SIB MQ Endpoint Address
- SIB MQ Endpoint Secure Address
Consider these 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 WAS versions.
- If your deployment manager is configured to run as non-root, follow the instructions in Migrating a previously non-root configuration to root to change the ownership and file permissions of the deployment manager directories after running the WASPostUpgrade command.
This must be done before starting the WAS V6.1 deployment manager.
- If your node agent or appserver has been configured to run as non-root, follow the instructions in Migrating a previously non-root configuration to root to change the ownership and file permissions of the node directories after running the WASPostUpgrade command.
This must be done before starting the WAS V6.1 node agent or appserver.
- A WAS Version 6.1 deployment cell can contain mixed releases of V5.x or 6.0.x nodes, but there is no mixed-node management support for V6.0.0.x and Version 6.0.1.x. The V6.1 migration tools still migrate these nodes during deployment-manager migration, but they issue a warning message that the nodes cannot be managed by the V6.1 deployment manager. You can then do one of the following based on your needs.
- Upgrade all V6.0.0.x and V6.0.1.x nodes to at least Version 6.0.2. This will allow them to be administered by a V6.1 deployment manager.
- Immediately migrate these nodes to V6.1.
Related tasks
Migrate product configurations
Migrate and coexisting