When FTP still fits

I do not pick FTP because it is trendy. I pick it when something upstream already speaks FTP and migration is not done yet.

Plain FTP belongs on isolated legacy paths only. When a partner requires FTP commands but supports TLS, use explicit FTPS with encrypted data channels. When you control SSH on both sides, SFTP is usually simpler. For web apps and browsers, HTTPS or object storage wins.

Use a decision table:

Constraint	Strong default
Existing partner requires FTP semantics	Explicit FTPS with protected data channels
You manage SSH accounts on both ends	SFTP
Browser or service uploads	HTTPS API or signed upload URL
Large cloud objects and lifecycle rules	Object storage API
Unreplaceable cleartext appliance	Isolated network, narrow gateway, replacement plan

Before you automate a nightly drop, write down what happens on failure. Can the job resume safely? Will a retry upload to a temp name? Who checks the hash before customers see the file?

Example partner flow I have wired before:

curl --ssl-reqd --user "$FTP_USER" \
  --upload-file ./report.csv \
  ftp://files.partner.test/incoming/report-$(date +%Y%m%d).part
# wait for 226 in verbose output, run shasum, then rename on the server

If the network drops after the data socket closes but before you see 226, the script should list the remote folder before it uploads again. Blind retries create duplicate or truncated files.

Compatibility explains why FTP stays around. It does not excuse cleartext credentials on the public internet. Put TLS and a narrow account in front of the legacy box when you can.

Draw one transfer your team actually runs. Mark protocol, ports, encryption, temp filenames, and the reply that means “safe to publish.”