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, new operating system, or new 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 |
---|---|
Plan your migration |
Review the following information on Control-M Migration:
After reviewing all the above documentation, create a plan that includes the installation, testing, and a migration date. |
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).
|
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) EM and Control-M/Server data and import this into the new environments for testing before the Migration cutover date. The export and import process can be repeated as necessary. |
Review final migration plan with BMC support |
Contact BMC support two weeks before the migration date to open an issue for an AMIGO Review of the migration plan. |
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:
-
DirectoryServiceType.cfg (see DirectoryServiceType.cfg parameters)
-
em.plc
-
emkey.p12
-
ess_key.txt
-
RemedyConf.xml
-
remedy.pwd
In addition, 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 |
|
Database configuration parameters |
Control-M/Server data |
Most configuration data (in configuration files such as config.dat), including Scheduling settings and Performance settings |
|
Agent and Remote Host data |
|
Customized values of the following parameters are not migrated. Instead, these parameters are set to the following default values:
|
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 System 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 |
|