Skip to content

MFT vs SFTP Scripts — When Scripts Stop Being Enough

SFTP scripts work. At small scale, a shell script that does sftp get and moves files has been a practical solution for decades.

The question is not whether scripts work. It is whether scripts continue to work reliably as the operating environment grows more complex.

  • they move files
  • they are easy to create
  • almost any developer can write one
  • they integrate naturally with existing cron, Task Scheduler, or CI infrastructure

Most scripts use SFTP clients with weak host verification by default. Finding StrictHostKeyChecking no or -o StrictHostKeyChecking=no in a production script is common. That setting disables the only active defense against server impersonation over SSH.

When a script fails silently — the cron job ran, exit code was 0, no email — the first sign of failure is often a partner escalation or a missing downstream file.

If a script is re-run after a partial failure, it usually does not know what files it already processed. Duplicates happen.

Scripts live in a crontab or a task scheduler entry that may not be in version control. Reviewing what a system does requires finding the right server and reading the script directly.

Credentials are often hardcoded or stored in files readable by more users than intended. Key rotation requires finding every file that references the old key.

Signs that SFTP scripts are reaching their limits:

  • More than a handful of partners with different settings and credentials
  • Repeated investigation burden: operators spend time reconstructing what happened from log files
  • Compliance requirements: an auditor asks for evidence of what files transferred when
  • Staff changes: the people who wrote the scripts are no longer around to explain them
  • Duplicate deliveries: partners report receiving files twice, or not at all
  • Security review: a reviewer finds hard-coded credentials or disabled host verification

A managed file transfer platform codifies the transfer workflow so it can be:

  • reviewed without reading scripts
  • validated before running
  • executed reliably with retry and idempotency
  • monitored for failures and status
  • audited for what happened to each file

It does not eliminate the need for operational discipline. It makes discipline the default behavior rather than requiring individual developers to implement it correctly in every script.