To migrate the previous version of the product to the new version on a different host, satisfy or perform the following tasks:

  1. Review the important release issues for the 2.3.0 product, as described in the release note.

  2. Determine that the products that you are installing are supported for your platform. The Support Matrix guide provides more information.

  3. Determine if the host has enough disk space and memory to accommodate so both versions of the product can co-exist. The Support Matrix guide provides more information.

  4. Uninstall any temporary test patches (TTPs), if they exist, in your old installation.

    If a TTP has been installed on a Service Pack, you must first uninstall the TTP. Otherwise, the TTP files will be treated as files modified by you and copied to the local directory in the new installation area.

  5. Install the new version of the product on the different host as described in Chapter 2, “Performing an Installation.”

    The installation program installs the 2.3.0 software.

  6. Run the sm_migrate utility to copy user-customized files from the previous installation to the new 2.3.0 installation. “Migrating customizations to a different host” on page 86 provides instructions.

    Note:

    Run the sm_migrate utility immediately after the installation and before you start any services or modify any files in the new installation. The sm_migrate utility will not merge any files from the previous installation local directory, if the same files are present in the new installation BASEDIR/smarts/local directory.

  7. Evaluate your security settings. “Migration of security configuration files” on page 93 provides more information.

  8. Evaluate the environment variables in the old runcmd_env.sh file. “Migration of security configuration files” on page 93 provides more information.

  9. Evaluate your custom code. Review the “Custom file migration use cases” on page 91 to plan your post-migration steps. The sm_migrate utility migrated all user-customized files from the previous installation to the BASEDIR/smarts/local directory in the new installation. It also made a backup copy of the files under the BASEDIR/smarts/.migrate.bkp.x.x directory (for example, .migrate.bkp.2.0.0.0). Review the output of the sm_migrate utility and evaluate if you would like to keep the user-customized files in the new installation.

  10. Depending on your deployment, ensure that the BASEDIR/smarts/local/conf/runcmd_env.sh file includes the environment variables, SM_TLS_PROTOCOLS and SM_ALLOW_LEGACY_CRYPTO.

    Use SM_TLS_PROTOCOLS set to the +TLSv1.1 value only if you need to interoperate with products based on Foundation 9.0.0.0 Build 1345 through 9.2.x.

    Use SM_ALLOW_LEGACY_CRYPTO set to TRUE only if you need to interoperate with products based on Foundation versions prior to 9.0.0.0 Build 1345.

    Check the version number on page 102 provides the sm_server --version command to determine the Foundation (DMT) version.

    1. Go to the BASEDIR/smarts/bin directory and enter this command to open the runcmd_env.sh file: 

      sm_edit conf/runcmd_env.sh

    2. Search for the environment variables. If they do not exist, add one or both depending on your deployment: 

      SM_TLS_PROTOCOLS=+TLSv1.1
SM_ALLOW_LEGACY_CRYPTO=TRUE

    3. Save and close the file.

  11. Rename the repository file before reusing it.

    1. Locate the existing repository file that was copied to the BASEDIR/smarts/local/repos/icf directory in the new 2.3.0 installation.

    2. Rename the repository file by removing the version number extension. For example, the repository file INCHARGE-IP-ANALYSIS.rps.3.1.0.2 should be renamed to INCHARGE-IP-ANALYSIS.rps without the version number extension.

  12. Optional for IP Manager, run the repository file migration utility (sm_migraterps) to make the repository file compatible with the newer 2.3.0 version of the software as described in “Automatically migrate topology for IP Manager using RPS utility” on page 96.

  13. If you installed the products as services, start them for the first time. Starting services on UNIX on page 105 provide more information.

  14. Verify the current state of the products and Broker. “Verify the product status” on page 110 provides more information.

  15. For Server Manager,

    1. In the Domain Manager Administration Console, right-click on the ESM server (INCHARGE-ESM, by default) in the left pane and select the Load All ESM Host monitoring data from Backup option.

    2. Perform a discovery (Topology > Discover All) from the ESM server.

      All of the applications that were configured prior to the migration are restored and Server Manager starts to monitor those applications.

  16. Decommission the previous version of the products. For instructions, refer to the uninstallation chapter in the installation guide for the previous software version.