Migrating configuration data

You can migrate administrative configurations with the Installation wizard or with the migration tools, as this task describes. If you decide to use the migration tools, do not select the Migration check box on the Migration panel of the Installation wizard.

Before you begin

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 and minimal loss.

You can perform incremental migration of Version 3.5.x or Version 4.0.x nodes by calling the migration tools multiple times, each time specifying a different configuration file. Various reasons exist for having multiple configuration files. Whatever the reason, migrating one configuration file at a time lets you test applications incrementally before continuing to the next configuration file.

[5.0 only][Version 5.0.1][Version 5.0.2]Before using the migration tools, consult the Version 5.0.x Release Notes document to understand what fixes you must apply to earlier versions. Applying fixes to an earlier version might also apply fixes to files that have a role in the migration. Apply any fixes to ensure the most effective migration of configurations and applications possible.

Why and when to perform this task

[5.0 only][Version 5.0.1][Version 5.0.2]IBM provides a set of migration tools for migrating administrative configurations from Version 3.5.x, or Version 4.x to the Version 5.0.x base product, Network Deployment product, or Enterprise product.

The overall migration process when you issue the commands to use the migration tools instead of letting the installation program issue the commands is:

  1. Save the current configuration and necessary files with the WASPreUpgrade migration tool.
  2. [5.0 only][Version 5.0.1][Version 5.0.2]Install the Version 5.0.x product without selecting the automated migration option.
  3. Restore the configuration from the earlier release with the WASPostUpgrade migration tool.

[5.0 only][Version 5.0.1][Version 5.0.2]WASPostUpgrade uses the backupConfig command to save the existing Version 5.0.x configuration before performing migration. The results are stored in the install_root/temp directory. You can use the restoreConfig command to restore the backup, if required.

Steps for this task

  1. [5.0 only]Migrate Enterprise Edition, Version 4.1 to Enterprise, Version 5.0.x, as described in Migrating to Enterprise V5.0.x.
    Use this procedure if you are migrating from Enterprise Edition Version 4.1 to Enterprise Version 5.0.x.
  2. Start the deployment manager before migrating base nodes that are federated.

    [5.0 only][Version 5.0.1][Version 5.0.2]Start the Version 5.0.x deployment manager. During migration, the Version 5.0.x deployment manager must be running for the migration tools to:

    • Update the configuration for each federated node
    • Request full synchronization
    If the Version 5.0.x deployment manager is not running, failures can occur.


    Migration tip

    Operating platform Tip in Platform-specific tips for installing and migrating
    All platforms Recovering from configuration errors when the deployment manager was not running during migration.



  3. Migrate base WebSphere Application Server nodes.
    Guidelines for migrating federated nodes
    Rule Description
    A federated node has no control over its feature configuration. The deployment manager owns the configuration of all federated nodes, including the configuration of features on those nodes. When migrating a federated node, the configuration on the base node is owned by the deployment manager and cannot be changed.
    Unfederate a node to let the node own its configuration, if you must add features to the node. It is always true that you must unfederate a node before adding features. You then add the node back to the cell to cause the deployment manager to add the changed configuration of the base node.
    Install the Version 5.1 node with features that make it appear to be a clone of the node that you are migrating. When migrating, select the same features for the new node that are in the existing node. Adding or changing features can cause configuration problems in a federated node. The most trouble-free path is to select the same features.
    It is possible to migrate from one machine to another. One of the tasks introduced in this topic describes how to migrate a federated node to Version 5.1 on a different machine.



    If you are migrating a federated node, select the same type of installation that you chose when you installed the earlier release. If you selected a full installation type, select a full installation type now. If you selected a custom installation type, select a custom installation type now and select the same features that you did for the Version 5.0.x release. Federated nodes have configurations that are controlled by the deployment manager that controls the cell.

    [5.0 only][Version 5.0.1][Version 5.0.2]Migrating a federated node installs the same features for the node that are in the configuration for the Version 5.0.x node.

    Select one of the following migration scenarios for information about how to migrate configuration data to base WebSphere Application Server nodes:

  4. After migrating each base node, start each node.
    Use the startNode command from the install_root//bin directory of each base Application Server to start the nodeagent process:
    startNode.sh
    Occasionally, for example after rebooting an Application Server machine, you must restart the node agent server on the Application Server node, by running the startNode command. To keep your Application Server nodes running without accessing the bin directory of each one, use the operating system to monitor and restart the nodeagent process on each Application Server node. You can also set up the dmgr server as a managed process on the deployment manager node.

    See Automatically restarting WebSphere processes for more information.

    Adding a node automatically issues the startNode command for the node.

  5. Configure the Application Server after migration, as described in Configuring WebSphere Application Server after migration.
    Configuring the Application Server after migration is a way of verifying the results of the migration tools. You can also use Configuration mapping during migration to verify the results of the migration. The topic has a detailed description of how the migration tools migrate objects, and what you should verify.

Results

You can use the migration tools to migrate from one version of WebSphere Application Server to another.

What to do next

Return to Migrating and coexisting to continue.

Related concepts
Migrating
Configuration mapping during migration
Migration tools
Coexistence support
Related reference
addNode command
removeNode command
serverStatus command
startNode command
startServer command
stopNode command
stopServer command
startManager command
stopManager command



Searchable topic ID:   tins_migadmin
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/ae/tins_migadmin.html

Library | Support | Terms of Use | Feedback