Introduction
WebSphere Application Server Version 7.0 can coexist with
Version 5.1.x and Version 6.x. Depending on the previous version of WebSphere Application Server, port conflicts
might exist that must be resolved. Read Coexistence support and Configuring port settings for
more information.
WebSphere Application Server Version 7.0 migration leverages
the existing configuration and applications and changes them to be
compatible with the WebSphere Application Server Version 7.0 environment. Existing
application components and configuration settings are applied to the Version 7.0 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
5.1.x or Version 6.x configuration by running the migration tools
multiple times, each time specifying a different set of instances
or profiles.
You can perform incremental migration of your WebSphere Application Server Version 5.1.x
or Version 6.x configuration by running the migration tools multiple
times, each time specifying a different set of instances or 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 7.0 mixed cell can contain
nodes that support
WebSphere Application Server Version 7.0, Version 6.x, Version
5.1.x. A mixed cell environment can exist in two ways:
- You perform incremental node migration of your existing system.
- You migrate the deployment manager to Version 7.0. 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.
- 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.
- You migrate the deployment manager to Version 7.0 and then create and
federate older version nodes to the new version deployment manager.
This form of migration is supported for only Version 6.0.2, Version
6.1, and Version 7.0 nodes.
- First, you migrate the deployment manager to Version 7.0. The deployment manager
has to be at the level of the highest node version.
- You then can federate nodes from Version 6.0.2, Version 6.1, and Version 7.0 to the new highest
deployment manager version. Version 5.1.x nodes are not supported
in this form of migration.
Avoid trouble: This method of incremental
migration leaves your system in a mixed cell environment with nodes
administered by a
Version 7.0 deployment
manager. Your migration planning should eventually include migrations
of all nodes to the
Version 7.0 level
to ensure consistent administration of the nodes.
gotcha
Existing functions continue to work in a mixed cell environment.
You should be 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.
Migration
involves the following main steps:
- Test your applications in a non-production WebSphere Application Server Version 7.0 environment, and
make any changes to the applications that are necessary to ensure
that they run in that environment.
- Migrate those applications and your configuration to Version 7.0.
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.
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. Read Migrating product configurations with the migration wizard for
more information.
Important reference articles for this migration
include the following articles:
- Creating profiles using the graphical user interface
- manageprofiles command.
- Migrating servers from multi-broker
replication domains to data replication domains
- Comparison of multi-broker versus data
replication domains
- Migrating to Version 3 of the UDDI
registry
- Migrating a complete gateway configuration
- Migrating from Version 5.1 embedded messaging
- Managing WebSphere Application Server Version
5.1 JMS use of messaging resources in later versions of the product
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
withWebSphere Application Server Version
5.1.x or Version 6.x, ensure that unique ports are selected during
profile creation for the Version 7.0 installation.
To set up coexistence with an existing installation of Version 7.0, select the Install
a new copy of the V70 Application Server product radio button
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 7.0 can run with an earlier
version. Read the "Wsadmin tool" article in the information center
for more information on wsadmin scripting.
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
- Data Replication Service (DRS) client
address
- 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
Read Port number settings in WebSphere Application Server versions for
more information.
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.
- 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 Server Version 7.0 deployment manager.
Read WASPostUpgrade command for more information.
- 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 7.0 node agent or application
server.
Read WASPostUpgrade command for
more information.
- A WebSphere Application Server Version 7.0 WebSphere Application Server, Network Deployment cell can contain
mixed releases of Version 5.1.x or Version 6.x nodes, but there is
no mixed-node management support for Version 6.0.0.x and Version 6.0.1.x.
The
Version 7.0 migration tools still
migrate these nodes during deployment-manager migration, but the tools
issue a warning message that the nodes cannot be managed by the
Version 7.0 deployment manager.
You can then perform one of the following actions based on your needs.