![[V5.1 and later]](../../v51x.gif)
Migration and coexistence overview
WebSphere Application Server contains migration tools that provide migration functionality. The installation wizard can call the migration tools, or you can call them at a later time. The migration tools migrate applications and configuration information to the new version, as described in Migrating and Configuration mapping during migration.
You can also find information about migrating the configuration and the applications from a previous version of WebSphere Application Server to Version 5.0.x in the IBM Redbook, Migrating to WebSphere V5.0: An End-to-End Migration Guide, SG24-6910-00 .
Overview of migrating from release to release
| Migration path | Description |
|---|---|
| V5.0.x to V5.1 | The migration from V5.0.x to V5.1 is routine if there
is no embedded messaging feature and if the node is unfederated. You can use
the installer program to migrate and have little or no post-migration tuning
to perform. When the embedded messaging feature is installed, perform
one of the following tasks:
|
| V4.0.x to V5.1 | The migration tools perform a fairly routine migration from V4 to V5.1. For example, Java 2 Platform, Enterprise Edition (J2EE) 1.2 EAR files in V4 work in V5.1 of WebSphere Application Server, which also supports the J2EE 1.3 specification. Similarly, it is not necessary to redeploy enterprise Java bean (EJB) 1.1 Java archive (JAR) files when moving them from V4 to V5.x, which also supports EJB 2.0 JAR files. |
| V3.5.x to V5.1 | The migration from V3.5 to V5.1 involves significant changes in application structures, development, and deployment. The migration tools assist in this transition by migrating system configurations and creating J2EE artifacts, including mapping previous security settings to J2EE security roles. These security mappings let you access migrated assets during the transition. The migration tools create initial J2EE enterprise applications based on V3.5.x configurations. However, because of the significant changes in the application structures, carefully test and fine tune migrated applications using development and deployment tools. |
You can select from three combinations of migration and coexistence options in the installation wizard or when customizing the response file for silent installation:
- Migrate only
- Coexist only
- Neither migrate nor coexist
If you neither migrate nor coexist with an earlier version of WebSphere Application Server, you are choosing to ignore the previous installation. You can run only one version at a time because of conflicting default port assignments and the potential for conflicting levels of the embedded messaging feature. It is possible that both versions might run at the same time without conflict if you use non-default ports in the earlier version and if they both use the same level of embedded messaging. To resolve conflicting port assignments, the coexistence panel lets you assign ports for V5 to ensure that it can run with an earlier version.
If you use the embedded messaging feature, the earlier version must use the same level of embedded messaging. For example, V5.0.2 the CSD04 level of embedded messaging. V5.0.0 and V5.0.1 use earlier versions. If you want an instance of V5.0.0 or V5.0.1 to coexist with an instance of V5.0.2, upgrade the V5.0.x instance to V5.0.2 by applying Fix Pack 2.
You can specify port assignments for coexistence on the installation wizard coexistence panel, by editing configuration files, by wsadmin scripting, or by using the Servers > Application Servers > server1 > End Points administrative console page.
Migrating and coexisting have roughly opposite goals. The goal of migration is to reconstruct your earlier version in a nearly identical V5.1 environment, including applications, configuration settings, universal resource identifier (URI) descriptors, and Web server context roots. The installation wizard can use the migration tools to migrate the previous configuration and applications. The goal of coexistence is to create an environment that is not in conflict with an earlier version, so far as port settings are concerned. The installation wizard displays a panel where you can set non-conflicting port values that allow the V5.x product to coexist with the earlier version, without port conflicts. This allows both nodes to start and run at the same time. Coexistence processing changes the following configuration files:
- The virtualhosts.xml file:
- HTTP Transport Port
- IBM HTTP Server Port
- HTTPS Transport Port
- HTTP Administrative Console Port
- HTTPS Administrative Console Secure Port
- The serverindex.xml file:
- Bootstrap Port
- SOAP Connector Address
- DRS Client Address
- JMS Server Queued Address
- JMS Server Direct Address
- SAS SSL ServerAuth Address
- CSIV2 ServerAuth Listener Address
- CSIV2 MultiAuth Listener Address
- The server1/server.xml file
- HTTP Transport Port
- HTTPS Transport Port
- HTTP Administrative Console Port
- HTTPS Administrative Console Secure Port
- JMS Server Security Port
See Default coexistence settings for port numbers for more information.
After choosing coexistence, start server1 and use it to change any ports that are in conflict, so that there is no conflict with the earlier version. Then you can run both versions at the same time.
Consider these issues in a migration or coexistence scenario:
- Conflicting context roots when attempting to share the same Web server.
A procedure for configuring a Web server for sharing between WebSphere Application Server versions is described in the information center for the base WebSphere Application Server product.
- Installing WebSphere Application Server multiple times on the same machine.
- Having multiple V5.0.0 or V5.0.1 instances use the embedded messaging feature and attempting to upgrade one instance to V5.0.2, or attempting to install V5.1 with the embedded messaging feature. The service level of the embedded messaging feature for V5.0.0 and V5.0.1 is not compatible with the service level for V5.0.2 or V5.1 (CSD04).
Migrating
Migrating and coexisting