What is our primary use case?
We are utilizing both MOVEit Transfer and MOVEit Automation to support two primary use cases.
The first use case involves using MOVEit Transfer as an SFTP server or location, as well as for ad hoc large file transfers. In the second use case, we leverage MOVEit Automation where files are uploaded to MOVEit Transfer and then transferred between our internal systems and vice versa.
How has it helped my organization?
We utilize MOVEit Transfer for file exchanges by creating User accounts, allowing secure file transfers. If someone doesn't need automation and prefers to send files sporadically to external recipients, we rely on the ad hoc file transfer feature. This is particularly useful for sending large files securely, which can't be transmitted via email due to size restrictions.
Additionally, we can request file packages, which is especially helpful during acquisitions. Before the acquisition, we use the ad hoc transfer capability in MOVEit Transfer to securely transmit large files. After the acquisition, SSO based logins are used, but the instant capability to send files securely to an external party was un-parallel without them installing software on their end.
For automated data transfers we use MOVEit Automation. It supports a variety of connectors like Azure Blob and AWS S3, though we primarily use it for Azure Blob. Initially, we used custom scripts within MOVEit Automation for Azure Blob integration, but with built-in support now available, we leverage the connectors for seamless connections. MOVEit Automation is extensively used across our company and has proven to be incredibly beneficial.
What is most valuable?
I appreciate MOVEit’s capability to transfer extremely large files. One instance involved successfully transferring a 70-gigabyte file, and although we haven’t attempted anything larger, every time we've needed to process a large file, MOVEit has handled it without issue. This ability to manage such large file transfers is something I really like about MOVEit Automation.
Another feature I value is MOVEit Transfer's logging functionality. Previously, when we used a Linux-based FTP server, we had no visibility into when files were dropped, and we lacked the auditing and logging capabilities. When sending files to vendors, their systems would sometimes claim not to have received them, and we had no way to verify or trace file delivery. MOVEit, however, provides robust logging that tracks service accounts and IP addresses, showing details like multiple file downloads. You can see who downloaded a file, the system account used, and how many times it was downloaded—this level of traceability is incredibly powerful.
What needs improvement?
We've faced some challenges with MOVEit as well. During the initial setup, we encountered issues with the MOVEit Transfer Gateway component, which operates in the DMZ. It frequently went down, causing disruptions in SFTP connectivity for most of our vendors. As a result, we had to implement extensive monitoring to ensure we received instant visibility whenever the gateway failed, allowing our system admins to respond quickly and restart the service.
Another issue stems from the fact that MOVEit is a Java-based product, and it seems to have a memory leak, leading to system slowness and unresponsiveness at times. To mitigate this, we had to schedule weekly restarts to clear out memory, which remains an ongoing process because, without these restarts, we wouldn't have a responsive system. These are two key challenges we’ve encountered with MOVEit Transfer.
Regarding MOVEit Automation, a job is typically triggered as soon as a file arrives, and it looks for the file, matches it, and moves it to the destination. However, if the expected file doesn't arrive, say on a Tuesday at 8:00 AM due to a job failure or someone forgetting to place the file, we need better visibility. Currently, MOVEit Automation offers limited capabilities for this scenario. We rely on error codes that indicate when no file was found, and we've built an email alert system around this, but for complex schedules—like jobs running on the 10th of each month—the system becomes ambiguous and occasionally generates false alerts. While MOVEit is not designed as a notification system, better alerting features would be incredibly valuable.
I'd also like to see Google Cloud connectivity in future updates. MOVEit has been expanding its connectors, initially supporting Azure, followed by AWS, but connectors for Google Cloud Platform are still missing. Adding this capability would be a great enhancement.
Another improvement I'd welcome is the ability to interact with message brokers. Currently, MOVEit handles file transfers and supports HTTP calls, meaning you can invoke APIs or download files over HTTP/HTTPS protocols. However, I’d like to see support for messaging protocols like MQ or AMQP. These protocols would make the platform more versatile, particularly for integrations where we need to pull messages from a queue and create files. IBM offers this capability, and if MOVEit could add it, it would make the product even more feature-rich and useful for our needs.
For how long have I used the solution?
I have probably been using it since early 2018. It has been about four years.
What do I think about the stability of the solution?
What do I think about the scalability of the solution?
We don’t run many nodes, but we keep adding a lot of jobs to the system, and so far, MOVEit has proven to be scalable. We haven’t reached a point where we needed to add significant hardware resources. The system is still running on the same setup we implemented four years ago. The only adjustment we've had to make is adding more storage. Although we use MOVEit Transfer for transient storage, people tend to drop files and forget to clean them up. Since many of these files are large, we’ve had to increase storage capacity to accommodate them.
For MOVEit Transfer, we currently have about 300 users. In contrast, MOVEit Automation has a much smaller user base—around 10 people—primarily developers who log in to create and manage automation tasks. This includes both our development and operations teams, as they are the ones who need access. However, MOVEit Transfer is widely accessible to internal and external users, with more people requesting access regularly. The user base continues to grow, as everyone finds use cases that benefit from the system. It's one of the systems in our organization that’s expanding rapidly in terms of usage.
How are customer service and support?
I initially submitted a few tickets regarding MOVEit's capabilities, and our system engineers may have created a few tickets as well. Since we have separate logins, we can't view all the tickets holistically. However, I'm confident that both I and the system engineers have reached out to support. Overall, the response from their support team has been pretty good.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
I haven't had much experience with FTP tools beyond MOVEit, but prior to using it, we worked with several IBM middleware tools like IBM DataPower. However, those tools couldn't manage large files effectively, which is one reason I appreciate MOVEit Automation.
Before transitioning to MOVEit, we were using a Linux-based SFTP server. Essentially, it was just a Linux virtual machine running an SFTP process, not a full-fledged tool. We simply enabled the SFTP service on the Linux machine and had others connect to it. This lightweight setup could be done on any machine. Eventually, we replaced that system with MOVEit, which has been a significant upgrade for handling large file transfers and more complex integrations.
How was the initial setup?
I wasn’t involved in the infrastructure side of things, but from what I’ve seen, MOVEit is a fairly easy system to set up. We have a dedicated systems engineering team that handles installations, and from what I understand, they were able to get it up and running quickly. It’s also a tool that was easy for us to learn and use, which makes it user-friendly from that perspective.
I'm not entirely sure about the deployment timeline. By the time I became involved, the initial setup and installation had already been completed. I joined once the system was already in place, and we had a quick training session—about half a day—on how to use the tool, and that was all we needed. I’m unsure how long they had been planning the implementation or how long it took to bring it online, but it seemed like a smooth and efficient process overall.
What about the implementation team?
The entire implementation of MOVEit was handled in-house.
For ongoing maintenance, we have two primary contacts responsible for it, though they aren't dedicated full-time to MOVEit. Along with managing MOVEit, they also support several other major systems. From a system engineering perspective, these two individuals handle patches and maintenance but aren’t constantly monitoring or working on the tool. They only act on issues when they arise. Based on our experience, one full-time systems engineer would likely be sufficient to support MOVEit if needed.
What was our ROI?
We saw a return on investment with MOVEit in the very first year. One of the main reasons we adopted it was that our Linux machine was located in a different data center, and we needed a solution accessible over the internet by external parties. Before MOVEit, we didn't have a tool that allowed us to host a server that was internal but also accessible to others. We had to maintain a dedicated server, and our primary SFTP server in the data center was a Linux server. Once we implemented MOVEit and decommissioned the Linux server, we effectively realized our return on investment, as we were able to shut down that entire operation.
While I can't assign a specific dollar value to it, MOVEit is clearly a better solution compared to our previous SFTP processes. Our partners are pleased with the simplified UI, and in cases where files are missing, it’s easy to check the logs and provide assistance. It’s been very convenient to prove when files were successfully placed. These capabilities have greatly improved both customer satisfaction and internal user satisfaction.
Overall, I’m really happy with MOVEit. Some users might wish for more advanced features, like file-missing notifications or more sophisticated alerts, but they may not realize how complex it is to build those capabilities. Some may think there's a better tool out there that offers everything, but no tool can do it all. Given what MOVEit already offers, we've achieved our return on investment, and it's been a solid tool for us.
What other advice do I have?
MOVEit Transfer and MOVEit Automation are quite straightforward to use. For MOVEit Transfer, one key practice is ensuring users don't treat it as permanent storage. It's best to use MOVEit SFTP only for temporary storage—meaning if someone uploads a file, it should be downloaded and cleared out by the recipient. Otherwise, file storage can accumulate quickly, given the volume of data you're dealing with.
As for MOVEit Automation, it's beneficial to establish patterns. For example, if you're handling external-to-internal file transfers, build a pattern that includes alerts or any other necessary logic in a generic way. This allows you to clone and reuse the pattern for new processes, saving time by avoiding the need to configure tasks from scratch every time. MOVEit provides the ability to take an existing task, clone it, and modify only the relevant details, which is what we do. So, before setting up your first automation job, it's crucial to plan a generic template upfront, as it will streamline future tasks.
Overall, I’d rate MOVEit a nine out of ten.
Which deployment model are you using for this solution?
On-premises
*Disclosure: I am a real user, and this review is based on my own experience and opinions.