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.

The setup of the current version of Control-M, overall, is very easy. The upgrade is in-place. With one click the agent upgrades, the server upgrades. The only point, as I mentioned, with upgrading, is that we needed a separate database update. When we upgrade our Control-M server, the database server should be upgraded at the same time.

The initial implementation in my current environment was in 2006. When we took over we just upgraded it. After that, we implemented two more Control-M Servers in this environment, as a PoC.

The amount of time required to implement it depends on the environment we are working with. In this environment, we have two production servers, four QA servers, and two testing servers. We have eight Control-M servers, three Control-M Enterprise Manager servers, and more than 400 agents. It depends on the change process. In our change process, we first need to upgrade our QA and test environments. Once that is done, we can go for the production environment the next day. After that, over the next seven days, we update our Control-M agents. Some of the upgrades require downtime. In four to five hours, we could easily update everything, but it's dependent on the downtime and the customer requirements.

When we upgraded to version 20, first we implemented it in our QA environment and we tested the new version in our test environment for three to four months. Once we see there are no bugs, we implement it in our production environment. We've seen a lot of bugs and BMC has had to produce some patches that we have had to apply in our environment. That is why we approach it the way we do in a QA environment, and wait for three months, and then go to production.

When we moved to Control-M, we used the Control-M Conversion Tool. It's a very important tool. It gives us an idea of where we stand. If I'm going to move an old environment to a new environment, it helps us with any errors so that we can rectify them.

I was involved in the deployment and initial setup of the solution right from the beginning.

We had jobs and workflows running within the first day. That was pretty good. We don't use the Helix model, however, there is a Helix model you can purchase, in which everything's hosted by BMC. You can be up and running literally in hours which is reasonable. There's a learning curve, however, if you do not get some value out of it within two days, you're probably doing something wrong.

At the time, there were only two of us deploying the solution. Today there are only three of us.

It's business-wide. Everything from data to marketing, to finance, even though it probably wouldn't make sense to anybody else, it touches everything. It's deployed across Windows, Linux, containers, VM, cloud, et cetera.

If anybody has a use case or wants to learn more about it, we'll show them. Anybody in our organization can get basic access and can tinker around in an alpha test environment. This includes non-technical people. We have non-IT people that use it.

If they can self-service and maybe design some parts themselves, that's a huge win right there. We have a very open model of deployment.

There are occasional patching and vulnerabilities that come out. Most of the patching nowadays can be automated if you're using the Helix-based solution. A lot of that is handled by BMC.

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.

I was involved in the process of evaluation and implementation, and now, I am also involved in monitoring the development.

Its implementation is among the simplest I have done. SAP tools are more complex. Helix Control-M was live within a short time. We configured it in 2-3 days. We tested it one day, and the next day, it could go live with a process right away.

Our implementation strategy was to divide the implementation into stages. We did it by area and configured the jobs. That was it. We had workshops to understand what the user wanted, and then we did configuration in the test environment to see that what they requested is actually what is being done and executed in that environment. We then moved that to production, so for each user group, we followed: demand, distribution, supply, and production. It was super simple.

In terms of maintenance, from time to time, they notify us that there are upgrades. We receive notifications about agent upgrades, tool upgrades, and some system maintenance. Because it is a SaaS, they tell us everything. We coordinate internally so that if there is a process that is running at that moment, that program is executed manually.

For the server and agent part, we have outsourced the maintenance to the CJG company. They are in charge of doing that maintenance. On the operations side, there is a person in charge. Every time something happens, he is in charge of the event.

In terms of our environment, we are a mixed shop. The majority of our products are on-prem. We have a Nutanix cluster in our data center, and that is where we host the majority of our things. We have maybe one or two devices on AWS. For Azure, I know that we have a license because it comes with our enterprise Microsoft 365 license, but I do not recall having any hosting there.

For migration, they have a migration tool that makes it very easy. You can run this migration tool, and it will export all your current jobs in a JSON file. It will try to import them on the tenant in the cloud on Helix Control-M. We faced a few challenges here and there because at the time we did it, some features were missing in Helix Control-M or were not supported, but they were supported in Control-M. We used to have dual endpoint profiles for the MSP file transfer or the ASP. FTP jobs have profiles where the server address, user password, or key gets stored. In Control-M, you could have a single profile with two endpoints. You could have Host A and Host B in a single profile. That was not supported with Helix Control-M at the time we decided to migrate, so we had the challenge of converting all those dual endpoint profiles into single endpoint profiles to be able to be imported. I know for a fact now that it is no longer an issue because they now allow you to create dual endpoint profiles in Helix Control-M, but it was a challenge at the time.

Fixing things here and there and making it compatible took about six months. Those six months were not just because of how hard it was to migrate. It was a combination of the challenges of migration and other tasks that we have not been doing because we could not afford to have a person dedicated entirely only to Control-M. Effectively, the time dedicated exclusively to the migration was two and a half months, but the migration was distributed in a six-month calendar because of other duties and tasks that I had to perform.

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.

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.

The initial setup was straightforward. It was easy to get going, easy to install, easy to create workflows consistently. There wasn't a huge learning curve. We learned as we went, but it was pretty easy to learn the product.

Our deployment took about a month.

The integrated guides and how-to videos in the solution’s web interface, for helping get to full productivity with the solution, are very helpful. People watch them. They need to be a little more in-depth and they need more of them, but what they have is a good start.

We have about 120 people in our company who are actively using Control-M. They range from developers to operations personnel, financial analysts, marketing analysts, and data scientists. We have a team of three for day-to-day administration of Control-M but they do more than just Control-M.

We are trying to import from Control-M version 7 to Control-M version 9, but have experienced a major problem with its new features (database-related stuff). We are slowly fixing this as we go, with the help of BMC. Right now, we are doing this process step-by-step, but we can't upgrade everything to the latest version. We can only move everything to Control-M version 9.5.

Initially, we were first-timers doing the cloud. We had so many trials and errors. For importing, we created virtual machines in AWS and set up a lot of automation. However, we needed a static IP address for Control-M. So, we had to start from scratch to create new virtual machines with static IP addresses.

We are currently importing step-by-step. We still have two mainframe servers that we need to do and should be done by the end of August.

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.

I've never had to set up a Control-M environment. But there is a certain level of complexity when you do your upgrade, even though they market it as "upgrade in place." As long as you're on version 9, you can go from 18 to 19 to 20.

I was not part of the implementation at my company but I have implemented several Control-M projects. The initial setup is straightforward.

First, we download the files from the BMC site and then start the installation. This involves running the setup files and if there is any error, you have knowledge base articles and you also have AMIGO support if you enroll in it.

The deployment can be completed in a day or two, including the Enterprise Manager (EM), servers, and agents. There are also conversion tools that are available to assist with creating jobs.

Our implementation strategy began with installing the Enterprise Manager first, and then the server, and then the agents. We would raise a support ticket so that whenever we had any issues, we could reach out to them.

I did not look at the interactive guides or videos that Control-M provides for reducing time to full productivity. I had all of the documentation handy but I did not refer to any of the videos.

For the MFT part, the initial deployment took about four months because we had to convert all our jobs and all our scripts to Control-M. It was not easy because we had a homemade solution, so there was no conversion tool for it. That meant we had to do it manually, with some scripting on our side.

In terms of our deployment strategy, for SAP we started with one SAP system from among the many we have. We started with a complex one, which was Redwood. The version of Redwood we had was not supported by the Control-M importing tool. Again, we had to do it on our side without a conversion tool.

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 was not there when it was purchased and installed. It was already there when I came here. At that time, it was version 8. From 2017 onwards, I've been doing all the upgrades. Currently, we are on version 9.20.

I'm actually in the process of doing an implementation right now. I'm replacing our current production system. We're replacing EOS, actually, therefore, I'm doing a straight install of everything on the new servers. It is very straightforward. The install is not really difficult. It's fairly simple if you understand how databases work and whatnot. There's really no problem doing it.

In my case, I can bring up a Control-M server within hours. I only say that as I've done that, as we were not DR prepared back during Hurricane Sandy. I had to bring up a production version of it in Cleveland, in our DR site in Cleveland. Within 24 hours, we were up and running. Therefore, if you need it done fast, it can be done. It's just a matter of, are you willing to put in what you need to put in to do it.

It's a fairly easy install, really. I personally have never had any training on Control-M. Other people in my organization have had training. That said, I'm the one that put it in and I'm the one that read the manual. That's where I got all my information from, was from reading manuals and whatnot, and directly working with it.

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.

There was no particular problem for us in regards to the implementation process, as we had BMC to assist us. We have a very large environment and our migration took between twelve and eighteen months. We have thousands of agents and many Control-M environments.

We did not follow a particular implementation strategy.

The initial setup was easy. BMC provided all the documentation before starting. They did it in the development environment and targeted various applications. They showed us what they were doing before they implemented it. So, we were coordinating with them.

Deployment took three months.

It is very easy to set up a PoC. If someone just wants to do a quick test, it is very easy to do. Assuming that everything is in place, it is quite easy to test or set up cyclic jobs.

We did the setup twice. The first time was a migration from another system, which was not BMC. That took three months, which was still pretty fast, and it was very successful. The second time was an upgrade to version 19, and that took about two months, and it was also quite successful. From my perspective, the solution was very good as far as upgrades go. We didn't have any major issues, before or after the upgrade.

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

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.

I was not involved with the initial setup. That was before my time.

I wasn't involved in the initial setup of Control-M.

I was not involved with its deployment. In terms of maintenance, it is not maintenance heavy. We just happen to follow the best practice of doing a reboot every month and applying the patches.

The upgrades are a bit complex. The last time we did an upgrade, it took several hours.

The initial setup was straightforward. It is really easy to understand the architecture, and even install it. Based on some internal rules that we have in-house, Control-M fits well with our architecture.

It took a day to install and a week to implement. After one week, we had some jobs working and were able to get the users to see, control, and monitor the jobs. We had it deployed and working in less than a week for Windows, Linux, and HP-UX operating systems as well as VMS.

While the difficulty of the initial setup can vary, the implementation itself is pretty straightforward.

I'm not sure exactly how long the deployment takes.

I'm the senior services manager, and overseeing the deployment of Control-M is part of my job. I did not install it, but I supervised the team. It was straightforward because we all got our BMC certification before the deployment. Our team included me and two technicians. We also had a DBA around to integrate the database.

Its initial setup was a long ago. It was very simple. The bank had about 6,000 offices, and it took about eight months to automate the whole batch processing.

At that time, people were not ready to use automated processes. The most difficult thing was to change the mind of the people. When we started with automation, people thought that they will lose their jobs with this kind of tool, and it was very hard to change the mind of the people. Using Control-M was very simple, and it was easy to use Control-M to automate manual jobs. From that stage till now, all new systems are syncing with Control-M, and all new developments are integrated into Control-M.

The upgrade process is great. They have a whole department with their AMIGO program, where you can have someone walk you through it. We have upgraded to 9.18. When we go to 9.19, it will be real quick. It should be almost hands off from what I understand, and that is what I am attending this BMC event to find out about: the upgrade process. When we did the last one, it was real easy. I understand it will be even easier going forward, so I'm happy with that.

The initial setup was done before I joined the company.

The initial setup is pretty straightforward, with all the necessary details mentioned in their well-written guides. They have guides for utilities, parameters, installation, administration, etc., which makes it easier to adapt for anyone who is new to the tool (of course, prior understanding of OS/DBs/networks/etc. is expected for you to understand it. ;) )

Initial setup and installation of Control-M does have challenges, but BMC has good technical support. Related documentation is also available online. Once you are familiar with these, setup becomes straightforward.

Control-M is easy to install and maintain. There are not a lot of steps required to upgrade or downgrade from one version to another. With other products that I've been using, it is difficult and complicated to upgrade because there are a lot of confusing steps. But with control-M, you need only follow the onscreen instructions.

The length of time required to deploy depends on the customer. The scope and complexity of the client's requirements dictate the amount of time it will take to complete. For example, we can deploy for a smaller customer in one week. However, for a large retail customer, it could take a month to complete.

We have one client right now, where we are upgrading from Control-M 2018 to 2019, and it is going to take us almost three months to complete. Part of the reason it takes this long is that when you try to upgrade a production environment, it's really difficult to get a window to perform the upgrade or the installation or the modification. That said, it's still easier than many other products.

The initial setup of this solution is straightforward, but for new users, I would recommend engaging a third party to help you set up and learn the ropes.

The initial setup of this solution is very straight forward. BMCs AMIGO program is there to walk you through the process.

It gets a bit technical when you need to setup MFTs, but at the same time, it's not rocket science either.

The setup was straightforward.

It was quite simple since Control-M has a very user-friendly GUI. That made it fairly easy to relate with the business and convert it into something which looks familiar.

The initial setup is straightforward.

If all the prerequisites are ready, a full-fledged setup for a single system would take 15 to 20 minutes to deploy.

Normally, we deploy with high availability so it has an uninterrupted service, even if a server goes down.

Initial setup was straightforward.

Initially, the setup was a bit complex when trying to understand what all the features and settings do. However, when we explored it more, then we understood it and became comfortable with it.

Initial deployment took a couple of weeks. But once explored more the more convenient

The initial setup was complex, because I wasn't used to it.

It's straightforward to use Control-M compare to other tools. Easy to migrate from other tools to Control-M.

Its setup was straightforward. It was easy for us to host it up because it is a service, and we just hosted it up in the cloud, and it was there.

Its deployment was very fast. It took less than a day. I had to run some commands. I went through the documentation on BMC's website, and it was good.

The initial setup is straightforward. It is relatively easy to upgrade the tool.

We moved everything, including the database. Now, it is the heart of our operations.

It has some complexities because it is a complex environment. It has a three-tier environment on-prem, and one has to establish a secure connection between these entities, which is not easy. The first one is the master server console. The second one is the main engine that determines the scheduling process, and the third one is the agent. Agents have to be deployed on different client machines.

The initial setup was fairly simple. Once all the servers and DBs were set up, the installation of Control-M Enterprise Manager, Control-M Servers and Control-M Agents was painless.

Initial setup was complex. We have integrated Control-M with many applications using some complex scripts for meeting our business needs.

The initial upgrade setup (for basic functionality) is not difficult.

I would like a simpler setup. We have had some challenges implementing, having to play with some different settings. In order to get it to do what was wanted of it, not alerting too often nor giving false alarms, it takes a bit of setup. Maybe something a little easier to use for setup would be nice.

Other than creating the jobs in Control-M once it was set up, I was not involved.

Setup was easy and there is a migration tool available for most platforms.

Upgrades are pretty straightforward. There's not really that much mystery to them.

Initial setup is quite easy; a wizard-based installation process.

I did not set up Control-M in my organization, but the setup is straightforward. You just log in with your credentials and everything is already setup for you. You can access things in line with whatever authorization you have. 

Its implementation is pretty fast and easy. The duration depends on the size of the infrastructure. It could be implemented between one to three months.

We used a consultant for the deployment and the initial setup was pretty straightforward and easy.

The setup of Control-M is okay. It was done before my time by the vendor or a vendor agent. A third party authorized by the company itself helped with our implementation.

Very simple to install.

The initial setup is very straightforward.

The initial setup was straightforward.

We've been using the product for quite a long time, so reviewing initial setup wouldn't be applicable to current times. I feel the setup of v9 is quite straightforward.

It is easy to set up and has clear information and support.

Out of the box, most clients will be fine installing Control-M with all default options. You have a choice of the packaged PostgreSQL database solution, or you can opt to use MS SQL It is therefore a relatively simple setup.

The initial setup isn't too difficult. It's quite straightforward. We haven't had issues with the implementations that We have done with our clients. The implementation is pretty fast. It depends on the size of the infrastructure, however, it could be implemented between one to three months. It happens very fast if you compare it to other solutions.

The initial setup was easy. The deployment took two weeks.

The installation is panel-driven and can be used by a relatively inexperienced technician to install it successfully.

You cannot be an airplane pilot without education; with the right education and training, the solution does what it has to do and makes it fantastic.

It is a complex product but for the most part, setup is reasonably straightforward. Some add-ins such as the BPI module can be quite challenging.

The setup was straightforward.

Initial setup is easy to understand for any end user who does not have any prior knowledge of the product.

While I was not involved in its original implementation from scratch, I did arrive in the early stages and once I had a grip on the functionality and its tools, it was fairly easy. I am sure the installation and first implementation came with challenges.

The setup was straightforward, i.e, in terms of CA NSM.

We had do perform several install configurations until we finally achieved the stability we required.

The installation was quite simple. There was very good documentation.

Yes, considering our then and there needs setup was bit complex and time consuming. As it was quite obvious due to the huge organizational size.  

Straightforward.

I have seen initial setups that are both straightforward and complex.

Setup was very simple.

Initial setup was easy to understand.

Other teams are in charge of the installation process.

Yes, I did. We change because of the integration facilities other market tools and to ensure a safe delivery of the company's files.

The installation for this product was not so easy. I found it quite complicated.