What is our primary use case?
My main use case for Control-M is that we use it for DevOps jobs.
A quick, specific example of a DevOps job I run with Control-M is that we patch servers often, and we have a sophisticated deployment process for different packages in our on-premises servers. We do not just use an out-of-the-box package manager; we have a Control-M process that handles pushing these patches into these controlled environments.
Regarding my main use case or how I use Control-M for these deployments, that is everything I do. We have lots of different Control-M jobs for doing different things, but we mostly use it for patching.
My main business use cases or services supported by Control-M include DevOps and management of devices used for deploying our application at different environments.
How has it helped my organization?
Control-M's reliability is its big appeal to me, as it has consistently worked for the organization since long before I got into it. Its simplicity in that way and its user interface are the big appeal, but that is about it.
That reliability and simplicity have helped my team when it works correctly and as desired, as the little task box turns red when it has failed, which is a good indicator for us that it is something we need to look at. It is an easy way to review a large number of jobs through a kind of world view of all the jobs, allowing us to see if anything has failed and letting us know what has failed in a nice user interface, making it very accessible to a lot of teammates. However, it has the drawback that just because a job has not completed successfully does not mean it has returned an error that turns the box red.
I do not have any metrics regarding how Control-M has improved the way my organization functions. It seems to have been picked a long time ago for its nice UI, but I think we made poor use of it. Good use of it is not very intuitive, and the lack of integrated version control makes people afraid to change things to try and improve them. Due to its proprietary nature, we lack environments to test adjustments on, which leads me to believe it has not been particularly helpful.
What is most valuable?
The best features Control-M offers, in my opinion, include the ability to selectively hold and run different jobs and the nice user interface, although I am not really keen on Control-M myself. It is not version controlled, which I really hate, or at least our implementation of it, but it is lacking in a lot of features. That is why I also use Jenkins.
The UI helps my daily workflow by giving us a quick visual way to establish what kind of progress a specific job is making.
What needs improvement?
I would appreciate Control-M providing better logging on the output of different jobs because sometimes a job completes and it thinks it succeeded, but it did not. There should be more programmability around error logging and better integration with version control. We are not really using Control-M as well as we could because we are not parameterizing all of our jobs and their steps, which I think can be done better, but that should be a lot easier to do. It is very hard to update these jobs, especially since we do not have something such as a JSON file for it that we can update.
To improve Control-M, there needs to be more programmability around how and when we log errors, and it would be nice to have some tools that actually allow us to interface with Control-M with scripts being run by the task steps. I think it would be beneficial to have some kind of configuration file that we could read, representing each job, giving us the ability to text edit these jobs instead of having to drag these boxes around, which is inconvenient. Additionally, better integration with version control, a web view, and improved resizing for the desktop application would be awesome. I also find that when I search jobs, the search bar does not order them in the order they are actually executed in, just alphabetically, and better searchability for these jobs is needed, especially when you have a large number of them in queue simultaneously.
It is very inconvenient to integrate Control-M with technologies for my data ops and DevOps processes as things change.
I would assess Control-M for building, scheduling, managing, and monitoring production workflows as not very effective. I use Control-M at least every few days, but it presents a kind of unhelpful user interface. While we have more senior people on my team familiar with all these functionalities, I mostly just run patches when needed, which is not very convenient. Coming from a more Linux-heavy world with depth in Jenkins, I find that these processes are much more convenient and the user interface for actual configuration and programming is much easier. Overall, Control-M comes across as very low-tech and clunky.
Using Control-M has made it pretty much impossible to create, integrate, and automate data pipelines across on-premises and cloud technologies. We almost never make new Control-M jobs because it is so inconvenient, and it is just a very clunky and tough tool to use. I would almost always prefer to do my work with Jenkins or simply write a Python script that logs its progress rather than use Control-M due to the cumbersome process of breaking steps into little boxes without version control.
Buyer's Guide
Control-M
October 2026
Learn what your peers think about Control-M. Get advice and tips from experienced pros sharing their opinions. Updated: October 2026.
920,043 professionals have used our research since 2012.
For how long have I used the solution?
I have been using Control-M for just a year.
What do I think about the scalability of the solution?
I do not really know how many users are using Control-M in my organization, but my team consists of about ten people using it on and off, depending on our needs at the time.
How was the initial setup?
I do not know how long the deployment of Control-M took, as that predates me by a long time.
Which other solutions did I evaluate?
I did not participate in the migration to Control-M, and I assume that over time, we will migrate more to Jenkins, as much as we can in the probably distant future.
What other advice do I have?
I would rate Control-M overall a two out of ten.
I rate it that low because it is really very low-tech for what it does, and it has really fallen behind a lot of DevOps tooling. I use Jenkins here and there, which has version control and the convenience of managing credentials, making it easy to add agents and nodes, and it facilitates connections between those nodes more intuitively than what Control-M does. Control-M just makes you SSH into target machines; it essentially runs scripts and lacks built-in configuration compared to a tool such as Jenkins. Even though Control-M seems general-purpose, that just means it is not very well applied to the DevOps work I do, making it a clunky, proprietary piece of software. Its user interfaces are not really that valuable to actual technical people who just want good logging and good integrations for their automation.
Regarding Control-M's AI capabilities, I have not seen any governance and security features.
I have never used Control-M's AI capabilities to assess the accuracy and reliability of output.
The biggest lesson I have learned from using Control-M is that it is good to have code in front of you. Many organizations have followed trends onto tools that are very WYSIWYG, and I have used several such as Telerik Reports in the past. If you do not have code in front of you, you do not really know what is going on, and it becomes hard to facilitate integrations and log specific technical and business functionalities. Buying higher-level proprietary tools can lock you out of your own workflow due to the lack of customization and access.
My advice to others looking into using Control-M is to not do that because it is a proprietary product that overlaps a lot with newer open-source technology that is more accessible and paradigmatic for modern software development. Since it is a commercial product, the company likely offers consulting for best practices on how to use it, and getting training for its intended users along with documentation within the organization could help prevent other companies from falling into the same un-paradigmatic usage we have experienced.
Which deployment model are you using for this solution?
On-premises
Disclosure: My company does not have a business relationship with this vendor other than being a customer.
Hi there,
Thank you for taking the time to share such detailed and candid feedback. Reviews like this are genuinely valuable to us, and we’re sorry Control-M hasn’t fit well with your team’s DevOps workflow.
Several of the gaps you describe, including version control, text-based job definitions, scripting access and Jenkins integration, are areas we’ve invested in heavily. Control-M’s Automation API lets teams define jobs as code in JSON, store them in Git, and build, test and deploy them through CI/CD pipelines, including Jenkins. The web interface also gives browser-based access alongside the desktop client. Depending on your version and how your environment was originally set up, some of these capabilities may not be enabled yet.
We’d welcome the chance to walk through your setup with one of our Control-M specialists and look at how your patching jobs could be managed in a more code-driven way. If you are open to it, please feel free to reach out to your account team to schedule some time with us.
Thanks again for helping us improve.
—Claire Murphy, BMC Software