July 16, 2026

What is managed file transfer? MFT explained without the vendor gloss

Managed file transfer, or MFT, is a confusing term because every vendor uses it differently. Some call their SFTP server with a web UI an MFT platform. Others reserve MFT for enterprise platforms that do scheduling, retries, audit logging, and protocol adaptation. The honest definition: MFT is the infrastructure that replaces shell scripts and cron jobs for moving files between systems and partners. What does that infrastructure actually do?

What MFT adds over raw SFTP or FTP

A plain SFTP server is a folder with SSH access. A script or operator connects, uploads files, downloads files, and leaves. No central visibility, no scheduling, no audit trail that survives a disk format. When problems happen — a file didn't arrive, a job failed silently, a partner is accessing data from three years ago — you have no evidence.

MFT adds a control plane above the protocols. That control plane provides central visibility into every transfer: who initiated it, when, from where, which file, how many bytes, success or failure, and retry history. It adds automation: schedule transfers to run every hour, every day, or on-demand without touching a cron job. It adds intelligent retries: if a partner's server is down, queue the transfer and try again in 15 minutes. It adds protocol adapters: support SFTP, AS2, HTTPS, FTP, or others from one platform without running separate servers. It adds identity integration: connect your directory (Entra, Okta, or on-prem AD) so operators log in with their corporate credentials instead of static passwords or SSH keys.

How a transfer actually flows through an MFT platform

An operator or integration system creates a transfer request: send files from Folder A to Partner B. The MFT platform queues the request, validates it against the configured rules, and triggers the transfer based on the configured protocol and delivery method. For SFTP: it connects to the partner's server using the pre-configured credentials and key, uploads the files, and polls the partner's inbound folder for a receipt file if one is expected. For AS2: it signs and encrypts the payload, POSTs it to the partner's HTTP/S endpoint, and waits for a Message Disposition Notification confirming receipt. For HTTPS: it sends the files to a webhook URL. In all cases, every step is logged: connection attempt, authentication, bytes transferred, delivery confirmation or error, and any retries.

If the transfer fails, the MFT platform does not just log an error and move on. It retries according to a backoff policy: try again in 5 minutes, then 15 minutes, then every hour until success or a configurable timeout. If the transfer succeeds, the audit log shows proof of delivery. For regulated data, that proof is often more valuable than the file itself.

Cloud MFT versus self-hosted MFT

Self-hosted MFT runs on your infrastructure: an appliance in your data center or a virtual machine you provision and patch. You own the uptime, the backups, the certificate renewals, and the operational burden. You get full control over data residency. The tradeoff is that you manage the entire lifecycle: updates, security patches, redundancy, and evidence export.

Cloud MFT is hosted by the vendor and accessed via a web console or API. The vendor manages patching, high availability, and certificate rotation. You configure transfers, credentials, and audit policies via the web UI or API; the platform handles the rest. Data residency depends on the vendor — some cloud MFT platforms offer EU hosting, others do not. The tradeoff is less operational work, faster deployment, and built-in redundancy; the cost is that your data transits through the vendor's infrastructure and you depend on their uptime.

When you do NOT need MFT

If your organization moves a handful of files per year — a manual download and email of a report to a partner — MFT is overhead. If all your file movement is internal (between systems on the same network you control), and you already have robust visibility and logging via other means, MFT may not add value. MFT is worth the overhead when you have many partners, frequent transfers, regulatory obligations, or a need for audit trails that survive an incident.

For a deeper look at how MFT compares to plain SFTP as it scales, see FTP vs MFT: when scripted file transfer stops scaling. For protocol-specific guidance, read AS2 vs SFTP: how to answer when buyers ask. And for the full feature list, check our protocol support documentation.

xEvolve is a cloud MFT platform with per-transfer audit trails, support for AS2, SFTP, and HTTPS, Entra SSO for operator access, and EU data residency — so every transfer is logged and traceable end to end.