Share your experience using SolarWinds Serv-U File Transfer Protocol Server

The easiest route - we'll conduct a 15 minute phone interview and write up the review for you.

Use our online form to submit your review. It's quick and you can post anonymously.

Your review helps others learn about this solution
The PeerSpot community is built upon trust and sharing with peers.
It's good for your career
In today's digital world, your review shows you have valuable expertise.
You can influence the market
Vendors read their reviews and make improvements based on your feedback.
Examples of the 83,000+ reviews on PeerSpot:

Richard Meyer - PeerSpot reviewer
System Engineer at a healthcare company with 10,001+ employees
Real User
Top 10
Gives business users visibility into and control over their jobs, freeing up IT personnel
Pros and Cons
  • "It gives us the ability to have end-to-end workflows, no matter where they're running."
  • "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."

What is our primary use case?

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

How has it helped my organization?

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.

What is most valuable?

The automation is one of the most valuable features.

What needs improvement?

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.

For how long have I used the solution?

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

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and support?

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.

How would you rate customer service and support?

Neutral

How was the initial setup?

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.

What about the implementation team?

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.

What was our ROI?

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.

What's my experience with pricing, setup cost, and licensing?

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.

What other advice do I have?

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.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Alejandro Parro Jr. - PeerSpot reviewer
Presales Engineer at Bridgeway Communication System, Inc.
Real User
Top 5
Helps improve our data exchange processes and centralizes the exchange of data between our systems
Pros and Cons
  • "The most valuable feature of MFT is the security it provides for our data. MFT allows us to add additional authorization and passwords to any file attachments we send via email, and also to limit the number of times the recipient can download the file."
  • "I want to be able to use GoAnywhere to create customizable reports that I can share with the MSP containing any information related to file transfers."

What is our primary use case?

We use Fortra's GoAnywhere MFT to facilitate our data exchanges.

How has it helped my organization?

Implementing GoAnywhere MFT has significantly improved our data exchange processes, particularly through automation. This allows us to send large files as single attachments via email.

The Secure Folders feature of Fortra's GoAnywhere MFT software strengthens our file transfer security. It provides detailed information about every user who accesses the data. Granular permissions can be set, allowing some users to only upload files, while others can only download them. These permissions extend to the entire HTTPS service, including the hosted drive.

GoAnywhere MFT centralizes the exchange of data between our systems, employees, customers, and trading partners. This eliminates the need for multiple applications for administration.

The GoAnywhere MFT's UI is user-friendly. I was able to understand how the solution works in under one hour.

GoAnywhere MFT's workflow feature stands out because it doesn't require programming knowledge. This flexible feature is also easy to set up.

GoAnywhere MFT's workflow feature eliminates the need for custom programs and scripts for our file transfers. Since I started using it I have eliminated over 100 scripts.

GoAnywhere MFT's workflow feature has streamlined previously manual processes, benefiting both us and our clients. For instance, we now receive automated notifications summarizing office hours and can easily collect any valuable information from the administrator. Before implementing GoAnywhere MFT, these tasks had to be done manually at the end of each shift.

I'm familiar with the ICAP process. We've also installed it for some of our existing clients. This allows for normal operation without needing to go elsewhere. It provides various functionalities, including automation, testing on Virtual LAN Providers, and the ability to limit access based on factors like extension numbers. This means we can restrict access to confidential information, regardless of whether someone is visiting or working within our organization. The ICAP process allows for this control without hindering regular operations. We can further enhance security by implementing our internal processes alongside antivirus protection offered by ICAP capabilities.

ICAP plays a vital role in keeping malware out of our organization, especially in high-volume traffic environments.

GoAnywhere eliminates the need for single-function tools and unsecured file transfer methods. It can automate application upgrades, providing organizations with both protection and efficiency. This means GoAnywhere can launch applications for specific tasks, eliminating the need to develop custom applications that often require additional licenses. Additionally, GoAnywhere can potentially reduce costs compared to other solutions in our environment.

Automating file transfers has significantly reduced project workloads for our organization. Manual client interaction is now automated, streamlining a previously five- to ten-step process into one or two steps.

GoAnywhere helps our staff save time to focus on other tasks. By automating many manual processes that previously supported web users and ensured security, GoAnywhere frees up valuable staff resources.

What is most valuable?

The most valuable feature of MFT is the security it provides for our data. MFT allows us to add additional authorization and passwords to any file attachments we send via email, and also to limit the number of times the recipient can download the file.

What needs improvement?

I want to be able to use GoAnywhere to create customizable reports that I can share with the MSP containing any information related to file transfers.

For how long have I used the solution?

I have been using Fortra's GoAnywhere MFT for two and a half years.

What do I think about the scalability of the solution?

GoAnywhere MFT scales to meet the needs of organizations of all sizes.

How are customer service and support?

The technical support is good.

How would you rate customer service and support?

Positive

How was the initial setup?

The initial setup is straightforward and took two or three hours.

What's my experience with pricing, setup cost, and licensing?

Fortra's GoAnywhere MFT carries a higher price tag than other MFT solutions. The comprehensive features it offers justify the cost, provided we can utilize its full process and functionalities.

What other advice do I have?

I would rate Fortra's GoAnywhere MFT nine out of ten.

We have approximately 100-150 users.

I recommend conducting a proof-of-concept for Fortra's GoAnywhere MFT.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor. The reviewer's company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate