A number of our clients are reaching the point where they need to consider migrating their current Control-M system to new hardware. This is often because the current operating system is either out of support, or reaching end of life. Where the host machine is a virtual server, it is often not possible to do an in-place OS upgrade, thus necessitating a migration to new hardware.
This document outlines some of the key elements that should be considered when planning the migration. Migration to new hardware offers an opportunity to review both the current hardware architecture and the use of service accounts.
BMC only support migration between operating systems for same major/minor version installations. Support for issues encountered during migration is only offered for supported Control-M versions. If your current system is 9.0.19.200, then the target system must also be 9.0.19.200.
Clients on unsupported Control-M version should review the upgrade path(s) available to them prior to considering the platform migration: it might be prudent to upgrade to a supported version of Control-M prior to migrating to a new platform. If the current version is still supported, it might be better to migrate before upgrading.
It is important to note down the scenarios for your migration, considering the Item (for example Ctrl-M/EM or Ctrl-M/Server), how it’s Hosted, the Current Platform, is it Physical or Virtual and what is the date support ends.
From release 21 (9.0.21.0) Java is no longer bundled with Control-M. This release requires java 11 or java 17. Java 11 support will be dropped in release 22.1. The BMC compatibility chart should be utilised when choosing the appropriate target java version.
The list of supported platforms for agents is constantly evolving, with older platforms being dropped from support. Where older platforms cannot be upgraded as part of the migration an available option is to use an agentless host. This involves using a supported agent as a babysitter for the unsupported platform, and utilising an ssh connection to run tasks on the agentless host.
Existing agents running an unsupported OS that cannot be upgraded due to legacy system can be converted to agentless: whilst this is a simple process, clients will need to perform the appropriate due diligence to ensure that their existing codebase does not use constructs that conflict with the reserved words used in scripting.
Proper use of HostGroups to separate out the logical agent functionality from the physical servers will minimise the code changes required at the time of migration. If your jobs refer to explicit servers, then every jobs needs to be modified when replacing that server.
If you have used a hostgroup, then the change only needs to be made in the system configuration.
Sizing
It would be prudent to review the performance of existing machines to determine whether they are running close to capacity or if there is a lot of unused capacity. Remember to check peak loading as well as average loading.
Firewalls
In addition to the known corporate firewalls, it is often overlooked that newer (server) operating systems often have firewalls provided as part of the OS. The ports used by Control-M will need to be opened up.
Cloud, Local or Hybrid
There is a lot of interest in outsourcing hardware to the cloud. Whilst this can result in savings, there is also a risk involved. BMC offer their Helix Control-M package, which can be used as a hybrid system. The Ctrl-M/EM element is always managed by BMC in their cloud environment (usually AWS). The Ctrl-M/Server can be cloud hosted or on-prem. Agents can be on-prem or cloud-based.
Things to consider:
– Job output files are always kept on the agent machine.
– Variable values will be held on the Ctrl-M/Server. The lifecycle of Named Pool variables should be considered as part of the design.
– Where the Helix offering is chosen BMC will take care of upgrades to the Helix Control-M/EM and Helix Control-M/Server.
– Clients are responsible for upgrades to their on-prem systems. Agents connected to Helix EM/Servers have an 18 month window for upgrades to be applied.
– The thick client (desktop) apps are officially deprecated. Release 22 will be the final version of the desktop GUI and CCM. Note that a lot of CCM functionality has already been moved to the web interface.
– Current environment identified
– Target environment identified
– Redundant processes identified
– Ctrl-M/Server migration/upgrade route identified
– Ctrl-M migration method chosen (automatic/manual)
– Agent upgrade evaluated and defined
– Hostgroups validated
– Service accounts validated
– All access migrated to Role-based
– Network changes identified (including routing, firewalls, group policies and NAS)
What happens to the Control-M/EM name?
The migration involves installing a new Control-M/EM server. The new server will automatically take the name of the new host platform.
What happens to the Control-M/Server Name?
When the EM is migrated a gateway will be created for both the current Ctrl-M/Server and the new server. Once the Ctrl-M/server has been migrated the new server can be renamed. Note that if the old name is to be retained then the gateway to the old server will need to be dropped first.
Do I need to migrate to a newer version of the same OS?
No. The migration process supports migration between windows and linux. Changing OS flavour does incur additional preparation and follow-up tasks, and is therefore likely to take a little longer.
Do agents need to migrate?
No.