July 16, 2026

FTP vs MFT: when scripted file transfer stops scaling

Plain FTP is dead — no encryption, no authentication beyond a password, no audit trail. But SFTP, backed by shell scripts and cron jobs, still runs critical workflows at many organizations. It is cheap, familiar, and works fine until it does not. This post walks through the honest trade-offs: when scripted SFTP is fine, when it breaks down, and what MFT adds to solve those breaks.

Plain FTP: why you should not use it

FTP sends credentials and data in cleartext over the network. Any packet sniffer can capture login credentials, intercept files, or modify them in transit. FTP has no place in regulated data flows, and if your compliance questionnaire says "no cleartext protocols," FTP fails immediately. It still lingers in legacy environments and forgotten integrations, which is exactly where auditors find it.

Scripted SFTP: good at small scale, breaks as complexity grows

SFTP over SSH is encrypted and widely supported. A bash script using sshpass, expect, or Paramiko can automate SFTP transfers: connect, upload files from a directory, disconnect, and log the result to a file. Running this script via cron every 15 minutes moves files reliably for many organizations. The cost is low — you need only an SSH key and a folder — and the operational overhead is minimal if nothing breaks.

The problems emerge as complexity grows. First, credential sprawl: each integration gets its own SFTP user account and SSH key, often stored in plaintext in the script or a shared .ssh/config. Offboarding is manual — remove the user, delete the key, hope you found every place it was copied. Second, silent failures: a cron job runs, the connection fails, and nobody knows until someone manually checks the logs or a partner complains that files never arrived. Third, no delivery evidence: the script returns 0 (success) but did the partner receive the file? Without a receipt mechanism, you cannot prove delivery. Fourth, logging is scattered: job output goes to syslog or a text file, partner confirmations are in email, and piecing together the full transfer history requires manual digging.

A concrete failure mode: the Friday night SLA miss

A financial institution runs an automated SFTP export of transactions every day at 17:00 via cron. The script connects to the partner bank's SFTP server, uploads an encrypted file, and logs success. One Friday, the partner's server is rebooted for emergency patching. The cron job runs at 17:00 and fails to connect — the server is down. The script logs "connection refused" and exits. Nobody monitors the cron output over the weekend. On Monday morning, the partner bank calls: the transaction export never arrived, and they cannot settle end-of-week reconciliation. An SLA is breached, and now you are explaining why there was no alert.

An MFT platform would have queued the failed transfer, retried every 15 minutes, and sent an alert after the second failure. When the partner's server came back online, the transfer would have retried automatically. On Monday, the missing file would have been delivered without manual intervention. The audit log would show the exact timeline: failure at 17:01, retry at 17:16, success at 08:15 Monday.

What MFT adds

Managed file transfer abstracts away the scripting and gives you a control plane: create transfers, set retry policies, monitor results, and export audit logs without writing code. Failures are visible immediately via dashboards and alerts. Delivery is traceable: the audit log proves that the file left your system at a specific time and in what state. Credentials are centralized: one password or key per partner, stored encrypted, and rotated as a policy rather than a manual grep-and-replace across scripts. Partner onboarding is faster: configure the partner, assign permissions, and the transfer can run immediately without coordinating SSH keys or firewall rules with network ops.

2026 best practices for file transfer

Both scripted SFTP and MFT benefit from the same baseline practices: use key-based authentication, not passwords; rotate keys every 90 days; require SSO for any operator who logs into the transfer platform or console; ship every transfer log to your SIEM (security information and event management system) so analysts can search and alert on patterns; enforce retention policies on disk, not on paper — if the policy says 90 days, delete the files automatically; and document every partner offboarding step so that access is revoked consistently and keys are not orphaned.

For more details on where scripted SFTP still fails, see Scheduled job failed silently, missed SLA and Orphaned SSH keys after offboarding. For a comparison to MOVEit and other legacy platforms, check our MOVEit alternative guide.

xEvolve handles retries, audit logging, and partner credential management in a unified platform — per-transfer audit trails, SFTP and AS2 support, Entra SSO for operator access, and tenant isolation so every partner's data stays private.