The Hidden Cloud Dependencies in Your On-Prem File Transfers

Your on-premises file transfer setup may quietly depend on a vendor’s cloud. Audit what your architecture actually runs—using Progress Automate MFT published design as the working example.

Open your firewall logs. Filter for outbound TLS connections from the server hosting your “on-premises” file transfer setup to anything in your vendor’s cloud range. Count them. If the number surprises you, the architecture you bought and the architecture you’re running aren’t the same thing.

If you don’t have firewall logs that capture this, that’s the first finding.

What ‘Hybrid’ Quietly Became

“Hybrid” has become a flexible word in Managed File Transfer (MFT). For some products, it means workflow logic on-prem with cloud connectors as optional add-ons. For others, it means a cloud-hosted control plane paired with on-prem agents. The deployment guide rarely makes the distinction obvious. The difference matters when your architecture review tries to reason about what runs where.

Progress Automate MFT publishes its hybrid architecture and network requirements explicitly. The useful detail is what each layer owns.

The self-hosted agent is the part that tends to win over teams who swore off the cloud. It installs on a Windows or Linux box you own, sits behind your firewall and connects outbound only—no inbound ports to open and expose. The transfer runs next to your data; only orchestration and audit live in the console. You get centralized management without surrendering the execution path, which is usually the exact fear that made on-prem-only feel safer in the first place.

Reality Check: “Hybrid” is not a deployment model. It’s a description of split control. If workflow orchestration lives in a cloud console and agent updates run automatically, you’re running a cloud-managed platform that executes locally.

That’s a real architectural pattern with real benefits. The  trade-off is a genuine dependency on the vendor’s cloud—fine when you have documented it and planned around it, a problem when you have not. The danger isn’t running a hybrid product. It’s running one without knowing you are.

What Automatic Updates Actually Pull

Auto-update mechanisms are how vendors push patches without bothering you. They are also how cloud dependencies arrive in the architecture without an architecture review.

For Automate MFT, the documented update path is the agent update mechanism (configured per agent in the auto-update settings): updates can be applied automatically, on a schedule or on demand. That’s transparent because Progress publishes the update options and the agent topology.

Here is where the value shows up. The old workflow is a PowerShell job on an app server: pull from SFTP, decrypt with PGP, unzip, rename, copy to SMB and email Accounts Payable when the file misses its SLA. Automate MFT moves that from “the script, last edited before its author left” into a managed task: point-and-click workflow design, prebuilt compress/decompress and encrypt/decrypt steps, conditional logic or custom scripting where needed, calendar-aware schedules, version history, run history and audit trails.

The point is not that auto-updates are bad. They can patch faster than change management. The point is that “automatic” belongs in the architecture record. When workflow definitions, endpoint credentials, schedules and agent binaries live in a managed platform, your review has something concrete to inspect instead of a folder full of scripts named final_v2_REALLY_FINAL.ps1.

Deployment Modes Aren’t Interchangeable

Across hybrid MFT products, marketing tends to treat deployment modes as interchangeable. The architecture documentation usually does not.

Take inbound partner transfers. That is an endpoint question before it is an agent question. Progress documents Automate MFT integrations where MOVEit Transfer receives partner files, then Automate MFT routes those files to internal targets.

That handoff itself is where the the details lives:

1. MOVEit Transfer receives the partner file at the secure edge.
2. Automate MFT stores the MOVEit Transfer server as a reusable endpoint with a reusable authentication method.
3. The workflow references that endpoint as a source or destination.
4. The selected agent executes the transfer on schedule or on demand, routing the file to a file share, cloud bucket, SaaS app or another MOVEit folder.
5. Centralized logs show the source, destination, run status and owner.

Now the architecture review has a path to inspect. Not “the product has agents.” Not “the diagram looked hybrid.” A file entered here, an agent executed there, and the audit trail proves what happened. No one has to be the human compliance database, reciting from memory what the logs should have captured.

Pro Tip: The vendors easiest to audit are the ones who published their architecture clearly. If the documentation describes the agent-coordinator topology, the update mechanism, the data plane and the metadata flow explicitly, you can answer the framework below in an afternoon. If it doesn’t, the framework becomes a vendor evaluation tool.

Both patterns can be valid. They are not the same architecture, and the difference matters when your security review asks where the file lives between landing and delivery. Same product portfolio, different control boundary.

A Dependency Analysis Framework

For any hybrid MFT, whether you bought it on purpose or inherited it through updates, answer these in writing before the next architecture review:

• Where does workflow logic live? Cloud control plane or on-prem server. When the cloud goes down, what runs?
• Where do credentials live? Local vault on the agent or vendor key management service (KMS)? Whose key rotation policy applies?
• Where do tasks actually execute, and what leaves your network? On an agent on-prem, or in the cloud? Separate the control traffic—management data and audit logs—from the file data itself: does any payload get pushed to the vendor’s cloud, or do files move only between your own endpoints? Document the cadence and the destinations for both.
• What does an auto-update actually touch, and can it happen without downtime? Binaries only, or also workflow definitions, connectors, policy and credentials? And does an agent update drop in-flight transfers, or roll through without a maintenance window?
• What metadata crosses borders? Filenames, partner identifiers, transfer logs and timestamps can qualify as personal data under GDPR when they identify a person directly or indirectly. If that data crosses borders, Schrems II-era transfer guidance becomes part of the review.

If three or more answers come back as “I’d have to ask whoever set it up,” the runbook needs a Saturday session before the auditor needs one.

Choosing Your Fit

The architectural question splits cleanly. Different products, different promises:

Automate MFT is intentional hybrid with cloud-management and flexible agent execution. The cloud dependency is the architecture, not a surprise. If you want a cloud control plane with centralized libraries, no-code workflow design, updates managed by MFT experts and agent pooling for resilience and load balancing, this is what you’re buying.

MOVEit Automation is the answer when the orchestration itself cannot live in a cloud control plane: closed IT environments, regulated deployments that need direct infrastructure control, and sites where an internet-dependent control plane is not acceptable. It runs the workflow engine on-premises on Windows and leans on MOVEit Transfer as the secure transfer server underneath. Same Progress portfolio, different architectural promise.

The mistake is buying one and assuming you have the other. The fix is the framework above and an afternoon with the firewall logs. If the honest answer to “where does the workflow logic actually live” is a guess, the architecture review has not happened yet.

Learn more about the file transfer solutions from Progress Software.