Premigration considerations
Before you begin the process of migrating to WebSphere® Application Server Version 8.5, there are some considerations of which you need to be aware.
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.
Considerations for AIX®, HP-UX, IBM i, Linux®, Solaris, and Windows operating systems
Consider the following information before you migrate Application Server:- After you install WebSphere Application Server Version 8.5, you might want to
build a complete WebSphere Application Server Network Deployment cell
configuration and verify that it works correctly before you attempt
to migrate an existing cell or node.
This process ensures that your system has all of the necessary prerequisites and supports the new level of WebSphere Application Server.
- Before you perform the migration, evaluate the items deprecated
in WebSphere Application Server Version 8.5.
For more information, see Deprecated, stabilized, superseded, and removed features.
- High-availability manager (HAM) and core-group functionality are included in WebSphere Application Server Version 6.1 and later.
See Core group migration considerations for core-group configuration and topology considerations that might impact your migration from Version 6.1 or later to Version 8.5.
Note: In most cases the recommended number of servers in a core group should not exceed 50. You receive a warning message when the migration tools add a server that exceeds the recommended limit. - Before you migrate to Java™ Standard Edition (SE)
Development Kit (JDK) 6 from JDK 5 or JDK 1.4 , review your applications for necessary changes based
on the Java specification. IBM®
WebSphere SDK Java
Technology Edition Version 6.0 is installed by default with WebSphere Application Server
Version 8.5. Optionally, you can use the Installation Manager
to install IBM
WebSphere SDK Java
Technology Edition Version 7.0. Avoid trouble: Do not enable SDK Java Technology Edition Version 7.0 unless all nodes are migrated to Version 8.5 and all nodes are also upgraded to SDK Java Technology Edition Version 7.0. Using SDK Java Technology Edition Version 6.0 and Version 7.0 in the same cell can result in application deployment incompatibilities.
See Migrating API and specifications for more information.
- When migrating a cell with multiple nodes, the applications must remain at the lowest JDK level until all nodes are migrated.
- The migration articles in this documentation assume that WebSphere Application Server Version 8.5 is being installed
in an environment where it must coexist with previous versions of WebSphere Application Server. Consider the following items when planning to enable coexistence:
- Update prerequisites to the levels required by WebSphere Application Server Version 8.5.
Previous versions of WebSphere Application Server continue to run at the higher prerequisite levels.
- Review the ports that have been defined to ensure that the WebSphere Application Server Version 8.5 installation does
not conflict.
See Port number settings for default port information.
See Running multiple application server versions for more information.
- Update prerequisites to the levels required by WebSphere Application Server Version 8.5.
- Consider the following information if you are
planning to have any mixed-release cells:
- You can upgrade a portion of the nodes in a cell to WebSphere Application Server Version 8.5 while leaving others
at the previous release level. This means that, for a period of time,
you might be administering servers that are at the previous release
level and servers that are running the newer release in the same cell.
In this mixed-release environment, some restrictions on what you can do with servers at the previous release level might exist. For details, see Creating application servers.
- You can upgrade a portion of the nodes in a cell to WebSphere Application Server Version 8.5 while leaving others
at the previous release level. This means that, for a period of time,
you might be administering servers that are at the previous release
level and servers that are running the newer release in the same cell.
- WebSphere Application Server Version 8.5 migration converts
HTTP transports to channel-framework web container transport chains.For more information on WebSphere Application Server Version 8.5 transport support, see the following information:
- Configuring transport chains
- HTTP transport channel settings
- Transport chains
- The following restrictions apply to a deployment
manager or job manager migration:
- The Version 8.5 cell and node names must match the cell and
node names in the Version 6.1 configuration.
If you create a profile with a different cell name or a different node name, the migration fails.
- The Version 8.5 cell and node names must match the cell and
node names in the Version 6.1 configuration.
- When migrating a federated node, the WebSphere Application Server Version 8.5 cell name and node name must match their respective Version 6.1 or later names.
- If you create a profile that does not meet the migration requirements such as naming requirements, you can remove the previous profile and create a new one rather than uninstalling and reinstalling the WebSphere Application Server Version 8.5 product.
- If you migrate a node to WebSphere Application Server Version 8.5 and then discover that you need to revert to Version 6.1 or later, see Rolling back environments.
- If you have a web services gateway running on a WebSphere Application Server Version 6.1 or later application server that is part of a WebSphere Application Server Network Deployment cell and you want to migrate the cell from a Version 6.1 or later to a Version 8.5 deployment manager, you must first preserve the gateway configuration as described in the coexisting with previous gateway versions article in the Version 6.1 documentation.
- The migration tools create a migration backup directory containing
a backup copy of the configuration from the previous version. The
following guidelines might help you to determine the amount of file-system
space that this directory might require:
- If you are migrating from Version 6.1 or later, the space available for this directory must be at least the size of the configuration directory and applications from the previous profile.
- If you use the migration tools to create more than one Version 8.5 target profile on
the same host or installation instance and you use the default port
settings, there is a chance that the target profiles will share the
same ports for some of the new Version 8.5 port definitions.
This will cause startup problems if both of the migrated profiles
are used. If you are migrating two or more profiles that reside on the same host or installation instance, perform the following actions for each additional target profile:
- Before using the migration tools, use the Profile Management tool or manageprofiles command to create the target profile and make sure that you select unique ports rather than using the default ports.
- When you use the migration tools, select the target profile rather than letting the tools create it.
- The amount of storage that your system requires during migration
to Version 8.5 depends on
your environment as well as on the migration tool that you are using.
- WASPreUpgrade storage requirements
- Location: Backup directory specified as a parameter of the WASPreUpgrade command
- Amount: For an estimate of your storage requirements when using this command, add the following
amounts.
- Size of the following items for all of the profiles in your previous
configuration:
- profile_root/installableApps directory
- profile_root/installedApps directory
- profile_root/config directory
- profile_root/properties directory
- Shared libraries referenced in the libraries.xml configuration files
- Resource adapter archive (RAR) files referenced in the resources.xml configuration files
- If trace is enabled, which is the default, up to 200 MB (depending on the size and complexity of your configuration)
- Size of the following items for all of the profiles in your previous
configuration:
- WASPostUpgrade storage requirements
- For an estimate of your storage requirements when using this command,
add the following amounts.
- Location: New configuration relative to the new profile_root directorySize of the following items for the previous profile that you are migrating:
- profile_root/installableApps directory
- profile_root/installedApps directory
- profile_root/config directory
- profile_root/properties directory
- Shared libraries referenced in the libraries.xml configuration files
- RAR files referenced in the resources.xml configuration files
- Location: Backup directory specified as a parameter of
the WASPreUpgrade and WASPostUpgrade commands
If trace is enabled, which is the default, up to 1 GB (depending on the size and complexity of your configuration)
- Location: New configuration relative to the new profile_root directory
- For an estimate of your storage requirements when using this command,
add the following amounts.
- WASPreUpgrade storage requirements
- If you use isolated data repositories—specifically, nonshared
data repositories such as transaction logs for SIB and Apache Derby
databases—and you migrate from a previous release, your existing
databases and transaction logs are saved when the WASPreUpgrade command
is run. Any database changes that you make after you run the WASPreUpgrade command
are not reflected in the migrated environment.
- If you have mission-critical information that is stored in these local data repositories, you should safely shut down all servers that interact with those repositories before attempting migration. Those servers should remain offline until the migration has been successfully completed or rolled back.
- If you make multiple attempts at migration, either because of unexpected rollback or to apply fixes, rerun the WASPreUpgrade command so that any changes to your isolated data repositories are reflected in the migrated environment.
- Do not migrate a node with active servers if the
SIB uses the file-store option for one or all of the messaging engines.
- The WASPreUpgrade command fails with a file-locked exception when you try to copy the file stores on an active application server.
- The WASPreUpgrade command copies a locked file, which could compromise data consistency.
- If you try to run the WASPreUpgrade command
to migrate from Version 6.1 with the node and application server that
own the SIB file store still running, you might get an error similar
to the following:
If you then shut down the application server and node, the WASPreUpgrade command completes.C:\was80A\bin>WASPreUpgrade c:\bkupWAS6.1.0.17June30B C:\was61B MIGR0385I: Starting to save profile AppSrv01. MIGR0215W: The migration function cannot copy the file and open the destination file c:\bkupWAS6.1.0.17June30B\migrated\C_\FSJune19\Log. MIGR0272E: The migration function cannot complete the command.
- Before you migrate an Apache Derby database, ensure that any application servers hosting applications that are using the Apache Derby database are closed. Otherwise, the Apache Derby migration fails.
- You should be aware of the following rules related to migrating security
domains:
- If you migrate a deployment manager that has a security domain with a cell-level scope, the
migration tools take the following actions:
- Migration creates a domain in the new configuration called PassThroughToGlobalSecurity if it does not already exist.
- Migration adds a cluster mapping to the new configuration for all clusters that existed in the
old configuration.
- Clusters that only existed in the Version 8.5
deployment-manager configuration before migration do not have their mappings to
PassThroughToGlobalSecurity changed.
- If mappings for the Version 8.5 clusters exist before migration, they still exist after migration.
- If no mappings for the Version 8.5 clusters exist before migration, they still do not exist after migration.
- If a cluster exists in both the previous configuration and the Version 8.5 configuration before migration, the cluster in the new configuration is added to the PassThroughToGlobalSecurity domain and behaves like the cluster in the previous release.
- Clusters that only existed in the Version 8.5
deployment-manager configuration before migration do not have their mappings to
PassThroughToGlobalSecurity changed.
- Migration adds a bus mapping for any busses that exist in a migrated Version 6.1.x
configuration.
Bus mappings are updated following the same rules as those for cluster mapping.
- Administrative servers (deployment manager) are not added to the PassThroughToGlobalSecurity domain.
- If you migrate a federated node that has a security domain with a cell-level scope, the
migration tools take the following actions:
- Migration creates a domain in the new configuration called PassThroughToGlobalSecurity if it does not already exist.
- Migration adds a server-level mapping to the PassThroughToGlobalSecurity domain for all
non-clustered servers in the old node's configuration.
- Servers on the node that is being migrated that are part of a cluster do not receive entries in
the PassThroughToGlobalSecurity domain because this was addressed through a cluster mapping during
deployment-manager migration.
If you have removed that mapping, migration maintains that behavior.
- Administrative servers (node agents) are not added to the PassThroughToGlobalSecurity domain.
- Servers on the node that is being migrated that are part of a cluster do not receive entries in
the PassThroughToGlobalSecurity domain because this was addressed through a cluster mapping during
deployment-manager migration.
For more information, see the Security domains in a mixed-version environment section of Multiple security domains.
- If you migrate a deployment manager that has a security domain with a cell-level scope, the
migration tools take the following actions:
- If you updated your java.security file in the previous version of WebSphere Application Server, ensure that your updates are located in the migrated java.security file, which is located in V85WAS_HOME/java/jre/lib/security/java.security.
- The process for disabling credential prompting has changed.
To disable credential prompting in Version 8.5, configure the ipc.client.props to disable credential prompting before migrating from Version 6.1 to Version 8.5.
- During migration, some of your application metadata might be reset
to the default and cause the application to function differently from
what you expect.
If you installed an application in your old environment with Use Metadata From Binaries set to true and during that installation or a future update of the application you made a change to the application's metadata (such as JNDI resource references or database entries for example), the change might be lost when you migrate.
When Use Metadata From Binaries is set to true, the administrative code only updates the metadata in the binary EAR file. This option is not supported in a mixed cell; therefore, it is automatically turned to false as part of migration. When this happens, the expanded metadata in the configuration directories take precedence over the values in the binary EAR file. This causes the values from the original EAR file installation to take precedence over any updates that you might have made.
Perform one of the following actions to resolve this issue:- Before migrating, update your applications in the old environment and set Use Metadata From Binaries to false. Ensure that the applications are functioning correctly with this new setting, and then run the migration.
- After migrating, update your applications and correct the metadata as required to allow the applications to function appropriately.
- After you use the migration tools to migrate to WebSphere Application Server Version 8.5, you might need to
perform some actions that are not done automatically by the migration
tools.
- Examine any Lightweight Third-Party
Authentication (LTPA) security settings that you might have used in WebSphere Application Server Version 6.1 or
later, and verify that Version 8.5 security
is set appropriately.
See Lightweight Third Party Authentication for more information.
- Check the WASPostUpgrade.log file in the logs directory
for details about any JavaServer Pages (JSP) objects that the migration
tools did not migrate.
If Version 8.5 does not support a level for which JSP objects are configured, the migration tools recognize the objects in the output and log them.
- Review your Java Virtual
Machine (JVM) settings to verify that you are using a heap size of
at least 50 for improved startup performance.
See Java virtual machine settings for more information.
If you have used a smaller heap size before, you can use the default heap size of 50.
- Verify the results of the automatic Apache Derby database migration,
and manually migrate any Apache Derby databases that are not automatically
migrated by the tools.
See Migrating Apache Derby databases for more information.
- WebSphere Application Server Version 8.5 does not include
the WebSphere Connect
JDBC driver for SQL Server. The WebSphereConnectJDBCDriverConversion
tool is provided to convert data sources from the WebSphere Connect JDBC driver to the DataDirect
Connect JDBC driver or the Microsoft SQL
Server JDBC driver.
See Migrating from the WebSphere Connect JDBC driver for more information.
- Examine any Lightweight Third-Party
Authentication (LTPA) security settings that you might have used in WebSphere Application Server Version 6.1 or
later, and verify that Version 8.5 security
is set appropriately.