The Hidden Cost of "Free" File Transfer Tools

SFTP is free. Cron is free. rsync is free. scp is built into every Linux server. On paper, your file transfer infrastructure costs nothing.

Until someone asks where yesterday's file went.

Or why it took four hours when it usually takes ten minutes. Or why the file arrived but nothing can read it.

These three questions show up in every ops team I've worked with. They sound like minor annoyances. They're not. They're symptoms of a file transfer setup that was free to build and expensive to live with.

"Where is my file?"

The partner calls at 9 AM. "Did you send yesterday's daily feed?" You check the cron log. The job ran. Exit code 0. It says it succeeded.

But the file isn't on the partner's server.

Now you're grepping through syslog, checking disk space on the source server, SSHing into the destination, checking if the SFTP service is even running. Thirty minutes in, you find it: the destination server rotated its SSH host key last week. scp failed silently because StrictHostKeyChecking was set to no in one script and yes in another, and nobody remembers why.

The file exists on your server. It never left. Nobody knew.

This happens because free tools don't have monitoring. Cron logs the exit code of the command, not whether the transfer actually completed. scp returns 0 even on partial transfers if the connection drops at the right moment. rsync's --partial flag keeps incomplete files on disk, but nothing alerts you that they're incomplete.

What this costs: 30 to 90 minutes per incident of engineer time. One to three incidents per week on a typical setup. At a loaded cost of $100/hour, that's $15,000 to $45,000 per year in "where is my file" time alone. Plus whatever the business impact is of missing data.

"Why is it taking so long?"

The daily file transfer usually takes 10 minutes. Today it's been running for four hours. The ops channel is getting anxious.

You check the usual suspects. Network bandwidth? Fine. Server load? Normal. Disk I/O? Nothing unusual.

Two hours of digging later: the transfer script doesn't compress data before sending it. It worked fine when the daily file was 200 MB. Last week, the upstream system started batching a week's worth of data into a single file. It's now 4 GB. The uncompressed transfer across a 10 Mbps WAN link takes four hours.

Nobody changed the transfer script. Nobody was supposed to. The upstream team changed their batch window without telling anyone.

Free tools don't have baselines or anomaly detection. There's no dashboard showing "this transfer normally takes 10 minutes, today it's taking 240." There's no alert when a transfer duration exceeds a threshold. You find out when someone complains.

What this costs: 2 to 4 hours per investigation. Monthly occurrence as upstream systems change. $24,000 to $48,000 per year in debugging time. Plus the cost of delayed downstream processes waiting on the file.

"I can't read this file!"

The file arrived. The partner confirms receipt. But their system rejects it.

"The file is corrupted," they say. Or "the encoding is wrong." Or "there are extra characters at the end of every line."

This one is almost always a character encoding or line ending mismatch. The source system writes UTF-8 with LF line endings. The transfer runs through a Windows server that converts LF to CRLF. The destination system expects LF. The file is "corrupted" because it passed through a system that modified it in transit without anyone knowing.

Or it's worse. The file is truncated. The transfer dropped partway through, and because there was no checksum verification, both sides think it completed successfully. The destination system starts processing a partial file and errors out halfway through.

scp and rsync don't verify file integrity after transfer. They verify that bytes were sent, not that the file on disk matches what was sent. If a network proxy modifies line endings mid-stream, or if the destination disk hits a bad sector during write, the transfer reports success and you have a corrupt file.

What this costs: 1 to 4 hours per incident of debugging. Partner relationship friction. Potential data quality issues downstream if partial files get processed. $12,000 to $32,000 per year.

The shadow transfer problem

Here's the part nobody talks about. You don't actually know how many file transfers are running on your network.

The ones you set up? Sure. The cron jobs in /etc/cron.d/, the Windows Scheduled Tasks, the batch scripts in C:\Scripts\. Those are documented (probably).

But then there's the dev who set up a cron job on a staging server two years ago to sync test data. It's still running. It's sending data to a server that was decommissioned six months ago. It's been failing silently every day for six months, and the error emails go to an inbox nobody checks.

And the finance team's robocopy script that runs every night, moving sensitive reports to a network share with no encryption and no access logging.

And the integration that a contractor set up three years ago that pulls partner data via FTP (not SFTP, just FTP, port 21, plaintext credentials in a config file).

Most organisations have 15 to 30 file transfers they don't know about. Shadow IT, accumulated over years, invisible until something breaks or an auditor asks uncomfortable questions.

What "free" actually costs

Cost category	Annual estimate	What causes it
Troubleshooting "where is my file"	$15,000 to $45,000	No monitoring, no transfer status, silent failures
Debugging slow transfers	$24,000 to $48,000	No baselines, no duration alerts, no compression
Fixing corrupted files	$12,000 to $32,000	No checksum verification, no encoding enforcement
Compliance gaps	$10,000 to $50,000+	No audit trails, hardcoded credentials, shadow transfers
Incident response	$5,000 to $20,000	Extended outages from silent failures, manual recovery

Total: $66,000 to $195,000 per year. For "free" tools.

The fix isn't expensive

The problems above all have the same root cause: your file transfer tools were designed to move bytes, not to give you visibility into what moved, when, and whether it arrived intact.

What actually solves these problems:

• Monitoring that shows transfer status in real time, not just exit codes
• Alerting on failures, duration anomalies, and missed schedules
• Checksum verification (SHA-256) on every transfer so you know the file arrived intact
• Audit trails that log who transferred what, when, to where, with what result
• Retry logic that handles transient network failures without manual intervention
• A transfer inventory so you know what's actually running on your network

MFTPlus handles the first five out of the box. Every transfer is logged, verified, retried on failure, and visible on a dashboard. You stop asking "where is my file" because you can see where every file is, all the time.

The transfer inventory piece is something we're building. A tool that scans your network and tells you exactly what file transfers exist, which ones are encrypted, which ones use hardcoded credentials, and which ones haven't succeeded in 30 days. Because you can't fix what you can't see.