Control-M Migration

The Control-M Migration process enables you to copy your existing Control-M data from one Control-M environment to another. To migrate Control-M data, the source environment and target environment must both have the same version of Control-M (both major and minor version level, v.v.rr.mxx).

Migration is useful in various situations, including switching to a new computer, operating system, or associated database.

For situations where you need to upgrade from one version of Control-M to a newer version of Control-M, see Control-M Upgrade.

The Migration process must be performed separately for Control-M/EM and Control-M/Server. The migration process involves the export of data from the source environment and then the import of the data to the target environment. The export can be performed while the source Control-M/EM or Control-M/Server is up and running, allowing you to test the migration, configure the new environment, and run test jobs in the new environment. The export and import process can be repeated as many times as needed for testing.

For more details on the planning flow, see Migration Planning Process.

Migration Planning Process

The following table describes the main tasks in setting and implementing your Control-M Migration plan.

Tasks

Description

Install the New Environment

Review the following sources to prepare your new environment so that you can work in parallel with the old environment while you prepare your installation. Note that migration of Control-M data is supported only when the source environment and the target environment both have the same version of Control-M (both major and minor version level, v.v.rr.mxx).

  • To determine which computers to install the new environment on and check compatibility requirements, see the Control-M Release Notes.

  • To find the Control-M installation files, see the Control-M Release Notes.

  • Install the Control-M solution in the new environment, as described in Control-M Installation.

  • If you are migrating Control-M/EM with installed add-on components such as SLA Management, Forecast, Self Service, and Workload Archiving in the source environment, you must install these add-ons on the new environment before executing the migration import procedure.

  • Compatibility Mode from the source environment is kept the same (whether ON or OFF) on the target environment.

Migration

Select the relevant workflow and schedule the migration for your site:

Agents can be migrated after the Control-M/Server is migrated to minimize application changes.

Along with the migration of Control-M/EM, plan for the migration of Control-M Workload Archiving data. Migration of archived job data might take a long time and might necessitate adjustments to retention parameters. For more information, see Migrating Control-M Workload Archiving.

Test the Migration Process

Export both the (old) Control-M/EM and Server data and import it into the new environments for testing before the Migration cutover date. The export and import process can be repeated as necessary.

Troubleshooting

For more information about troubleshooting your migration, see Troubleshooting Control-M Migration or contact Customer Support http://www.bmc.com/support.

Verify New Environment

Verify that the migrated data exists in the new environment.

Control-M/EM Migration Considerations

During the migration of Control-M/EM data, the following data files are migrated:

Additionally, the Defaults.rsc files, in the <EM_HOME>/etc/resource and <EM_HOME>/etc/site/resource directories of the old and new environments, are merged to preserve the customized values in both environments.

Control-M/Server Migration Considerations

A variety of data types and data files are migrated to the new environment. Although most data is migrated, certain types of data items are not migrated and you will need to manually copy them to the new environment or manually configure them on the new environment. The following table lists the various data items that are migrated during Control-M/Server migration, as well as the data items that are not migrated:

Data Category

Data Migrated

Data NOT Migrated

Database Data

  • Scheduling-related data.

  • Agent-related data.

Database configuration parameters.

Control-M/Server Data

Most configuration data (in configuration files such as config.dat), including Scheduling settings and Performance settings.

  • Environment-dependent data, such as data regarding hosts and ports.

  • Database connection parameters.

  • Parameters for paths to files and directories.

  • Process parameters and comments.

  • Computer-specific or account-specific parameters.

  • SMTP and email settings.

  • User Exist scripts.

Agent and Agentless Host Data

  • Control-M/Agent statuses of disabled Agents.

  • Pre-defined Agent-specific parameters.

  • System parameters.

  • Manual conditions in the ctmldnrs.dat file (created by the ctmldnrs utility), provided that the file is stored in the default location, <Server_home>/tmp.

  • Lists of utilities permitted to be activated by the Agents.

  • Remote Agent maps.

Customized values of the following parameters are not migrated. Instead, these parameters are set to the following default values:

  • Communication Protocol Version: 12

  • Check Interval: 7200

  • Unavailability Shout Urgency: R

  • Persistent Connection: N

  • Allow Agent Disconnection: Y

  • Session Idle Time-Out: 900

  • Maximum Disconnect Time: 300

SSL Certifications

SSL migration is available only when migrating from UNIX to UNIX or from Windows to Windows.

For SSL migration, the Secure Sockets Layer parameter must be set to ENABLED, as discussed in SSL Communication Parameters or Control-M/Server general parameters.

If you are migrating from UNIX to Windows or from Windows to UNIX, SSL configuration is not migrated and you must define the SSL configuration manually.

Remedy Data

Remedy configuration parameters from the exported config.dat file are migrated to the RemedyConf.xml file located in ctm\<server_home>\data\remedy