Control-M Reviews

We use Control-M to automate scripts that we use in banking and automotive use cases. These are our two big applications. We have a total of 18 applications running in Control-M now, and we want to move over approximately 13 more.

Control-M is running in a virtual machine.

Before Control-M, we had a lot of applications running under different operating systems, including Windows Server and Linux Server. We had a lot of scripts and a lot of programs that were running on the servers. When we implemented Control-M, we were able to automate a lot of those scripts. We have a lot of bank applications and processes and to this point, we have automated about 30% of the ones that we have to do.

We have automated some of our critical processes in core banking. Many of them are now being handled by Control-M. However, we have not yet finished all of the scripts.

Control-M gives us good visibility of our applications and processes. For example, in the morning we can see the results of all of the scripts, whereas, in the past, we could not do that. Our goal is to move the execution of the scripts from the server to Control-M. At this point, the scripts are controlled from Control-M but the execution is done on the server.

We have four domains in Control-M. We have planning, monitoring, history, and forecast. We do not perform data analytics yet.

Our clients use the web-based interface to interact with Control-M.

When a new team member or a new client wants to use Control-M, we have to install a client on their machine. After that is done, there are three options. The first is called Workload, and it is used for observing or monitoring the workload and execution of the jobs. The second one is called the configuration control manager, and it's for configuration administration. The third is reporting, which is another important one. We use the reporting module to generate our reports that concern the execution of the jobs.

We use Control-M to integrate file transfers with our workflows. It is called Advanced File Transfer (AFT) and is used by our financial team. We have another technology for file transfers but the problem with it is that it provides no transparency. There is no interface to see the transfers between applications. With Control-M, we can monitor the transfer between applications and it's great because we can see everything that happened throughout the day.

AFT allows us to configure actions. For example, if a file transfer does not complete successfully then we can send a notification to the destination about the problem.

Control-M has helped to improve our data transfers because it allows us to monitor the execution of the process. With other technologies, we cannot do that. Also, it allows us to configure the notifications, which is very important for us because it will automatically tell the other team when there is a problem with the transfer.

The most valuable feature is the monitoring, which allows me to see the execution and results of each of the scripts.

Being able to view the history is very important because if we have a problem then that is where we search for the details.

From an administrative perspective, the planning domain is very important when we want to add a new feature or a new script.

The forecast domain is what we used to ensure that the implementation is working and that the configuration is okay.

Compared to similar technologies, AFT takes a lot of time when transferring a large file from server to server.

The history module only contains a maximum of 10 days, but we would like to have access to more. For example, it would be helpful to have 30 days or two months of history available.

There should be more granular control available for monitoring applications and sub-applications. For example, when we want to monitor a job, we can specify the application, but we want to have the option to only specify sub-applications that are related to it. As it is now, all of the sub-applications are monitored.

We implemented Control-M for our clients approximately four years ago.

Control-M has been stable for us since we implemented it, four or five years ago. We have not had any problems with the database, file system, or scheduling component.

The scalability is excellent.

We have about 13 people who work regularly with Control-M. We are all engineers and IT managers, and I am the main administrator. The other administrators are in charge of their specific applications, and they need access to Control-M because they need to see the execution plans for the applications that they are in charge of.

I have worked with BMC technical support and I would rate them a nine out of ten.

They respond very quickly, according to the severity of the problem. Also, the responses that they give are really clear and assist us with finding the problem, as well as the root cause.

I have worked with Dollar Universe and AutoSys in the past, before working with Control-M. I find that overall, Control-M is the best one for several reasons.

First, with Control-M, it's easy for someone to be an administrator. All of the documentation is available online, which is important. The second point is that the interface is easy to use. The third is that the solution is really stable compared to other products, such as AutoSys or Dollar Universe. These solutions were not stable in our environment. Part of the reason was that we had trouble finding any documentation online.

This is an expensive product compared to other solutions, although I think that it is a good one. We are in a good position with licensing, as we can run 10,000 jobs. To this point, we have 3,000 jobs that are running, which gives us room to integrate the remainder of our applications. 

My advice for anybody who is looking to use Control-M is to have a lot of money. It is a good solution but it is expensive compared to others.

I would rate this solution a ten out of ten.

We are using the solution for maintaining the infrastructure jobs like database Genesys and NICE. All jobs have been integrated into a single frame and a BMC Control-M readme page. Basically, we create jobs and modify the jobs. We have to analyze if any jobs fail. We settle the issues so that the jobs are up to date and should run.

The solution can communicate with the cluster. It can redirect any alarms or failures, and we remediate those actions.

We create new job scenarios and workarounds. We have special access to incidents and monitor controller operations. 

The solution is good in terms of working with other products. The integration is useful. 

Once you understand the solution, the initial setup isn't too bad. 

The solution is stable. 

It's scalable. 

We need the updates to be able to maintain interoperability. We still want to be able to verify testing in production and the environment and want upgrades to go smoothly so as not to disrupt our applications. The more seamless it can be, the better remediation will go. 

We'd like it to be easier to maintain the administrative side. Transferring files should be easier. There are a lot of dependencies. We'd also like there to be less space consumption.

There's a bit of a learning curve for new users.

When we pull job applications, if we configure multiple tenants under multiple environments with a single frame while we are logging into the applications, it sometimes freezes and takes too much time. 

I've used the solution for about one year.

From what I have seen so far, it is stable and reliable. 

We do have frequent version upgrades and maintenance and therefore haven't seen many issues.

It's a scalable product. I'd rate it eight out of ten in the ability to scale. 

We have 11 people on our team and about four people who handle administration and maintenance tasks. We're in four regions: Australia, Singapore, India and New Zealand. In these regions, there are two configured clusters - one in Australia and one in New Zealand. 

We have an administrative team that has the privilege of raising technical support. We will do the Genesys part, however, for BMC, they run the people. They will take care of coordination with the vendor and the business unit.

We use a lot of different solutions, including Genesys, NICE, Control-M ESPL, WFM, and workforce management. All are interoperable.

The company has used this solution for about seven years, and I have only been around for one. I'm not sure why they first initiated usage.

The initial setup is easy once you have some experience. It can be somewhat difficult otherwise. 

We have four people that are able to handle maintenance tasks.  

Once our teams have tested and validated the scenarios are working fine, then they will move from Genesys into services. Once Genesys services have been integrated, Genesys engineers will come and will monitor everyday operations for Control-M. If they identify any files or any jobs that have instability, they'll look for a permanent fix.

We are mediators between the vendor and customers. 

We are using around version nine. I'm not sure of the exact version number. 

I'd rate the solution seven out of ten. I do need more time with the product. However, I haven't seen the product causing many issues. It's been sustainable, and we've liked having all operations in one single cluster.

We mainly use Control-M for integration in cloud environments like GCP and AWS. I'm an electrical engineer who mainly uses Control-M to access the files, documents, and data I need.

Control-M ensures that our files are secure and the data pipeline is accessible. It helps. It also allows us to create and monitor data while keeping it secure.

Control-M is critical to our business because we couldn't remotely access our files on the cloud without it. It makes our work easy when there's an issue in our admission sector. I would say it has been a significant help.

The web interface is handy. It's easy to use, and Control-M provides you with the necessary materials to understand the features and perform various tasks.

The interface is user-friendly. I had no prior experience, but I found it easy to work with. I had to review lots of documentation, but it's not difficult to navigate the different applications on it.

Creating and automating data pipelines is a bit difficult for a new user because some of the documentation isn't available. The documentation could be improved, and I'd also like to see automatic upgrades.

I was recently hired at this company, so I've been using Control-M for over a month now.

Control-M is stable. That's one reason the company chose them.

Control-M is scalable.

I rate Control-M eight out of ten. I have contacted them to help me understand how different things work in Control-M.

Positive

I rate Control-M eight out of ten. It's a solid application, and the graphical user interface is intuitive. Control-M can be used for different applications with various parameters.

Control-M is a scheduler tool, and we have multiple batch jobs that are currently running in our organization. 

We are currently one version behind the latest one. The latest version is 9.0.19.200, which also has Control-M Python Client, and we are planning to go for the latest version.

We currently have it on-premises on the Windows platform. We are planning to migrate to AWS.

We have multiple technologies, and we have different types of jobs, such as Informatica jobs, SAP jobs, database jobs, web service jobs, etc. In such an environment, from the support perspective, usually, we need to log in to multiple technologies and check if a job is executed or not and if there is any error, which is not easy. Control-M acts as a one-stop shop to check the status of all jobs. The maintenance or support team members can easily log into Control-M and verify the job status.

It has been helpful in reducing the burden on our resources during the weekend. It has also been helpful in reducing delays and data mismatches.

It is easy to create, integrate, and automate data pipelines with Control-M. You can drop and drag whatever you want and then provide a time for the scheduler. There are many inbuilt plug-ins, such as the Informatica plug-in and the SAP plug-in. We are using these plugins. It is pretty easy and simple.

It allows us to ingest and process data from different platforms. For example, you can have a flow that starts with a REST call. Once that is processed, the records are picked from the database and sent to SAP. You can easily design a pipeline workflow and schedule jobs. You can also specify the dependencies. For example, you can specify to execute Job B when Job A is completed or execute Job C when Job A and B are completed. There are multiple options in Control-M to ingest and not miss data from any platform.

Testing is easy. You can have multiple environments, such as development environment, testing environment, staging environment, and production environments. You can easily test your workflows, and you can easily promote from one environment to another environment. You can promote from the development environment to the staging and production environment. There is an option called Promote, and you can use that option to promote to whichever environment you want.

We are an enterprise, and when the data moves from one technology to another technology, multiple teams get involved, which requires multiple communication exchanges between the teams. Sometimes, there might also be delays in getting the data from one team. With Control-M, we can create a workflow where we can specify to proceed for job B after job A. There is no need for a team to send emails to another team. There is no delay. Team A doesn't have to inform team B to run a job because otherwise, there will be a delay. Control-M eliminates such issues. It has improved our business service delivery speed.

It has good reporting capabilities. You can get a report of the status of all your jobs. You can see how many jobs are pending and how many are processed. You can also share these reports with the management. There is also a URL that you can give to your management or customers. They can check the job status, and they will have knowledge about the status and any abnormalities.

Automation of Control-M has improved the speed of process execution. No manual intervention is required using Control-M. You don't need to have a resource waiting to do a job at a certain time. You can automatically schedule a job, even over the weekend. It results in faster speed and better utilization of resources. You can also integrate it with other solutions. For example, if a job fails, a ticket can automatically be created in ServiceNow or BMC Remedy and assigned to a specific group so that they can look into it.

I find Control-M for SAP and Control-M for Informatica good. You can connect to the Linux or Windows servers, and you can run multiple jobs. 

Control-M Managed File Transfer is also a very nice feature for transferring multiple files.

It meets our requirements, and it is simple and easy to use. 

They can give more predefined plug-ins so that we don't have to create them. 

The security layer for Control-M MFT can be better. 

We have been using Control-M for the past six years.

Its stability is good.

Its scalability is good. We would like to increase its usage, but its price is a challenge.

Their technical support is very good. They also have a community portal. I would rate them a nine out of ten.

Positive

We didn't use any other solution previously.

I am responsible for installing and managing Control-M. Its initial setup was straightforward. It took about nine hours to get it installed and up and running. The number of people required for deployment and management of jobs depends on the scope of your operations. If you have 50,000 jobs a day, two people are enough.

Its maintenance is handled by the server team. We have it on-premises, and they take care of the patches and upgrades. If it was on the cloud, the upgrades would be done automatically.

Its pricing is a little bit high. They could provide an enterprise-level license for an unlimited number of jobs. Currently, it is based on the number of jobs, and if you exceed the number of jobs, there are charges. For example, if your license is for 3,000 jobs per day, but you run 3,050 jobs, you will have to pay for the extra 50 jobs. They charge $120 per job. So, it is too costly.

To someone who is looking for a process automation solution but is concerned that Control-M isn’t modern enough to work with multiple cloud-based data sources and tools, I would say that Control-M is the best option even when working with cloud-based data sources. 

I would rate it a nine out of ten. Control-M is the best solution to replace any enterprise solution if its price suits you.

We use Control-M to monitor jobs on the endpoints. We monitor throughout the day to see which jobs fail. It helps resolve issues with the programmers. They know if they want to rerun, force complete, or hold a job. We work hand in hand with the programmers who have the final say on what they want to do with a particular job that requires action. Control-M is deployed across multiple locations, but I can't estimate the number of users.

Control-M is a critical part of our operations. We rely on it to do our jobs daily. It helps us automate things that come from the JCL side where you would normally have to do everything manually. It's a little quicker and more automated on the BMC side, which makes things smoother for the end-users. 

The solution allows you to relay your issues to management, who in turn, can communicate them to our customers and programmers. It maintains a dialogue between all parties. It's had an overall positive impact on our process execution. 

We can set up automated email notifications to the programmers or the whole team for a particular job. It helps save time because we're not consistently looking at the job to see if it has ended or failed.

The Control-M interface makes delivering files in our data pipeline a little easier. The integration is so much more seamless, so the transition is a smoother experience.

I've been using Control-M for four years. 

The stability is fairly good. We haven't had any serious issues. 

The response time could be faster when you need a person to answer your questions. There are situations where availability becomes crucial. 

I wasn't involved in the deployment. Maintenance is handled by our unit team. They do updates and patching almost weekly.

I rate Control-M an eight out of ten. It comes down to preference and what you need. There are multiple platforms out there, but I've only used this software.  I recommend doing some research and seeking out a lot of opinions. Talk to other folks who worked with other solutions to get a grip and a better understanding. 

We primarily use the solution for automation, orchestrating and automating the workloads, and being able to schedule tasks. Prior to Control-M, we were manually running jobs or there was either a scheduled task on Windows, getting Task Scheduler, or we'd have a script laid out that someone would have to run through manually on a daily basis. 

We learned about Control-M and felt that it could take over that process and have it automated, while also providing some monitoring and notifications so that if something did fail, we could easily be notified and keep track of it.

It provides a holistic view of jobs that are scheduled to run. We haven't done full production on it yet. Hopefully, we'll be in production by July or August this year. That said, so far from what we can see, it's going to free up some time for certain staff that has been running these tasks manually overnight. Now, if someone gets notified of an issue, then they can address the issue. In the long run, it'll free up some time and resources to focus on other tasks. 

I like the interface, including how I can see everything and how I can put the jobs together. Depending on the experience, I can either use the GUI or I can use the command line to create jobs based on JSON scripts. It provides that flexibility for someone who has no experience of using Control-M as well as with someone who's a full-blown developer that can get very complex with creating these jobs. Generally, it provides a good interface for everyone with different levels of experience.

Control-M doesn't really process data as far as I can tell. It orchestrates other scripts. From what I understand, Control-M doesn't really ingest or analyze any data. It's a tool to help with the processing of data on different platforms. I can tell it to run a script on one server, to send the data over to another SQL server, or a different platform, Power BI for example, and run a script on Power BI so that it can ingest the data when it gets there and do what it needs to do. Once that's finished, I can send it to another platform to put a dashboard together based on when that data is available.

Once one understands the process of how it functions, it's pretty simple and straightforward to create, integrate, and automate the pipelines. There is a learning curve to understand how it all works, all the components, and all the requirements for parameters and different options. However, it's pretty simple once someone has a basic understanding of how it all works.

The Control-M interface is good for creating, monitoring, and ensuring the delivery of files as part of our data pipeline. There's a wealth of information in both the full client, as well as the web interface that they have. Both are very easy to use and provide all the necessary material to understand how to do various tasks. The help feature is very useful and informative and everything is very easy to understand.

It’s great that Control-M orchestrates all our workflows, including file transfers, applications, data sources, data pipelines, and infrastructure with plugins. There are a lot of plugins and we haven't used all of them yet. Primarily, we've only used the file transfer plugin, the Azure file service, and Azure functions. Primarily, the developers have used that to put the various tasks and workloads in place. While we haven't fully utilized everything in Control-M yet, we're learning how to use the various functionalities and transitioning from our legacy scripts and data sources. 

Some of the documentation could use some improvement, however, it gets you from point A to point B pretty quickly to get the solution in place.

I've been using the solution for almost a year. 

It seems stable. I haven't rolled the solution out to a very large environment yet. The solution we're working on right now seems to be working fine. All the issues we've seen have to do with us figuring out connectivity between Control-M and the cloud services, however, I haven't had any experiences with issues around stability with Control-M.

Right now, it's a small deployment and we have it in four environments. We have it in our dev, QA, UAT, and production environments. Right now, there are two application teams that are using Control-M, however, we have another two or three teams that are looking to get onboarded.

It's pretty scalable. I haven't done a deep dive look into it the scalability, and we haven't identified a need yet to scale out. It seems pretty scalable, yet I'm not sure as I can't speak from personal experience. I don't have experience with it yet.

It was a challenge to get the direction on how Control-M should be implemented. As we learned about new requirements from the customer, implementing those with help from the engineers at BMC was hard. The third-party contractors were one issue, however, when I escalated it to our customer representative, he was able to get me in touch with a dedicated BMC engineer and she was able to give me the information I needed and provided the context and direction on the best approaches. I wasn't able to use the third-party engineer that was assigned to us, however, the internal resource was a great partnership to help move this along.

Neutral

We were using Microsoft and internal tools. We used the basic Windows tools that were built in.

We went with this product to centralize the deployment and to centralize the management of all of the workloads.

Some of the installation components were really complex. I'm more on the infrastructure-based side of Control-M, I deploy it and then get it ready for functional use so that the application developers, script developers, and workload developers could easily access it. It took me three weeks to figure out the requirements for getting the SSL certificates as the documentation wasn't really clear on what those requirements were. Once we figured it out, it was simple, however, the support staff couldn't give me the right information to understand what was required.

It seemed like there was a gap in expectations on what was required for certificates. In terms of the installation overall, it wasn't clear what each variable or what each configuration point was referring to until we were well versed with how everything functioned. Then we were able to say, "Oh, this is what that field meant and this is what was required here." However, during the installation process, there was very limited information on what was being asked at each configuration point.

In terms of strategy, there was a challenge with the customer. I was the third or fourth resource that was brought onto the project. The first three people that handled it, internally and externally, had trouble figuring out what the expectations were. I was handed the baton at the last moment. I had to tie up loose ends and try to get this up and running for the CIO before he started to send up red flags to BMC.

We had an integrator, however, setting up the timing with the integrator was a challenge. What I got from my company and the general expectations weren't clear. When I did get clarification, I wasn't able to get ahold of the contractor since he required a week or two weeks lead time. We then ran behind based on the lack of information I got. Setting up time and requirements was a challenge.

I'm also a contractor working for a customer. Being a third party, trying to work with another third party with minimal information from the client, was just a challenge all around.

There was another team handling the pricing. I'm not sure of the exact costs. 

Our customer chose this solution. 

We do not use the Control-M Python client and cloud data service integrations with AWS and GCP and we do not use Control-M to deliver analytics for complex data pipelines yet.

We haven't gone into production yet, so we haven't rolled this out to all our customers. We're still testing the features and we'll be starting the UAT in two to three weeks.

Right now, we're still in the early stages of rolling everything out. We've gone through the testing in our development environment and in QA to make sure things are good. Now, we're testing performance in UAT internally, and then we'll have customer validation within a few weeks before we go into production.

The solution will play a very critical role in day-to-day operations. However, it'll be at least two months before it becomes critical. Right now, it's still being implemented and evaluated.

It is pretty flexible on various cloud solutions, working with different cloud technologies and platforms. I would say potential users should take a look at it. It does provide a lot of flexibility, especially with the application and integration component that they have. The developers seem to really be able to get what they need out of the AI or the application into an integrated product or feature set.

Before installing Control-M, have a sit down with the Control-M solutions engineer and make sure you share with them all of the details of what you'd like to accomplish before deploying the solution. My client just said, "We want this" and they didn't give us the details about what they were looking for. We ended up having to redesign a few features, as those items were not clarified as part of the installation. When I was brought on board, the customer didn't mention they wanted HA, so that came later. At that point, we had to reinstall and add more servers.

The person who signed the contract was focused on MFTE, which is the enterprise file transfer tool or managed file transfer tool. However, later, the architecture team decided not to use that and go with another tool. Due to that decision, the client could have gone with a SaaS solution instead of the on-premises solution to Control-M and saved a lot of time, money, and hassle on deploying the on-premises infrastructure. So my advice to others is to make sure that the needs and the functional usage of the tool are identified clearly before purchasing or implementing the tool.

I'd rate this tool ten out of ten. It does what it says it does. 

The major use cases we have are batch processing and MFT. We are heavy users of the MFT plugin.

One of the benefits of Control-M is that it's helping to give business users visibility into and control over their jobs, and freeing up IT personnel to focus on other operations. Here, I'm mainly thinking of MFT. Our MFT end-users did not have access to our prior MFT tools at all, so they couldn't see the jobs. They would just request a job be built and then we would publish job reports so that they could see what was out there. Now, in Control-M, we're able to give them job-control access. We still lock down the building of file transfer jobs, but they now have the ability to see a job and see how it's built. They can run a job and hold a job if they need to.

But even for some of the batch jobs, we've written some orderable services that are allowing them to run jobs on-demand, jobs that they used to have to log in to a server and go through a menu to do. Our business users definitely have much higher capabilities in our product now.

And while we are primarily on virtual servers, we are in the process of standing up some agents in the cloud. We have our first agent in AWS up and we're getting ready to do some testing on it. That's pretty critical. There's a really big push within our organization to move into cloud. A lot of our next-gen apps that are going to be replacing the current ones are being built in the cloud. We have that first agent out there, but I assume there are going to be many more to follow as these new applications are stood up in the public cloud. Today we're on-prem, but I definitely envision us moving the entire Control-M stack to the cloud. Eventually, it will be in the cloud and we'll just have a couple of agents on-prem, versus being on-prem and having just a couple of agents in the cloud.

Control-M has also helped to make it easier to create, integrate, and automate data pipelines across on-premises and cloud technologies. It's due to the ability to orchestrate between workflows that are running in the cloud and workflows that are running on-prem. It gives us the ability to have end-to-end workflows, no matter where they're running.

The automation is one of the most valuable features.

New plugins could be tested better. We've had a lot of problems with the MFT plugin. We've been working through a lot of issues with BMC on it.

The functionality that has existed for long periods is very stable. But the problems with the MFT plugin specifically, and problems we've had with MFT in general, have unfortunately caused the entire stack to be affected enough that our end-users couldn't even log in to the application. 

I wish we would have known better about how MFT impacts the application as a whole, and I wish they would have done more load testing around that. That seems to be where most of our issues have been. The issues have been so bad sometimes that the entire app goes down, not just MFT.

I've been using Control-M for about two and a half years.

The stability of Control-M has Not been great. A big thing we've been trying to work on with BMC is observability. Modern applications should be observable and resilient, but we're finding that sometimes Control-M is not very resilient and many times Control-M is not very observable. We're working with BMC to try and figure out how we can externally monitor this application. 

We are using Dynatrace because of the problems we've had with Control-M. If we stood up Control-M and never had any problems, we probably wouldn't be too worried about being able to observe the processes and the queues and the communication between processes. But because we've had so many problems, it has forced us to dig in. We can't wait for a problem to happen and wait for a week for support to tell us how to fix it. We can't do that in a production environment. We have to know before a problem happens so that we can be proactive and not reactive. That's been a big struggle that we're continuing to work with BMC on.

It's pretty scalable. You can stand up a ton of agents and you can stand up a ton of servers, if you need scheduling servers. Scheduling and agents are definitely very scalable.

There isn't the ability to really scale the EM (Enterprise Manager) a ton, although the GUI can be scaled somewhat. I don't know how much of a need there is to be able to scale the EM. We don't seem to have issues on the EM side, for the most part.

We're definitely having issues with the gateway between the EM and the scheduling server, but BMC is telling us that it's because we're running too many file transfers on the scheduling server. They say that if we stand up more scheduling servers, that should resolve that issue. We'll see if it does, if we still have any issues after we spread the load of MFT, not only over more agents, but also over more schedulers. If we still have issues after that, I think that would mean you're pretty limited in how you can scale your EM. That is the one thing about which I'm not sure how well it scales.

Technical support is very back-and-forth. That's one of my gripes about the support. We open a case, they ask us for logs, we upload logs, and they come back and ask us for something else. 

At times, there isn't a lot of what I would call working together with them. We do now, but that's because we had a ton of support cases piling up and we started escalating with their internal leadership. Now, there are weekly meetings between our leadership and their leadership and our account managers, as well as weekly meetings with the support team and the dev team, to talk through our cases and any updates on them.

It took a lot of pushing from our end to get them to work with us. Otherwise, they just asked for logs and then we were waiting for a couple of days for them to look through all the logs and get back to us. We can't be doing that, especially if the issue is a production problem. We can't just upload logs every time we open a case and wait around for two weeks to get an answer.

Another gripe is that they're very siloed in what they know. Something that I've been asking for for a long time, from BMC, is somebody who can take a look at our environment as a whole, and not just in pieces. Every time we open a case with support, they want to assign it to a specific area. If it's a problem with the agent, then an agent person will look at it. If it's a problem with the EM, then an EM person will look at it. But nobody is looking at the environment as a whole. That's an issue because a lot of our problems, as I've mentioned, with MFT, are impacting the entire environment. It's not just one component. It's the entire environment and how those components relate and how they communicate that have been impacted. Nobody has really looked at the environment as a whole, in support. I think it would benefit BMC to have more experts on the entire application and not have everybody so siloed.

Neutral

The initial setup was a little complex, due to some of the requirements. It requires that you have C shell as it doesn't work with the regular BASH shell. There are some old mainframe requirements that have carried through the product, even though we don't run it on mainframes. For example, the user that you use to run it has to be under seven characters long. We had to modify the account we use because the name was too long.

We're still really trying to get our environment squared away. We started two and a half years ago, but we've got a laundry list of applications that we're migrating out of and we've only completed one of those migrations. We're having to modify our architecture now because of the load that we are running. I'm working with professional services at BMC to review our existing architecture so that they can give us a BMC-supported design recommendation.

One of the competitors we are migrating from is Broadcom/CA. Broadcom bought a couple of products. They own both AutoSys and Automic, and we are migrating out of both of those solutions. AutoSys has been pretty straightforward to migrate into Control-M because the job configuration is pretty simple. However, the Automic workflows are very complex. They utilize certain features that only Automic offers, things that we can't replicate in Control-M. That is causing a lot of issues and has caused us to put that project on hold for the time being, until we can work through some of the problems that are being presented. We've been migrating Broadcom for at least a year now.

Some applications are pretty straightforward. MOVEit is an example of one that's a pretty straightforward conversion. However, another tool we have, Diplomat MFT, has a backup file structure that is not what the conversion tool was expecting. We ended up writing a custom Python script to do that conversion for us. The ease of migration really depends on what application you're migrating out of. It could be very complex or very easy.

The migration process is a very high concern. We selected Control-M due to the ability to migrate everything into it and have everything in one tool. If we can't get our migrations completed, then Control-M will just be another tool on top of all the other ones that we have to support.

We used VPMA for the deployment. Our experience with them went pretty well. They're definitely very knowledgeable about the product

I don't know that they, or really, as I said earlier, even BMC had all the knowledge around how MFT could impact the application as a whole, back when we originally bought this. MFT was very new back then. VPMA did their best and guided us as much as they could, but I just don't think the plugin for MFT, specifically, was very mature yet. There were probably a lot of unknowns there.

We had a pre-sales team from BMC that helped us in the very beginning, before we worked with VPMA. They were nice, but I wouldn't say they were very knowledgeable. They had a very surface-level knowledge of the application. They didn't know anything that was deep. They would have to find out for us and get back to us.

It's not my realm, but I would assume Control-M has not helped us realize any savings on renewal costs after switching from Broadcom. The cost of an agent is significantly higher for Control-M than it is for Automic or AutoSys.

We are paying way more for Control-M than we've paid for any of our other scheduling tools. We have an inside joke that Control-M is sold as the "Bentley" of schedulers, but we feel that we got a "Pontiac" because it's falling apart half of the time.

BMC has two licensing models. One is where you pay by job execution and the other is where you pay by endpoints. I'm sure the specifics vary depending on the customer, but we opted to go with endpoint licensing. I'm not sure if that was the best decision, knowing what we know now.

With endpoint licensing, we pay per server. That means it behooves us to run as many jobs as we can on each of those servers. But we're very much finding that even if we make those servers very large and give them a ton of resources, they're still not able to perform because Control-M doesn't scale very well vertically. If you make the agent bigger, if you double the CPU and RAM, that doesn't necessarily mean you can run twice as many jobs. It's going to choke in other areas. 

We will see if we end up switching our licensing model. I think the endpoint licensing model we chose is quite a bit more expensive than an equivalent model where we would pay per execution. We would definitely have to change a lot about our environment if we were to change our licensing model from endpoint to execution, because today we give all of our end-users the ability to run jobs on-demand. If we were to change our licensing model to be based on executions, we would probably want to restrict that a little. 

The way you license is a very large consideration when moving to Control-M.

We really haven't taken advantage of some of the features that Control-M offers yet. The main thing I'm thinking of is SLA management. We haven't implemented that yet on a lot of our business-critical workflows because we just lifted and shifted everything into Control-M from the old app. As of today, things are pretty much equal until we are able to implement some of those additional features.

There are capabilities that Control-M offers that are good and I can see it being a very good product. BMC, as a company, has some maturing it needs to do in a lot of its processes. They have a very good sales team, but a lot of things after that can use some work.

We definitely haven't bailed on it, but I've heard a little bit, back and forth, from people at BMC that they might not be too upset if they lost us as a customer because we've been having so many problems. We've been on them about helping us get this environment corrected and functioning as we expect it to. But in a year from now, it's possible we could be in a really good place. I'm excited to see where it all goes.

I believe that the API should be upgraded with security control from the DM. There is Currently no security for the app API solution.

I have been using the solution for more than 10 years.

The solution is stable. I can say that in the previous version there was a problem. However, it is a stable solution.

The scalability of this solution is very good.  The current solution is used wide spread in my company, but I don't have any plans to expand.

I rate customer service and support a ten because it is the greatest.

Positive

I used a different solution called Computer Associates. I switched because my client switched to that solution. I never went against the solution or suggested to switch over again, because I like BMC.

The solution is complex, but it is very easy to administrate all the components from this solution.

The administration is currently done by two people. 

It pays for itself. In the last two years, I switched for mainframe to distribute systems. 

I switched to this solution within the last year. I switched from the servers payment package to the job payment package, and it is very expensive. 

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