Your bash script is probably running 847 transfers a month. You have no idea.
That's not an insult. It's what a fresh installation of mft-discover typically finds in environments where file transfers grew organically over years. Cron jobs added by engineers who are no longer on the team. SFTP credentials baked into scripts checked into a private repo that six people have access to. A transfer to a partner FTP server that the finance team set up in 2019 and nobody has touched since.
Everyone starts with a cron job and a bash script. That's the right call. It's cheap, it works, and it runs on whatever you already have. The problem isn't the decision — it's not noticing when the decision stopped being right.
What DIY actually costs
The engineer-hours argument usually wins the debate on paper. Your team already knows bash. The script takes a day to write. Managed file transfer software costs $150 to $199 a month. The arithmetic is obvious until you add the columns everyone skips.
Maintenance. Every time a server changes hostname, a partner rotates credentials, or someone upgrades the SFTP server to a version with different key exchange requirements, someone touches the script. Five minutes if they know the history. Three hours if they're new. Multiply that by however many scripts you have, across however many servers, over the years.
Failures at 2am. Bash doesn't alert you when it fails silently. If your transfer script produces no output and cron doesn't capture stderr, you find out the file didn't arrive when the finance team can't close the month-end report. The investigation usually takes longer than the fix — you need the logs, but there aren't any.
Audit gaps. SOC 2, ISO 27001, and POPIA all require demonstrable audit trails for data movement. A cron log showing "exit code 0" is a record. It is not a verifiable audit trail. When an auditor asks which files transferred, by which process, verified by which checksum, at exactly what timestamp, the cron log doesn't answer the question.
Credential sprawl. Passwords in environment variables. SSH keys without expiry. SFTP credentials in plaintext in a config file that's been copied between three servers over five years. Your transfer scripts are probably holding credentials your security team doesn't know about.
What changes with managed transfer
Here's what a failed transfer looks like with mftctl:
$ mftctl jobs list
ID NAME SCHEDULE STATUS LAST RUN NEXT RUN
j1 billing-export 0 2 * * * OK 2026-06-12 02:00 2026-06-13 02:00
j2 partner-sync */15 * * * * FAILED 2026-06-12 14:45 2026-06-12 15:00
$ mftctl jobs logs j2 --last 1
[2026-06-12 14:45:02] Starting transfer: partner-sync
[2026-06-12 14:45:03] Connecting to sftp.partner.co.za:22
[2026-06-12 14:45:13] ERROR: Connection timeout after 10s (attempt 1/3)
[2026-06-12 14:45:23] ERROR: Connection timeout after 10s (attempt 2/3)
[2026-06-12 14:45:33] ERROR: Connection timeout after 10s (attempt 3/3)
[2026-06-12 14:45:33] Transfer FAILED — alert sent to ops@yourcompany.comThree retry attempts. Alert on failure. Structured log with timestamps and a transfer reference. SHA-256 checksum verification before and after. You get this without writing any of it.
The audit trail is cryptographically chained. Every transfer event links to the previous one through a hash. You can run mftctl audit verify from a terminal with no network access and get PROVEN or TAMPERED at seq X. Not a dashboard screenshot — a verifiable proof.
Credentials live in MFTPlus, not in your scripts. When a partner rotates their key, you update it in one place. Shell completions, YAML config, job management from the terminal if that's how you work.
The honest comparison
| DIY scripts | MFTPlus Starter ($150/mo) | MFTPlus Pro ($199/mo) | |
|---|---|---|---|
| Setup time | 1–3 days | 5 minutes | 5 minutes |
| Audit trail | cron logs | hash-chained, verifiable | hash-chained, verifiable |
| Failure handling | silent unless you build it | retry + alert | retry + alert + SLA |
| Compliance coverage | manual documentation required | SOC 2 / ISO / POPIA ready | SOC 2 / ISO / POPIA ready |
| On-call burden | your team | none | none |
| Credential management | scattered across servers | centralised, no plaintext | centralised, no plaintext |
Who should stay on scripts
If you have one transfer job, a bash script that works, and no compliance requirements, stay where you are. Adding managed file transfer software for a single scheduled rsync is overhead that doesn't pay off. The script is fine.
Same if your team is comfortable with the operational burden and you're early enough that audit trails aren't yet a requirement. The time will come, but it's not always now.
Where it stops making sense to stay on scripts: when you have more transfer jobs than you can name from memory. When the question "what ran last night?" requires checking three servers. When a compliance questionnaire asks for audit logs and you have to build something before you can answer.
That's when the $150 a month math works out differently.
FAQ
How does MFTPlus handle transfers that were previously managed by bash scripts?
You migrate jobs one at a time. Define the job in YAML or through the dashboard, point it at the same source and destination, and cut over. The existing bash script can run in parallel during a transition period if you need it. Most jobs take under 10 minutes to migrate.
Does MFTPlus support SFTP, FTPS, and SCP?
Yes. SFTP (SSH file transfer protocol) and FTPS (FTP over TLS) are fully supported. SCP is supported for transfers. FTP without TLS is supported for inbound compatibility with legacy partners, but we recommend migrating legacy FTP sources to SFTP when possible.
What does the audit trail actually prove for a compliance audit?
The hash-chained audit trail proves that the transfer records haven't been altered since they were written. An auditor can run mftctl audit verify independently, offline, with no access to your infrastructure, and confirm that the chain is intact. This satisfies the "demonstrable, tamper-evident" requirement in SOC 2 and ISO 27001 frameworks.
Is there a free tier for evaluating MFTPlus?
Yes. The Community tier is free and includes basic job scheduling, SFTP/FTPS support, and operational logs. It doesn't include hash-chained audit trails or the compliance reporting features. Most teams use Community to evaluate the deployment and operational workflow before upgrading.
What does mft-discover actually find?
mft-discover scans your network for active file transfer activity — SFTP sessions, FTP connections, scheduled jobs touching common transfer paths. It identifies transfer endpoints, credential exposure patterns, and protocol usage. The output is a structured report you can use as an onboarding checklist. It's free to run independently of MFTPlus.