If you have an existing WebSphere® Application Server Network Deployment
configuration with a significant number of large applications and you must meet a specific
maintenance window for migration, you might have some difficulty if you use the standard migration
scenario. In this case, you might want to copy the resources in the configuration tree from a Version 7.0 or later deployment manager configuration to a Version 9.0 deployment-manager management profile but defer adding
applications to the Version 9.0 profile so that you can
continue managing the environment using the Version 7.0 or later
deployment manager.
Before you begin
Supported configurations:
This topic is about profile configuration migration. To migrate your applications
to the latest version, use the WebSphere Application
Server Migration Toolkit.
Tip: To avoid possible connection-timeout problems, modify the connection-timeout value
before running the
WASPostUpgrade command to migrate the federated nodes in a
cell containing many small applications, a few large applications, or one very large application. If
you use a SOAP connector, for example, perform the following actions:
- Go to the following location in the Version 9.0 directory
for the profile to which you are migrating your federated node:
profile_root/properties
- Open the soap.client.props file in that directory and find the value for
the com.ibm.SOAP.requestTimeout property. This is the timeout value in seconds. The default value is
180 seconds.
- Change the value of com.ibm.SOAP.requestTimeout to make it large enough to migrate your
configuration. For example, the following entry would give you a timeout value of a half of an hour:
com.ibm.SOAP.requestTimeout=1800
Note: Select the
smallest timeout value that will meet your needs. Be prepared to wait for at least three times the
timeout that you select—once to download files to the backup directory, once to upload the
migrated files to the deployment manager, and once to synchronize the deployment manager with the
migrated node agent.
- Go to the following location in the backup directory that was created by the
WASPreUpgrade command:
backupDirectory/profiles/profile_name/properties
- Open the soap.client.props file in that directory and find the value for
the com.ibm.SOAP.requestTimeout property:
- Change the value of com.ibm.SOAP.requestTimeout to the same value that you used in the Version 9.0 file.
Read Overview of migration, coexistence, and interoperability and Migration considerations. For resources to help
you plan and perform your migration, visit Knowledge Collection: Migration planning for WebSphere Application Server.
About this task
You can use this strategy to satisfy your specific maintenance-window requirement by building the
full WebSphere Application Server
Version 9.0
WebSphere Application Server Network Deployment configuration in the background while the
existing topology is still running and being managed.
For help in troubleshooting problems when migrating, read Troubleshooting migration.
Procedure
- Make sure that the WebSphere Application Server
Version 7.0 or later deployment manager is running and managing the
existing environment, and make sure that no Version 9.0
deployment manager is running.
This is important in order to prevent two different deployment managers from trying to manage the
same environment.
- Run the WASPreUpgrade command.
- Run the WASPreUpgrade command from the Version 9.0
app_server_root/bin directory.
- Specify the name of the Version 7.0 or later migration backup
directory.
- Specify the name of the Version 7.0 or later
WebSphere Application Server Network Deployment installation.
- Optional: Specify the name of a specific instance or profile to be
migrated from a previous version of WebSphere Application Server.
- Optional: Specify the location of user preferences for the administrative console for one
or more profiles.
For
example:
WASPreUpgrade /WAS6.1_backup_directory /WAS6.1_install_directory
For a full explanation of the WASPreUpgrade command and its parameters, read
WASPreUpgrade command.
- Run the WASPostUpgrade command.
For
example:
WASPostUpgrade /WAS6.1_backup_directory -profileName dmgr_profile_name
-includeApps script -keepDmgrEnabled true
For a full explanation of the WASPostUpgrade command and its parameters, read
WASPostUpgrade command.
At this point, you can exit the maintenance window and still manage the environment using the WebSphere Application Server
Version 7.0 or later deployment manager.
- Customize the administration files.
- Go to the migration backup directory location that contains the generated
administration files.
- Combine and tailor the administration files as needed.
This might include grouping applications together in some administration files or specifying the
installedApplications directory using the installed.ear.destination parameter
.
- Run the wsadmin command to install the applications.
After all applications have been installed, you are ready to start using the WebSphere Application Server
Version 9.0 deployment manager.
- Stop the WebSphere Application Server
Version 7.0 or later deployment manager.
This is important in order to prevent two different deployment managers from trying to manage the
same environment.
You can do this in a number of ways. One easy way is to rename the
serverindex.xml file in the node directory of the Version 7.0 or later deployment manager to something else.
- Start the WebSphere Application Server
Version 9.0 deployment manager.
Start the deployment manager from its
profile_root/bin
directory. For example:
startManager
Results
At this point, the WebSphere Application Server
Version 9.0 deployment manager should be running and the normal
application synchronization should occur.
You can follow either of the following procedures:
- Migrate the entire cell before installing the applications.
- Perform the following actions:
- Install the applications and leave the cell in a mixed state.
- When you are ready, modify the connection-timeout values (as described in the tip at the
beginning of this article) before running the WASPostUpgrade command to migrate
the federated nodes.