Control-M Reviews

We use the solution in Western Mutual Insurance Group's environment for the daily scheduling of around 11,000 jobs. Our number of end-users is in the hundreds, across 18 to 20 teams. We have three different physical locations as a company. Since COVID, we are a partially remote workforce as well, so we have multiple locations.

It's essential that the solution orchestrates our workflows. Regarding processes like file transfers and data workflows, we want one source for that. We want one area where we can check and see how things are progressing, and Control-M is invaluable. Everyone has access in our environment to Control-M, and we all use it heavily. We utilize a ton of plugins in our environment. We started the transition into servers and are seeing what our license allows in that area. We try to take advantage of everything we can.

We use Control-M to replace a lot of our manual logging of job data. It's been very valuable in terms of logs that can output alerts.

I just did an audit earlier this year, and it was a swift process using the product. It took me less than a few hours, and without the solution, it would potentially take a couple of days to a week.

We essentially have a nightly batch cycle. We process data overnight, so it's available for end-users during the day. Using manual execution, instead of Control-M, this nightly batch cycle would transition into a weekly or monthly batch cycle instead.

I recently took over as admin of Control-M about a year ago. Since then, the question has been how we can further utilize Control-M in our environment. We haven't yet found the limits of what Control-M can do. We're finding better ways to apply it every day. From the old days when we manually scheduled jobs to the current paradigm of using an automation tool. This made the process much more manageable.

We define Control-M internally as a "critical business application." I would say that if Control-M were not available, the impact would be catastrophic to our business.

The reporting is top-notch. I haven't found any other applications on the market that can replicate what Control-M offers. The alerting is very good, and I think their service monitoring is the best in the industry. 

The solution is a key part of our system and I have not seen any significant limitations with it. It's very reliable and performs as advertised.

We're just starting our data pipeline journey. Compared to other products in the market, I believe Control-M's is the easiest to use. Theirs came out ahead in terms of ease of use every time. I rate them very highly in that area. We're primarily an Azure corporation. We found that the solution's built-in integrations with Azure are straightforward to use.

We actively build out methods of alerting, for instance, when workflows in Control-M don't complete, as this impacts our end-users and our managers that support the teams attempting to provide data for the end-users. I think Control-M has a ton of built-in integrations that make alerting when that data is unavailable more visible to end-users. I think that's been very useful in our environment.

The stability could be improved. I ran into an issue with a recent Control-M patch. The environment would become unstable if security ports were scanned. This is an area they need to improve on, but ultimately it's a relatively small improvement.

We have been using the solution for around seven years. 

One patch had some issues, but the fix pack was very helpful. Other than that, we haven't had any stability issues with this product. So I'd rate it very highly.

The scalability is excellent, we're looking into options in Azure for scaling up and down in our environment, and Control-M has been essential in accommodating that.

Technical support would be a 10. They're always available. They've been very helpful with any questions I have. There are multiple means of contacting them, and they've always been responsive. The technical account partner, Jake, has been very helpful. The account rep, Chris, has also been very responsive.

Positive

Control-M in our environment predates my time. I believe the company first implemented the solution around 15 years ago.

The initial setup was before my time. We started off as a mainframe exclusive influence of Control-M, and then we transitioned to distributed servers from there. I am a team of one.

The solution's automation has improved our business service delivery speed. Our big push this year has been toil reduction and automation of manual tasks that ultimately take time away from our engineers. Control-M is factored into probably north of 80% of those reductions with its ability to automate tasks. So far this year, we're at about 4,000 hours of toil reduced. I would say Control-M has played a factor in 3000 of those hours.

I would rate this solution a ten out of ten. Control-M is critical to our business.

There are other solutions like Control-M out on the market, but in every recent market evaluation, Control-M has always come out on top. I think they are becoming more cloud-native as they progress with their Control-M Web Services. They're more reliable than the others on the market right now. 

I would advise anyone to start with a trial version of this product. I think they'll be very impressed with it. 

We don't use Python to a significant degree at all in our environment. We have been looking into that, but nothing solid yet. We don't use AWS but are looking to get into it in 2024.

We use it for our workload automation. We use it as a single pane of automation for our enterprise.

We are currently using three different environments for three different productions. We have production data tasks, and we have multiple different levels spread out. 

We are currently using its most recent version. In terms of deployment models, they have both models. They have an on-prem solution, and they also have a SaaS solution. It just depends on what your company needs. They can take care of you.

Over the past so many years, I have learned that one of the most important features is giving everybody one tool that can do many different types of automation and workflows. That's been invaluable. Instead of having multiple tools for different teams and different platforms, Control-M has become the one-stop-shop for a lot of these automations.

It is very easy to create, integrate, and automate data pipelines with Control-M. It allows us to ingest and process data from different platforms. It could take us anywhere from a day to a week to get a new integration in place. We've taken it upon ourselves to try to introduce that to all of our internal customers as well.

It can orchestrate all our workflows, including file transfers, applications, data sources, data pipelines, and infrastructure with a rich library of plug-ins, which is very important for us. We try to utilize all new plugins that come out. If our company uses it, we try to use that plugin at least somewhere in our infrastructure.

In terms of creating, monitoring, and ensuring delivery of files as part of our data pipeline, it is a recent project, and it is something I've been learning about recently. However, having the ability to set up a job, set up a connection, deploy that job, and automatically have the feedback on where your files are when they've been moved has made life five times easier.

It has had an effect on our organization when creating actionable data. It has decreased the time to resolve dramatically. Everywhere I've worked, having Control-M orchestrate those alerts has been invaluable.

Our internal customers and management really appreciate the ability to be proactive before things really devolve into a problem or a high-severity incident. We're trying to incorporate analytics and proactive notifications as much as possible to decrease our downtime dramatically.

It impacts our business service delivery speed. Within the past few years, we have taken projects that normally would have taken multiple months, but the duration came down to a couple of weeks. So, we've increased our productivity tenfold.

Its impact on the speed of our audit preparation process has been great. With some of the built-in tools and some of the built-in reporting, being able to pull that data at any given moment has aided audit and probably increased our personal response time tenfold. We're able to get reports and audit out to the requesters within a week, if not sooner. Without Control-M, it would typically take us at least a month or so to get that out.

It has dramatically improved our execution times. We're able to get solutions out the door much quicker. A lot of our automations have been built around that, and we're able to get valuable output relatively quickly. When developing a new solution, without having Control-M, we would spin our wheels trying to come up with something that could only do a fraction of what Control-M can do at this point. Especially for a new solution or a new execution, we would be looking at a couple of weeks if not a couple of a month or two to come up with something deliverable. With Control-M, we're able to get that down to a week or two.

Our ability to integrate with many different solutions has been invaluable. The new approach of the automation API and jobs-as-code is also valuable.

The biggest improvement they could have is better QA testing before releases come out the door.

I have been using this solution for about 10 years.

I love it. It is rock solid. It is very stable.

There are no limits. You can easily scale up depending on your workload or whatever you need in a very short time. You can pretty much automate it at that point.

It is being used extensively in the organization. We do have multiple locations, but because we're using a web client, it is hard to say exactly how many end users are using it at this point. It is a company-wide solution. So, we probably have a couple of hundred users at this point.

They're very responsive. I'd rate them a 10 out of 10.

Positive

I personally have always used Control-M as my primary. I do know that other companies have experimented in the past, but I've always come back to Control-M.

I wasn't involved in the deployment. I always came on a little afterward.

In terms of maintenance, it is relatively maintenance-free besides the patches that come out. They come out pretty and frequently, but when they do, they're pretty comprehensive. Other than that, maintenance is pretty minimal. Because it is low maintenance, our engineering team does the maintenance when required.

We have absolutely seen an ROI. Over the last five years, I've heard we've done price analysis, especially with other tools. We always come out on top with Control-M. It always has the best price-to-performance ratio.

It is critical to our business. I don't know the facts and figures, but from anecdotes and talking to other management and up levels, I can say that it is considered a priceless solution in our environment.

If we no longer had Control-M, a lot of our most important pipelines would fall apart. Workflows would go unnoticed. The automation is so deeply integrated at this point that there's no telling what would break at this point. There may be things that we're not even thinking of.

For the tooling that you get, the licensing is acceptable. It has competitive pricing, especially with all the value that you get out of it.

There are additional costs with some of the additional modules, but they are all electives. Out of the box, you get the standard Control-M experience and the standard license. They're not forcing some of the modules on you. If you decide that you do need them, you can always purchase those separately.

I would advise working with the engineers, reading the documentation, and going into it expecting to set up high availability.

Control-M has been around a while. They're very quick to market, and they're very quick to adapt. At this point, they do have offerings, either on the way or recently released, that can support multiple cloud environments.

We are currently not using the Python Client, but that is on our board, and I do intend on investigating. We are utilizing some parts of the AWS integration.

I would rate it a 10 out of 10.

We are a large insurance company that uses BMC Control-M Managed File Transfer for batch processing and file transfers.

The batch is running on Linux, and it also has Windows components. Micro Focus is another system that we integrate with BMC Control-M.

It's an excellent method for organizing system change management. We use BMC Control-M Managed File Transfer to script our releases, which is probably the best use of it, but everyone would have a different answer. Because it is adaptable, we do a variety of things with it.

The file transfer feature is certainly useful. 

The most important aspect is the ability to integrate different platforms. 

We can run batches on mainframes, Linux, Windows, and all sorts of strange systems.

It can be difficult to stay on the right side of the licensing structure. Obviously, BMC Control-M Managed File Transfer wants to profit from it, so it's difficult for us and not cheap. 

It's probably more expensive than many of its competitors, but technically, there's really no downside.

They have caught up with most things at the moment; for security, they added SSL a few years ago, which helps a lot, and for file transfer, they will probably have to keep upgrading to add new protocols.

I am familiar with the password vaulting interface; they could probably add something for that because user IDs are a major issue in Control-M. You can now get systems that identify where the user IDs are, and you have to go there, and if you have the appropriate authorization, you can simply select a user ID and use it for the Control-M job. An interface to password vaulting would be useful, but they may already be doing so. I don't want to say this is a big missing piece only to discover that you did it two years ago. 

Password vaulting would be a feature that should be included.

I have been using BMC Control-M Managed File Transfer for 20 years.

We are working with version 9.19, but we are also testing version 9.20, which I believe is the most recent version.

BMC Control-M Managed File Transfer is very stable. We use it for about 40,000 jobs per day, but I know of sites that run hundreds of thousands of jobs per day on a single Control-M server. 

There is no problem in terms of stability. The only time I've had issues was when we used unusual servers to run the server on, and many years ago there were chips made by Intel called Itanium. That release was extremely buggy, but only about ten companies in the world used it. 

Stability and reliability are not an issue if you stick to the mainstream releases. It has internal high availability, failover capability, and all of these features. It is trustworthy, and it has to be. If it fails, other businesses will cease operations, so it has to be 100% reliable.

BMC Control-M Managed File Transfer is very scalable.

We have an unusual setup in that we don't allow many users direct access. They must send requests to a small team that will create jobs for them. We only have about seven or eight direct users in the system, but the number of people who rely on it is in the thousands. It is a strange setup. 

Most sites are set up in this manner, with people creating jobs on behalf of the larger community. We also have Control-M Self Service, which is a web-based tool that users can't really do anything with. 

We simply have it set up so that they can only see the jobs as they execute, and that is our approach. Many businesses are reluctant to grant widespread access to Control-M because, while it can be a powerful security tool, it can also be a security risk if many people have it.

We are moving, and MicroStrategy is one of the systems we are integrating with Control-M as well as SAP. SAP users want to start using Control-M, there is nothing special for MicroStrategy, but there is a plugin for SAP that we will install and use in the future. But, it will probably be another year before we get around to fully incorporating it. It would be implemented during the PoC consideration phase.

Technical support is good, but it depends on the situation. At times they restructure and assign you to other countries to communicate with. It's been very good when I've had to talk to people in the UK. 

They have occasionally relocated us to Italy, where some of the technical knowledge may be lacking, but they have good systems. 

They have BMC communities where other users can ask questions and interact. Technical support isn't bad; I'd give it a four because it's extremely helpful. They always do their best.

Positive

It was the very first solution we worked with. We tried a few other options when I first looked at the market 20 years ago. We investigated Tivoli Workload Manager, or TWM, as an IBM product that we didn't think IBM was developing much at the time, but that turned out to be the case. 

There is another product called title software that is a good competitor that we considered, but it wasn't as reliable as Control-M and all of the CA. Broadcom now owns everything.

They have a wide range of solutions in their portfolio, but I've never used any of them. CA-7, which is not a very old mainframe-based solution, could be compared to Control-M if you only had a mainframe, but it is incompatible with Unix and Windows. I have always worked with BMC Control-M and seen other schedulers, but it's always been BMC Control-M. I am trusting the software.

It's a lot easier now; years ago, it wasn't; some of the releases were extremely complicated. They have worked hard to improve that. It can be distributed from a central location, which makes releasing new agents much easier now, and many of the issues that people had with installation have been resolved if you're using mainstream platforms.  It is now a very simple install for Linux and Windows. On the Control-M server, you can run the installation process and choose an internal database supplied by BMC, typically Postgre. That is a much easier process to do now than it was 10, 15, years ago.

For the installation process, I would give it a four out of five, maybe a four and a half out of five. There are always things they can improve on, and sometimes you notice small details that aren't quite right. For an educated user, an easy install would be no problem. It's a simple procedure these days.

You can do the Control-M components in a couple of days, but it's what you've tied it into. Many people create their own scripts and then realize, oh, hang on. To keep up with the new Control-M, we must make changes. Two days for Control-M, but what you've tailored with it, if you're upgrading, obviously if it's a brand new install, then you start from scratch, hopefully with good conventions and standards to apply. However, if it is an upgrade, you may encounter issues where people say, "We hit some scripts on an agent, and now we have to go and figure out exactly what we were doing with those scripts." But that's not the Control-M side of the story; rather, it's what the users have done with it.

If you wanted to install a Control-M survey, you could do it within a day if you were to start from scratch, using all of the defaults. 

When you start doing something different, you run into problems. But if it is simply to perform the standard installation, and you want to take the database that we'll give you, or you can have a medium-sized installation. You keep saying yes. You should be able to complete it in a single day.

I have done a lot of installations over the years. I have sometimes been the third-party consultant who comes to companies to do the installation.

I believe you can do it in-house these days. The last one I did was in-house, but if you didn't have a lot of experience, you might want to find some specialized company to do it for you. 

There are specialist partners who will do this for you, but I believe you should do it yourself because you will have control and will know what to do if someone comes in and asks you how is this configured. You will know because you will be the one who configured it.

We currently have about four people in the team who are responsible for Control-M. It's complicated because one of the guys is retiring, and I'm not sure if he'll be replaced. People looking after, I'd say four is a good number for a Control-M server. There are various components to it, such as Unix administration and database administration. Obviously, we have other people who are specialists in their fields to whom we could go and notify them that something has happened; and ask them to have a look. or to log in to check. 

Four people would be the minimum number of people who would be responsible for a server.

BMC Control-M Managed File Transfer is expensive.

Because we are part of a company with subsidiaries all over the world, I can only provide an answer for Switzerland. At the moment, we are probably paying around $120,000 per year just for ourselves. But, they are attempting to restructure so that they can offer a global license, because, across Europe, we obviously have about 30 different companies that all have to do the same things.

I speak with my colleague in Spain, who is experiencing the same issues with questions and having to visit the local BMC branch. We are all paying the same amount, but different countries have slightly different prices. In fact, prices can be quite high at times; obviously, Switzerland is not cheap.

Our headquarters are in Germany, and I believe it would be better if they simply forget about everyone doing their own thing, and use this product all over, get a license through Germany and use it globally.

Their pricing is really their weak point. It's pricey. I would give them a three or three and a half out of five for pricing and licensing. 

People do get value out of it, and the work it does quickly pays for itself.

We pay for the file transfer module, which is an additional cost. They are not huge sums; perhaps you pay 20% more for the file transfer module, and you obviously have to host it on the platform. We are also paying for all the ancillary costs, but you have to pay extra Self Service, which is the website, which could be another 20% on top. 

If you said $150,000 for the year, that's about right. We do it per agent rather than per job, which is the difference between the two on-premise models. You can do it per agent or per job, and we only have a few agents, each agent handles a large number of jobs.

If you are starting from scratch, I would strongly recommend the Control-M Matrix, which is BMC's current SaaS solution. It is my understanding that it is a lot less expensive. I haven't used it myself, but based on the prices, it's likely to be nearly half the price of what we currently pay.

That simplifies your life because any upgrades to the Control-M server are handled by BMC. You go to the cloud, and they give you control and a server, and you don't have to worry about upgrades and such.

The disadvantage is that BMC now has your data, and they do not currently have a SaaS solution available in Switzerland. I believe it is only in the United States that things can become complicated, and BMC would then have complete control over your licensing.

They'd be able to see exactly how much you're using because we currently report how much we use. I believe it would work well for BMC because they would see a genuine reflection on usage and could then say, "You should be paying a lot more for what you are doing with the product."

The SaaS solution is called Matrix Control-M. If I were starting from scratch today, that's what I'd look at first, but some people might want to keep it on-premises.

Control-M obviously has agents that will work in the Amazon and whatever cloud, the Google Cloud, but that's a different story.

Where you can have it on-premises but have your agents somewhere in the cloud. That's not a solution I've considered, but I suppose it's becoming more popular.

I would rate BMC Control-M Managed File Transfer a nine out of ten.

We schedule the majority of our SAP jobs Control-M. We do that globally for all the production plants. We have tens of thousands of SAP jobs and managed file transfer.

SAP batch and managed file transfer are critical processes that we have automated. We are in the process of replacing Connect:Direct and SecureTransport, the legacy file transfer solution, with Managed File Transfer (MFT). That is on the global scale. 

The Control-M for Informatica is gaining a lot of popularity, primarily in the financial side of the business. They have a lot of security restrictions that make their jobs very difficult. Also, there are cost issues for Informatica, e.g., anytime they execute a workflow in Informatica, they get billed for it. We are adapting the solution to not scrum the workflow every half an hour or hour because they pay for it, but only when it is needed. Therefore, we can do a database query and check if there are new records that need to be processed. If there are no records to be processed, then depending on that output, we either run the Informatica job or leave it and check again for maybe half an hour. We are optimizing, saving money for the customers and ourselves, while reducing the number of executions, jobs, etc.

We are using on-premises. We have been for many years. We are aware of the new Helix offering, which is a SaaS/cloud offering from BMC, but it is not really ready for enterprise yet, not at our scale. We are doing some cloud, though not the Helix offering. I have installations in the cloud using Azure and AWS. We are not fully functioning there yet. We are waiting for the demand, but we are aware of the cloud opportunities and making use of them.

We have been busy upgrading to version 9.0.20 Fix Pack 100 but our production environment is still on 9.0.19 Fix Pack 200.

We use Control-M as part of our DevOps automation toolchains and leverage its “as-code” interfaces for developers. We have found that a lot of the new customers who are developing for cloud prefer to use the API and would like to test for themselves. That is really where Jobs-as-Code comes in. They can test and fail quickly the agile way. We definitely have some customers who are using that.

We have seen quicker file transfers with more visibility and stability. Because data transfers are part of the Control-M tool, they form as part of the normal workflow. We see the value in that.

If they have ad hoc requirements, then they can theoretically schedule their own file transfers with the Self Service. We are trying to push as much work back to the customers or developers that have that requirement, because they prefer to help themselves, if possible. We try empowering them and enabling them through Control-M, especially for file transfers, because it is a much broader base of the business then just with batch scheduling. Typically, with SAP batch scheduling, it would work with dedicated teams. With file transfers, the entire business is involved. There are business users, end users, etc. It definitely needs to be as simple as possible and as managed as well as possible. They need to manage it themselves, if possible, because our team is not growing but the number of customers, applications, and jobs are growing. We need to hand back some of the responsibility to the customer for them to resolve and action it.

A new feature, which we deployed about two years ago, is the Managed File Transfer (MFT). We also use Managed File Transfer Enterprise (MFTE) for external transfers of our biggest use cases. 

Another valuable feature would definitely be the MFT dashboard that is now available in Control-M natively. It is easy to just search for jobs, files, etc. Instead of the customers contacting us to find out what happened, when it happened, and why it happened, they are able to service themselves. This allows us to cut down on operational staff, costs, and time because customers can manage it themselves to a degree.

The most valuable feature is definitely the Self Service. A couple of years ago, it was available, but not with the features that it is today. There wasn't really uptake on it, although it was available. We have seen a steady growth in the number of users using it and what they are using it to do. They are using Self Service to schedule by themselves and do monitoring by themselves. They interact with their schedules. Also, the performance of Self Service is very user-friendly and more accessible. That is one of the features that we use a lot lately.

The reporting has definitely improved over the years. We are definitely doing more of that as well. We are definitely seeing more value in reporting on the batch schedules, optimizing it and seeing if we can cut costs. 

The reporting has improved. It is not where it should be yet, but we have seen improvements. The biggest thing for me is the restrictions regarding templates for reporting. You can't create your report with your own parameters. We have a meeting weekly with BMC and our customer lifecycle architect, and this comes up quite frequently. We have been privileged enough to do work with the developers. They are aware of the requirements regarding reporting and what our customers are asking for.

What I found lately about the YouTube videos, specifically, is that they are very simple. Usually, when I watch a video, I would read the manual, instructions, etc. to see if I understand it. I would hope that the interactive sessions, Q&As, or videos could be used to handle more complex issues of what they're discussing. An example would be the LDAP authentication for the Enterprise Manager. They would typically just go through the steps that are in the documentation. What people typically looking at those videos are looking for is how to do the more complex setup, doing it with SSL and distributed Active Directory data mines. Things that are not documented. I find those videos helpful for somebody who is too lazy to read the manual. I expect them to handle more than what is available in the documentation and the more complex situations.

The high availability that comes from BMC with its supplied Postgres database is very limited. Even using your customer-supplied Postgres database is problematic. We have engaged with them regarding this, but it is difficult. My company doesn't want to do this and BMC doesn't want to do that. We just need to find some middle ground to get the proper high availability.
We're also moving away, like the rest of the world, from the more expensive offerings, like Oracle. We are trying to use Postgres, which is free. The stability is good. It is just that the high availability configuration is not ideal. It could be better.

I have been using Control-M for 12 years.

Control-M is really stable. We have seen that throughout the years. I have had customers who have been running version 6.3 for seven years after support stopped. It has been running for three years straight, without a reboot or restart, doing its job. We have actually had issues with customers who don't want to upgrade. They have said, "This stuff is working perfectly. Just leave it alone because it just doesn't go down." 

We have a saying in our department as well. When somebody says there is a problem, we say, "It's not Control-M. Check everything else. Check the server, network, and database. It's not Control-M." 99 out of 100 times, we are right. It is either infrastructure or something else, but it is not Control-M.

I have never run into any problems scaling, either vertically or horizontally, with Control-M. In each version, it just gets better. I am really happy with that.

We were one of probably the first companies who bought MFTE, and it was not ready yet. It didn't scale properly. It didn't offer the functionality that the competing tools that we were currently using had. It's grown tremendously because of our input and feedback directly to the developers and BMC. I'm not complaining about it, but it put us back a bit. We have learned not to be a very early adopter. We have seen the same with the cloud. Everybody wants to jump on the cloud, but nobody knows why. They just want to do Cloud. We've made a substantial investment with MFTE. It was a couple of hundred thousand euros, and it was not ready yet for our enterprise requirements.

Our monitoring team who does 24/7 monitoring. They handle the alerts. They check their job flows. They make sure escalations are going through. If tickets need to be logged, make sure that gets done. They also interact with ad hoc requests from customers. 

There is the scheduling team who does the job definitions, updates, etc. 

There is the administration team, which I'm part of, with administrators who look after the infrastructure, Enterprise Manager, servers, agents, gateways, etc. Recently, we also have a dedicated MFT team that only looks after MFT because of the huge number of customers, requests, and requirements.

Other customers who use it are really all across the board. We had a presentation last week to our bigger department that is worldwide, but which we are a part of in South Africa. We have noticed about 52 main departments, then the sub-departments, between them. A lot of them sit right across the enterprise. Typically, the most active users would be SAP users who checks for output on the jobs running on Control-M. It is just 10 times easier to do it in Control-M than on SAP itself. We also manage to keep the output for longer than SAP. What they can't find on SAP after seven or 14 days, they can usually find with us, e.g., outputs for the jobs or logs. 

There are the MFT users who love being able to see each morning that their file was transferred, how long it took, and how big the file was. A lot of self-service users are using the Self Service function. Team leads and operational staff use it most.

I love support and the support people. It is very good. Because we are quite a mature customer and the whole team has a lot of experience (sometimes more than the support people), if they don't realize the seriousness of the situation, then we would not escalate but just to make our customer lifecycle architect aware by saying, "We are not feeling this case is getting the required personnel on it. We need somebody more senior. We don't have time to cover the basics that the first line support is trying to deal with. We've been over that." Overall, I would rate the technical support as nine out of 10.

Previously, we used a big SAP solution, which was not a commercial, and specifically designed for our company.

We have recently taken over a mainframe migration as well as the scheduling was on TWS, which is IBM's scheduling software on the mainframe z/OS. We moved that all over to Control-M. That was a combination of SAP jobs, Informatica jobs, database jobs, and normal script jobs. So, we use a bit of everything. We have also used the automation API a lot for interfacing with Control-M and other middleware tools, but primarily it is SAP and file transfer.

We use Control-M to integrate file transfers within our application workflows. It integrates with the tools that we are replacing, i.e., Connect:Direct, which is quite a legacy tool, and our old IBM tool, which we have been using for more than 15 years and has no visibility. With Control-M, you get visibility on your file transfers and how it mostly interacts with your batch schedule. Something gets created, it's sent over, and then it gets processed. Control-M has already been part of the executing, extracting, import, or processing. Now, with the file transfer, customers can see the entire workflow from the data being generated, transferred, and processed. This resolves a lot of complexities because you used to need to contact three different teams to find out if the file arrived and was processed. One tool does all of that now.

There isn't a lot of new functionality that our previous tools didn't have. It is just re-consolidating all the tools that we need into a single one. That makes it much simpler. There is one team to contact globally for file transfers, and that makes it easy. It provides visibility with its Self Service that wasn't available with Connect:Direct or SecureTransport. Our customers are quite happy to have that. We can also provide reports. 

SecureTransport competes with MFTE. There isn't a conversion tool for that yet. Connect:Direct simply provides the means for a conversion tool, but it gets integrated into scripts and applications. It's very difficult to migrate or extract that data.

The initial setup is straightforward. It changed a lot over the years as well, but in the nicest way. You have minimal downtime with the upgrades on Enterprise Manager as well as the Control-M servers. A lot of preparation is done before the tool is shut down for the upgrade. Our downtime used to be at least an hour for upgrades or migrations. That has typically come down to 10, 15, or 20 minutes, depending on the size of the server. It is definitely more stable and understandable.

We have also noticed that the exception handling is much better if there are issues. We don't get that many surprises. The errors are understandable. The agent upgrades have zero downtime, so that is just amazing. All the patching and maintenance is centralized. We have migrated our development and integration environments to 9.0.20 in the last month or two. That went very smoothly. We will start with production next week. We have been through this quite a number of times. We came from version 7 to version 9 to versions 9.0.19 and 9.0.20. We do all the upgrades in-house.

We do it all ourselves. If we get stuck, we would contact BMC. At my previous job, we were a partner for BMC in South Africa, and I was on the support side for BMC. It is only we need to open tickets for bugs or problems that we contact BMC. Typically, upgrades and migrations, we handle those in-house.

There are three people full-time on the administrative side. We have a global setup: Europe, Mexico, America, Africa, and China. We have tons of virtual machines and hundreds and hundreds of agents, and even more that we might host.

I know we have already budgeted for more tasks. The company is very happy with the performance of our teams, specifically the South African team. We are really doing more with good tools and less people. There is definitely a return on investment, just from the stability and visibility which has improved a lot.

On the effort side, we have definitely seen a lot of savings. We have some bigger projects that are automating the schedule and removing human intervention. These have reduced department staff/headcount, by about 50%, when we were able to automate the batch side of it, because also our department offers monitoring and operations as part of our service. We have a dedicated monitoring team. Whatever runs in Control-M, that is monitored by us and escalated, if needed. 

Departments now have multiple scheduling tools between the mainframe, distributed systems, and cloud. Control-M brings all of that, e.g., we have it on a single pane of glass so we can see the exact execution on the mainframe, the execution on the line, and the execution in the cloud. This is instead of using three or four different tools. Therefore, the complexity of batch monitoring and scheduling has decreased as well with the standardization of Control-M. That is definitely one of the big advantages that we have seen.

It is expensive. We have a lot of customers who complained initially about the costs. Because it's not just the licensing, unfortunately. It's the infrastructure, salaries, etc. I like the licensing model. It is pretty straightforward. We are on the task license. I know that we have some really good discounts. Our BMC account manager makes sure that we stay below the license count as well as checking for growth. Overall, it's good. The licensing is simple enough for me. It is a bit expensive. Especially with the cloud coming in, we might see the licensing change in the future, but I'm guessing.

This is now from my previous years as support for banks and big companies. If it's not enterprise scale, I find that it's too expensive for smaller companies. You really have to be quite big and need to have a dedicated support staff to run it, then you'll be fine. What we've seen at smaller companies, it's too expensive because they want to automate everything. Now, stuff that can literally run once a day for the rest of their lives is costing them $3 a job a day. It becomes too expensive, eventually. They are not seeing the return on investment because it's not business critical. Nobody is going to die or they're going to lose money if that job didn't run exactly at 11 minutes past 4:00. It's definitely for bigger enterprise companies, especially banks or healthcare providers. We have had an instance where Control-M was unavailable due to external factors for 20 minutes and there was a loss of almost a million euros because the solution involved logistics. 

We have done the usual crontab migration. Everything is in crontab or Windows Scheduler. Typically, we end up with a migration, even if it's from a known tool, where we end by exporting it into Excel and converting it into job definitions with a script. We have been involved in that, but nothing using BMC tools.

When I joined the company, I first supported them through the local partner. Because we have such a vast array of scheduling tools, they went through a PoC and business case. We evaluated three or four tools, where BMC Control-M was one. Quite soon, because the company was already using Control-M in Africa and China, they were looking for global solutions to see if it really could create change.  

What it came down to was ease of use, enterprise capability, and BMC was already in the company with ITSM and a couple of other products as well. They had a good relationship with us. We consulted with other customers who have used it as well as references because it was expensive. It was definitely the most expensive solution then, out of the four. However, we didn't want to go five years down the line and then have to change again because of issues.

We have had a very good run with Control-M. I love it.

With the move to big data and especially with our AWS Cloud presence, we have a data lake. We are in discussions with the analytics teams about how they can utilize Control-M in the cloud for analytics, big data, etc. However, at the moment, it is not a big deal.

What we have found with the Jobs-as-Code is that customers need to understand Control-M better, how the scheduling works, the knowledge around it, its conditions, etc. It took some time for the developers to get used to Control-M, then Jobs-as-Code. They are now confident with it. We are presenting twice weekly. We have an open forum for interested parties about Control-M or our department, Enterprise Scheduling and File Transfer, where we have a dedicated session about Jobs-as-Code. If there are questions about how other departments are doing it, if there is a better way to do it, if they are able to save on the number of jobs, can we make them rerun, or instead of creating 10 jobs, can it be done with five jobs? So, there is not a lot going from Jobs-as-Code directly into production, but we have a couple of parties, especially on the cloud front, who are very interested in it.

The solution is enterprise scale. Also, if you want to integrate all your applications into one view and offer all the functionality across the board, such as file transfer, scheduling, cloud, and on-prem, then you can create your own application integrations to integrate with applications that's not supported currently by BMC, like APIs. For top 100 enterprises, there isn't another better tool on the market for enterprise.

I would rate it as a nine out of 10.

It is used for file transfer, both inbound and outbound, including B2B.

Dashboard and recovery are the features I found most valuable in the solution.

I think that in the latest version, they have already improved. We still have to work on the latest one since we are still installing it. So we have not completed the installation. Post that, I think we'll see what needs improvement.

We have some issues on the SAP side of BMC Control-M Managed File Transfer. When I talk about non-SAP and SAP sides, I think with large volumes, one needs to install multiple agents. So that is something which should not be there. But at times, it is recommended by BMC. So, there are some stability issues when it comes to SAP side. The aforementioned details can be considered for improvement.

I have been using BMC Control-M Managed File Transfer for ten years. They released the latest version two days ago, and we are going to upgrade it to the latest version.

Stability-wise, I rate the solution a nine out of ten.

It is a standard pre-requisite that if we grow, then we have to double your CPs and other stuff. So, scalability is not an issue.

Since we are using the enterprise version, there are maybe more than 100 users that are concurrently logged in to the application.

We have used BMC's technical support, and we found it to be great. BMC has very good knowledge articles and other stuff, so that is good.

The initial setup is simple. Last time, it took around one and a half or two and a half hours to get the whole installation and migration done. So, now it can be done in less than one hour. BMC provides an AMIGO plan, and we follow that for deployment.

We handle multiple customers. So, the staff needed for the deployment and maintenance really depends on the number of customers.

I would definitely recommend the solution to those planning to use it since it is good to use.

There are some stability issues when it comes to SAP side, and hence I rate the product a nine out of ten. However, considering the Non-SAP side, I rate the overall product a ten out of ten. So, an average rating of the overall solution would be nine out of ten.

Control-M supports a lot of business processes. It supports some of the HR functions. I don't know if payroll is directly supported, but we do run jobs through PeopleSoft, which obviously impacts HR. Recently, we've started using the SAP module. So, we're making a transition from PeopleSoft to SAP, and I also see some payroll functions happening there.

We use Control-M to orchestrate a diverse landscape of vendor products such as Pega, MuleSoft, etc. File transfers and data feeds fetching are quite important for us. So, a lot of data processing happens through Control-M.

Control-M provides us with a unified view where we can easily define, orchestrate, and monitor all of our application workflows and data pipelines. Of course, such a diverse landscape requires you to make the effort to utilize Control-M to tie everything together or to act as the glue. Once you do that, everything is clearly defined, and you can view these disparate systems using one unified pane. If you don't define it correctly, then obviously Control-M won't have that insight, and so you'll have to go to multiple locations to go look at your job statuses.

We use its web interface. It is primarily for the application support teams to go monitor their own jobs. The jobs defined within Control-M are tightly controlled by a specific group of people. There are also people who need access to view that the jobs were completed successfully or why the jobs may have failed. These people are given access through Control-M web to view and monitor the jobs that they support or the applications they support. They're usually able to log on without having to install any client on their personal workstations. So, it's quite convenient. We have not implemented its mobile interface.

The integrated file transfers with our application workflows have certainly sped up our business service delivery by 80%. It has allowed the business to integrate file transfers more readily. Prior to utilizing the Control-M module, people had to write their own file transfer scripts in a scripting language of their choice to vary degrees of effectiveness. With the integrated File Transfer solution within Control-M, there is a standardized way of performing file transfers along with the capability of file watching and grabbing the file names that were transferred, making it much more versatile.

Control-M can immediately report when a job fails. If you have proper monitoring in place, you're notified immediately when your business flows are impacted. In the past, when you run jobs using Cron or just wrote shell scripts, you're really left in the dark because they don't necessarily report even from within Control-M. Implementing Control-M has made the business realize how critical and important it is to have proper error coding within the scripts that they schedule. If the scripts don't necessarily report any errors or redirect the system output into log files, when a job fails, there is no way to detect that.

We've automated many time-consuming business reports and other things that were very manual and took a tremendous amount of manhours. We've also automated a lot of maintenance using Control-M. We've integrated with Ansible Tower. So, we now are able to run Ansible playbooks and Ansible job templates. With the scheduling capability and the multitude of integrations that Control-M offers, it really acts as the unifying glue and as a communicator and orchestrator across the enterprise. With Ansible Tower, you can run a number of playbooks through it to perform patching and reboots and whatever maintenance that the infrastructure teams require, but you can't really do it when the business is still operating, or you can't do it when that business is operating, but you could do it for another business that's not operating at the moment. It is very hard to coordinate that without knowing which lines of business have jobs running or things like that. With Control-M, you can see that and you can actually enact workload policies to put jobs on hold prior to running Ansible playbooks. Once your Ansible playbook is complete, you can release the jobs again by deactivating the workload policies. So, it makes those processes very streamlined.

We do use the Role-Based Administration feature. We have been allowing other groups to gain more control over their agents so that they can define connection profiles, and they can do a little bit more on their side without inundating the main team with a lot of tasks. Everybody is happier. They can get things done faster, and they have immediate feedback and response because they're in control. The main Control-M team is not inundated with a lot of different requests from various teams to do a number of mechanical tasks. They don't get asked to create the connection profile for a database. People have all the information there, and they can do it themselves. They can define it in a way so that only they have access to it.

It has helped us to achieve faster issue resolution. Control-M reports on the error. It is easier to view the system output of that job. Whether it is an Informatica job, a scripted job, or a database job, it is easier to go in and view the issue and then troubleshoot from there. Most of the time, you can be running from the point of failure if the jobs aren't defined correctly. In a properly defined job, I would estimate that there is a 70% to 90% reduction in the meantime to resolution.

It has helped us by improving our service-level operations performance. We've built integration between Control-M and our ITSM, which is ServiceNow, and that has certainly allowed us to gain more visibility within our community through ServiceNow. Every time a production job fails, an incident ticket is cut, and that's highly visible. That needs to be escalated too, and there is a much more defined process to be able to resolve that issue. In the past, obviously, when you didn't have that level of visibility or that integration, there was always time lost in identifying what the issue is.

The File Transfer component is quite valuable. The integration with products such as Informatica and SAP is very valuable to us as well. Rather than having to build our own interface into those products, we can use the ones that come out of the box. The integration with databases is valuable as well. We use database jobs quite a bit. The file watcher component is also indispensable when integrating with other applications that generate files, instead of triggering a workflow based on time.

We have been experimenting with centralized connection profiles. There are some bugs to be worked out. So, we don't feel 100% comfortable with only using centralized connection profiles. We do have a mix of control on agents out there, which leads to some complications because earlier agents do not support centralized connection profiles.

A lot of the areas of improvement revolve around Automation API because that area is constantly evolving. It is constantly changing, and it is constantly being updated. There are some bugs that are introduced from one version to the next. So, the regression testing doesn't seem to capture some of the bugs that have been fixed in prior versions, and those bugs are then reintroduced in later versions. One particular example is that we were trying to use the Automation API to fetch a number of run ads users from the environment. The username had special characters and backspace characters because it was a Windows User ID. In the documentation, there is a documented workaround for that. However, that relied on two particular settings in the Tomcat web server. I later found out that these settings work out-of-the-box for version 9.0.19, but those two options were not included in the config file for 9.0.20. So, it led to a little bit of confusion and a lot of time trying to diagnose, both with support and the BMC community, what is the issue. Ultimately, we did resolve that, but that is time spent that really shouldn't have been spent. It had obviously been working in 9.0.19, and I don't know why that was missed in 9.0.20, but that's a primary example of an improvement that can happen.

We've also noticed that the Control-M agents themselves now run Java components. Over time, they tend to destabilize. It could be because garbage collection isn't happening, or something is not happening. We then realize that the agent is consuming quite a large amount of memory resources on the servers themselves. After recycling the agents and releasing that memory, things go back to normal, but there are times when the agent becomes unresponsive. The jobs get submitted, and nothing executes, but we don't know about it until somebody says, "Hey, but my job isn't running." When we look at it, it says Executing within the GUI, but there is no actual process running on the server. So, there is some disconnect there. There is no alerting function or the agent there that says, "Hey, I'm not responding." It is not showing up in the x alerts or anything like that.

The integrated guides have not been that helpful to us. I do find a lot of the how-to videos on the knowledge portal to be useful. However, there are some videos where the directions don't always match with some of the implementations. There are some typos here and there, but overall, those have been more helpful for us.

Its pricing and licensing could be a little bit better.  The regular Managed File Transfer piece, is a little overpriced, especially for folks who already have licensed Advanced File Transfer.

What I'm also noticing when I'm trying to recruit for Control-M positions is that the talent pool is quite small. There's not a whole lot of companies that utilize Control-M, and if they do, most people don't want to let their Control-M resources go if they're good. There is a high barrier of entry for most people to learn Control-M. There are Workbench, Automation API, and so forth mainly for developers to learn, but there are not a whole lot of resources out there for people to get more familiar with administering Control-M or things like that in terms of the technology or even awareness. So, it becomes very challenging to acquire new resources for that. A lot of the newer people coming out of college don't even know what is Control-M. If they do, they think of it as a batch scheduler, which is certainly not true in its current transformation.

Control-M is a very powerful enterprise tool, but the overall perception has not changed in the past five to six years that I've been working with Control-M. There's not much incentive for people to dive into that world. It is a very small community, and overall, the value of Control-M is not being showcased adequately, maybe at the C-level for corporations. I've had multiple conversations with other people and other companies who have already exit using Control-M. About 70% of the companies out there do not take full advantage of the capabilities in Control-M. So, that type of utilization really hampers and hinders the reputation of Control-M. That's because people then acquire this untrue concept that Control-M can only do X, Y, and Z, rather than the fact that Control-M can do so much more. I don't know if it needs a grassroots marketing movement or a top-down marketing movement, but this is what the perception is because that's what I'm hearing and that's what I'm seeing. For some of the challenges that I face working in Control-M, when I go back to my management and say, "Hey, I want to spend more money in this space," they're like, "Why? Can you justify it? This is what we see Control-M as it is. It's not going to bring us value in this area or that area." I have to go back and develop a new business case to say, "Hey, we need to upgrade to MFT enterprise or something like that." So, it definitely requires a lot more work convincing management in order to get all these components. In the past, we had to justify acquiring a workload change manager. We had to justify acquiring the workload archive. All of these bring benefits not only to our audit environment but also to the development environment, but the fact that we had to fight so hard to acquire these is challenging.

I've been using Control-M for about eight years.

Version 9 was very stable. Once they started adding a lot of the newer Java components, the stability suffered. It seems to have gotten better in version 9.0.20, but that's could be my basic perception. 

We run a lot of database client jobs. There are some things that we've implemented that I understand can contribute to the agent instability. We sometimes extract a lot of database output and massage that output using other scripts. I've noticed there are certain things that you cannot do with it, or there are some things that contribute to the instability. For example, in the output scanning functionality, there certainly is a size limit. You probably don't want to scan anything too large because that's going to put a lot of resources on the environment.

In addition, there are times when the agent becomes unresponsive. The jobs get submitted, but nothing executes. There is no alerting function. These are the examples of instability that I've noticed. Overall, the main application itself, the EM, and the scheduler have been pretty stable.

It is very scalable in terms of job execution. I haven't really explored scaling Control-M and the EM environment to a point where we have hundreds of users accessing it at a given time. That's because I don't have a hundred users who want to access that at a given time, but I do understand that you can distribute the web server more, and then have a load balancer to balance the load. I would think Control-M is a fairly scalable application.

In terms of its users, we have a lot of application support folks. We do have some developers who access Control-M mostly for the non-prod environments to execute and monitor their own jobs. There are some software engineers and operational engineers who are part of the application support teams that access Control-M. As for size or concurrent users, we have about 50 concurrent users at the max.

I would probably give them a nine out of 10. For the most part, they're very helpful, but there's always an initial standard dialogue. For an issue, you have to collect from EM logs, agent logs, and so forth, and you submit that. Sometimes, we have done all the advanced work and submitted it, but they still come back and say, "Hey, we need the logs." It seems like that's a canned response without looking at the tickets.

Positive

We've been with Control-M for quite a long time. We have not been using anything else in my history with this organization. 

I have not looked at anything recently. I am aware there are other application orchestration solutions out there, but I have not felt the need to go explore those options at the time.

If you're deploying using out-of-the-box options, the process is fairly straightforward. If there is some customization that needs to happen, then the process can be complex, and the documentation does not cover some of those complexities.

For the most part, we are standard out of the box. We have run into some performance issues where we had to, later on, go in and maybe make some modifications. For example, we had to stand up different gateways for various purposes just because one singular gateway was not enough to take the load in particular because we had installed a workload archive, and that was just taking up a lot of resources. Other human users were not able to perform their actions because the archive user was consuming so much of the server's resources. So, there was a lot of tweaking there, and we had to basically break out and distribute some of the components.

In terms of implementation strategy or deployment plan for Control-M, the environment always had Control-M, and we just had to upgrade the Control-M environment. We've had Control-M in our environment for quite a long time, probably when it was still version 6. So, as we progressed through different versions, we obviously had to expand the environment and the platforms. We initially started off with Control-M on AIX, and we later moved to Control-M on Linux. As you go to Linux, obviously, there is planning for high availability and production environments, disaster recovery environments, and so forth. So, you have to plan for marrying a lot of the BMC Control-M components and identifying where a load balancer may be required, or DNS ALIAS is required so that you can quickly flip over in the event something happens. Then, of course, there is sizing for the environment in terms of how many jobs are running, how many executions are happening, and so forth. This is how we plan.

We've used the AMIGO program, and then we've performed the upgrades ourselves.

For its day-to-day administration, we have a team of five people. They're administrators and schedulers.

Its return on investment is quite high, and that's mostly because we use so many of Control-M's capabilities. We also extend those capabilities. We write our own scripts to be able to integrate Control-M with so many other applications such as Automation Anywhere, Alteryx. We have also done vice versa. We have helped other teams develop their capabilities in integrating with the REST API and Control-M. So, the ROI is quite high for our use case, but based on the conversation with some of the community partners out there, their ROI is probably quite low because they're not making use of all these new features. I don't know if it is because they don't have the skillset to make use of these new features, or their management structure or process structure is hampering them from going out there. A lot of large companies I know like to maintain the status quo, and that's why they're slow to adapt and slow to move, which is going to hurt them in the long run, but in the meantime, it can hurt the adoption of Control-M as well.

Its pricing and licensing could be a little bit better. Based on my experience and discussions with other existing customers, everybody feels that the regular Managed File Transfer piece, not the enterprise one, is a little overpriced, especially for folks who already have licensed Advanced File Transfer. We understand that Advanced File Transfer is going away and is going to be the end of life, and there is some additional functionality built into MFT, but the additional functionality does not really correlate with the huge price increase over what we're paying for AFT already. This has actually driven a lot of people to look for alternative solutions.

I know they are now moving more towards endpoint licensing or task-based licensing. In my eyes, the value of Control-M is the ability to break down jobs from monolithic scripts. You don't want to have to wrap everything up in one monolithic script and say, "Hey, I'm executing one task because I want to save money." That defeats the purpose of controlling, and that defeats the value of Control-M. By being able to take that monolithic script and break it down into the 10 most basic components, you can monitor each step. It is self-documenting because, within Control-M, you can see how the flow will work, and you can recover from any one of those 10 steps rather than having to rerun the monolithic script should something fail. That being said, the endpoint licensing does make more sense, but maybe pricing or things like that can be more forgiving.

N/A

It is worth the time and money investment to learn more about Control-M. You should learn all the features of Control-M and really explore and test out the capabilities of Control-M. That's the only way people get comfortable with what Control-M can implement. A lot of people aren't aware of just how flexible a platform Control-M is, especially with all the new features that are being added via the Automation API. These features are helping to drive Control-M and things developed in Control-M more towards a microservices model.

We are just beginning to explore using Control-M as part of our DevOps automation toolchains and leverage its “as-code” interfaces for developers. Obviously, there is a little bit of a learning curve for developers as well in order to see the value of developing Jobs-as-Code. Currently, we're walking developers through it, and we're holding their hands a little bit in terms of developing Jobs-as-Code, but we are heading in that direction because it does provide artifacts that you can version control and change quickly and easily. You can redeploy much quicker than just having the jobs defined in the graphical user interface. Previously, when you had to modify it, you either did it via the GUI, or you exported it via XML and then modified those components. Once you get the developers closer to their job flows, then you can theoretically speed up the delivery of applications along with scheduled jobs.

I don't have a whole lot of experience with other scheduling orchestration environments, but from everything that I've heard while speaking with other colleagues, I would say Control-M ranks fairly high. I would rate it a nine out of 10. Control-M usually is the platform that people are moving to, not moving away from.

Our use case was mainly about consolidating our data pipeline from different sources and doing some data transformations and changes. We needed to get data from different sources into a state where we could act on it into one consolidated data set.

It gave us the ability to consolidate a diverse set of solutions into one comprehensive solution that streamlined our development processes. It was straightforward to adopt and we could build on existing skills without having to have 10 solutions for 10 problems.

And when it came to creating actionable data, it gave us the ability to move faster and at scale. By adopting a solution like Control-M, we were able to scale and deliver faster data transformations and maneuvers, turning data into insights in a more efficient and scalable way.

The ability to deliver faster and at scale was important. Business and management always wanted us to deliver faster and bigger and we were able to do both with the solution that we implemented using Control-M. We were able to respond faster to changes and business needs, at scale. 

Having a feature-rich solution enabled us to aggregate all of our processes into it, and that made the overall execution, from a project and portfolio perspective, a lot more efficient.

We were also able to respond to audit requests, because it's centralized, in a much more efficient way.

There isn't a single feature that is most valuable, but if I had to choose one, it would be the rich ability it gave us for making customized scripts. That was probably the most unique feature set for our situation. We used Control-M's Python Client and cloud data service integrations with AWS and, as a feature, it was very customizable. It gave us a lot of flexibility for customizing whatever data maneuver we wanted to do within a pipeline.

The Python Client and cloud data service integrations have a rich set of features with flexibility. It did not require additional, crazy skills or experience to deal with it. It was a nice transition into enabling a data scientist to leverage existing skills to build those pipelines.

Creating, integrating, and automating data pipelines with Control-M was straightforward. It did require some knowledge and training, but compared to other solutions, it was a lot simpler. Working with data workflows, with the data-coding language integrated into Control-M, was straightforward. The level of difficulty was somewhere between "medium" and "easy." It was not that hard to leverage existing skills and knowledge within this specific feature.

The user interface for creating, monitoring, and ensuring delivery of files as part of the data pipeline was very actionable. It was almost self-explanatory. Somebody with basic user-interface experience could navigate the calls to action and the configuration that is required. It was well-designed.

I would like to see them adopt more cloud. Most companies don't have a single cloud, meaning we have data sources that come from different cloud providers. That may have been solved already, but supporting Azure would be an improvement because companies tend not to have only AWS and GCP.

I used it for a couple of years.

It's fairly stable. I don't recall any specific issues. 

It's fairly scalable. For our needs, it scaled very nicely.

We have a shared model where we have a centralized, shared service organization when it comes to data. Different people will use it, but it's centralized.

We used other solutions from BMC as well, and their customer support was always great. I give them a 10 out of 10.

Training or a Knowledge Base were available or you could ask a question by submitting a ticket.

Positive

We had DataStage from IBM and SSIS.

The switch was really about streamlining the process. We had other tools that only did partial processes or were not doing it with the speed and efficiency that we were looking for. We were looking for a solution that could streamline things and solve 90 percent of our data challenges.

The analysis that I saw validated that the ROI was within a couple of years.

The pricing was competitive, from what I understand.

We looked at continuing to use the same solutions we had been using, and there were a couple of other cloud-based solutions that we evaluated. One of them was Matillion. The ease of use was one component of our decision, as was the flexibility of scripting with Python. Those were the key differentiators.

For the on-prem solution, we had to do the patching and whatever was required by the vendor, but the cloud implementation was a model that was usable. The upgrades, changes, and patching are done directly by the vendor.

Control-M was a critical piece of the puzzle, to help us with all the data transformation and projects that we had to do. It was part of either one specific project or even a larger project that required that middle data transformation so that we could get to analytics or any other consumption of that data.

We use the solution to automate our business batches, workload processing, and some elements of our IT and system maintenance procedures and processes. These include sequential clips, programs, and workflows. We automate these and have them scheduled for regular execution. We needed an orchestrator, and Control-M fits our requirements well.

The availability of data and reports is vital, and the solution's capacity for timely processing and build generation improved considerably over time. As our operation grew, so did our use of Control-M, and there has never been a delay in the availability of data and reports, even with very high workloads. Eventually, we could also bring automated control over our back end. Control-M makes workflow orchestration simpler; it can deal with an impressive amount of transactions.

We realized the benefits of the solution a long time ago, and from time to time, there will be a situation that reminds us how valuable it is to us. Control-M is an overwhelmingly stable and steady product, free from issues and frequent disruptions. As is the case for any such tool, there are occasional bugs and fixes, but overall, it's a stable product and a fully integrated part of our operation.

The product has improved dramatically over the years; it offers a lot in terms of features and capabilities and integration with third-party tools. A wide range of models available with the product is critical in reducing manual and mundane work such as custom script writing. This saves significant amounts of time and, by association, money for the organization.

As a Control-M user for over 15 years, I see it as very straightforward to create, integrate, and automate data pipelines. Even in the beginning, when Control-M was more of a data architecture product, it was easy to pick up. I've seen multiple people adapting very well in terms of adapting and enabling the capabilities of the solution for business; it's straightforward. 

Ideally, agent lift modes of connectivity would be established on different platforms. We can get applications integrated directly with Control-M. That's a recent feature. There are ready-made platforms and plugins which allow us to see templates for workflow orchestration in third-party and custom in-house applications. It's a straightforward solution, and this is an area where Control-M excels.  

Our customers are pleased being with Control-M, despite some minor hiccups, which happen with any solution. They have been happy with the product for years, and it's an enterprise-wide batch workflow orchestration tool. That's how it is established in our organization and what our users are satisfied and familiar with. 

The process execution speed is excellent and has constantly improved over the years.

The bottom line is Control-M is a mission-critical solution, it's integral to our organization. 

Regarding product design and R&D, the DevOps pipeline could be improved with better capabilities and automation. API security and authentication is another area that could use improvement; users must have static credential passwords, which is a security concern.

The REST API supports FTP for file transfers, but we would like to see additional, more encrypted protocols and simplified file transfer encryption. Currently, the solution offers PGP encryption, which isn't the most straightforward. 

We have been using the solution for around 15 years. 

The product is stable.

The solution is scalable; we increased our usage over the years and plan to continue that. 

We have multiple teams at multiple geos and deployments; we're an enterprise-sized organization.

Recently, there are some bugs with the product development, which necessitated R&D's involvement, which isn't ideal. We have fully integrated the solution into our production businesses, so any stability issues have a significant impact. There were cases where workarounds weren't provided quickly, with stubborn bugs needing environmental solutions.

Neutral

I've worked with multiple other workload orchestration tools, including IMB Tivoli Workload Scheduler and a CA automation product. Control-M stands above the competitors in terms of stability. CA underwent an acquisition, leading to changes in product strategy and mergers with equivalent products like Automic, so Control-M was the surer option. It is also more robust and has greater system availability than the competitors.

The initial deployment was complex, and this was by necessity. It is important to note that deployment is now more straightforward due to years of knowledge, experience, and newer features.

It took around two weeks to set up the Control-M infrastructure, and the process of bringing in business data and full adoption took place over years. It could be done faster, as in our case, there were other considerations involving budgeting, testing, and timelines. Setup of the initial infrastructure takes a few weeks, and then getting the platform running and configured can be done in a day or two. Further configuration and integration with LDAP and monitoring tools can take a little longer.

The solution can be managed and maintained by two or three staff members, but the number of staff involved in a deployment can vary significantly. It depends on the specific scenario and teams.

I would say we have a return on our investment; we have a vast amount of transactions and business automation implemented on a massive scale. We have adopted Control-M extensively, and it would be challenging to migrate to another solution in a reasonable time. We often look at alternatives but considering factors like timelines, resource availability, and team bandwidth, we keep coming back. The solution provides enormous value to our organization.

The solution is not cheap, it comes with quite a hefty price tag. Control-M is the market leader, but we still want the price to be as friendly as possible. 

The solution comes with the base module and an additional one with a few extra plugins, which is helpful. 

We evaluate competitors yearly, but in terms of value for money, we always return to Control-M. We get an excellent return on our investment.

I would rate this solution an eight out of ten.

I would advise any organization to do a proof of concept for their scenario before making a decision.

We don't currently use the Python Client, it's something we are planning to look into. We haven't started working on it, but we are in the review process to understand the client, and how it could fit into our operation.

The solution doesn't create new data as such, but it processes on top of the business data. 

We don't currently use the product for analytics, but we do plan to get Control-M data onto other systems for analytics and machine learning tasks.  

If we didn't have Control-M we would use an alternative solution. If there was a better one we would use that, or a product with a favorable cost and value proposition, which is a key factor.  

The tool always positively impacted our business, including our business service delivery speed. Over the years, there were one or two issues, but the vendor supporters could keep up. Some bugs required extensive development, and the support is excellent in this regard. They always have the right staff to assist during major productions or changes. Compared to before we had Control-M, it's as if we were previously traveling by foot, and now we've discovered the wheel. 

Regarding the audit preparation process, features like workload archiving come with an additional cost, which not all organizations can afford. I would instead maintain something locally on the system, but the solution is straightforward in terms of data necessities.

Control-M has to catch up in some areas, but it also offers specific capabilities and customization options. Application integration provides scope for exploration and deployment in custom developments. As a product supplier, BMC could focus on improving in areas indicated by their biggest customers. There is a lot of room for improvement.

File transfer support is Control-M's only significant limitation, as it only supports SSTP and STP transfers. Overall, other tools offer better security and file size in terms of file transfers. Therefore, the solution slows down when dealing with larger file sizes or a high volume of files, but it is sufficient for smaller organizations.