WAS v8.0 > Migration and coexistence > Distributed operating systems > Migrate product configurations > Migrate product configurations with migration tools > Migrate product configurations with the migration wizard

Migrate a v6.1.x or v7.x federated node using the Migration wizard

Overview

Use the Migration wizard to migrate from a WAS v6.1.x or v7.x federated application server.

To enable rollback...

1. Back up the v8.0 dmgr configuration using backupConfig
2. Back up the v6.1.x or v7.x federated node configuration using backupConfig.
3. Migrate the federated node.

4. If necessary, roll back

Procedure

1. Perform a typical or custom WAS v8.0 installation.

2. Migrate the WAS v6.1.x or v7.x dmgr to v8.0

3. Collect the information that the Migration wizard will prompt you for during the migration. See: WASPreUpgrade and WASPostUpgrade

4. Optional: Use PMT or manageprofiles to create a target WAS v8.0 application server or custom profile, but do not federate the node. You can also create a target profile later using the Migration wizard.

   For the target profile, use the same node names and cell names for each node that you migrate from v6.1.x or v7.x to v7.

   If you make any cell-level changes to the new v8.0 node before migration, such as changes to virtual-host information, these changes will be lost during migration. Therefore, you should wait until after the node has been migrated before making any such changes. Otherwise, you will have to manually remake all of the changes to the new cell after migration using the administrative console running on the dmgr. This tip is reflected in message MIGR0444W.

5. Ensure that the v8.0 dmgr is up and running.

   We can migrate a v6.1.x or v7.x node whether the node is running or stopped. The migration tools can retrieve all the configuration data either way. We must stop the v6.1.x or v7.x node before you can start the v8.0 node that you are installing, however, so it makes sense to stop it now.

6. Start the Migration wizard by going to...
   Start | Programs | IBM WAS V7.0 WAS ND | Migration wizard

   ... or run...

   WAS_HOME/bin/migration.sh

7. Select or specify a previous version of WAS from which to migrate, and then click Next.

   Select the check box and enter the location of the previous installation if it does not display in the selection list.

8. Select the source profile or instance to migrate, and then click Next.

9. Select the target profile to which to migrate from the list of valid profiles for the installation or select Create new profile, and then click Next.

   Select the check box to create a backup copy of the target profile's configuration before migrating the source profile. If you select the check box, the backup copy of the target profile will be written to...

   PROFILE_ROOT/temp/MigrationBackup.time_stamp.zip

   We can use the restoreConfig command to restore the configuration after migration if necessary.

10. If you selected Create new profile on the last panel, enter the parameters for creating the new profile and then click Next.

11. Specify a migration backup directory in which to place a backup copy of the configuration from the previous version, and then click Next.

    The directory is created if it does not already exist. If the directory exists, it should be empty because the backup operation might overwrite existing backup files.

12. Select one of the options for migrating the applications installed on the source profile, and then click Next.

    We can choose to do either one of the following with the applications:

    • Include your enterprise applications as part of the migration.

    • Prepare your enterprise applications for installation in the WAS v8.0 installableApps directory without actually installing them during migration processing.

      Scripts that can be used to install these applications are generated and saved in the migration backup directory. We can then run these files at any point and in any combination after the migration. We can also reorganize and combine these files for better applications installation efficiency if you want.

    • Do nothing with your enterprise applications during migration processing.

13. If you selected the option to install the applications, specify where the migrated applications should be located and then click Next.

    We can choose any one of the following options:

    • Keep the applications in the same directories in which they are currently located.

      Restrictions: If you choose this option, the location is shared by the existing WAS v6.1.x or v7.x installation and the v8.0 installation. If you keep the migrated applications in the same locations as those of the previous version, the following restrictions apply:

      • The WAS v8.0 mixed-node support limitations must be followed. This means that the following support cannot be used when evoking the wsadmin command:
        • Precompile JSP

        • Use Binary Configuration
        • Deploy EJB

      • You risk losing the migrated applications unintentionally if you later delete applications from these locations when administering (uninstalling for example) your v6.1.x or v7.x installation.

    • Choose to install the applications in the default directory of the target version.

    • Specify the directory in which to install the migrated applications.

14. Select one of the options for setting port values, optionally specify a starting port value for resolving port conflicts, and then click Next.

    We can choose to do any one of the following with the port values:

    • Use the port values assigned to the previous (source) installation.

    • Use the port values assigned to the target profile.

    By default, a port conflict is resolved by incrementing the port number by one until an unused port number is found. Instead, you can specify a starting port number to be used when a conflict is detected. If the starting port number is in use, it will be incremented by one until an unused port number is found.

15. Select the check box to migrate to support script compatibility, and then click Next.

    If you select this option, migration creates the following v6.1.x or v7.x configuration definitions:

    • Transports
    • ProcessDef
    • v6.1.x or v7.x SSL
    • v6.1.x or v7.x ORB service threadpool

    ...instead of the following v8.0 configuration definitions...

    • Channels
    • ProcessDefs
    • v8.0 SSL
    • v8.0 ORB service threadpool

    Select this option in order to minimize impacts to existing administration scripts. If we have existing wsadmin scripts or programs that use third-party configuration APIs to create or modify the v6.1.x or v7.x configuration definitions, for example, you might want to select this option during migration.

    This is meant to provide a temporary transition until all of the nodes in the environment are at the v8.0 level. When they are all at the v8.0 level, you should perform the following actions:

    1. Modify your administration scripts to use all of the v8.0 settings.

    2. Use the convertScriptCompatability command to convert the configurations to match all of the v8.0 settings.

16. Specify the administrative console workspace user root directory where the "My Tasks" user information is stored in the previous installation, and then click Next.

    This panel displays only if you are migrating from v6.1.x.

17. Enter the administrative security credentials for the source WAS installation, and then click Next.

    This panel only displays if security is enabled and if the server user identity is not stored in the repository.

18. Verify that the v8.0 dmgr is running, and then click Next.

19. Check the information in the summary panel and make sure that it is correct, and then click Next to start the migration.

20. If the wizard indicates that the profile-creation process was successful, click Next. This panel displays only if you selected the option to create a new target profile. Otherwise, correct any problems and retry the migration.

21. If the pre-upgrade process is successful, click Next. Otherwise, correct any problems and retry the migration.

22. If the post-upgrade process is successful, click Next. Otherwise, correct any problems and retry the migration.

23. If the migration is successful, click Next. Otherwise, correct any problems and retry the migration.

24. Click Next to migrate another profile, or click Cancel to exit the Migration wizard.

25. Stop and restart each of the appservers on the migrated nodes.

What to do next

You might need to do some things that are not done automatically by the migration tools.

• Examine any LTPA security settings that you might have used in WAS v6.1.x or v7.x, and make sure that v8.0 security is set appropriately.

• Check the WASPostUpgrade.log file in the logs directory for details about any JSP objects that the migration tools did not migrate.

  If v8.0 does not support a level for which JSP objects are configured, the migration tools recognize the objects in the output and log them.

• Review JVM settings to verify heap size.

• Configure WAS to use a database.

  For example, you can configure WAS to use DB2.

• 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.

Migrate product configurations with the migration wizard
Migrate a v6.x or 7.x federated node
WASPreUpgrade command
WASPostUpgrade command

+

Search Tips   |   Advanced Search