FTP: Fast at Bulk, Wrong on the Wire

The workflow survives because it suits the work. Open a client, drag between two panes, let the queue drain. Bulk operations that make a browser-based file manager time out are unremarkable here, because the transfer is a background queue rather than a series of page loads.

FTPS wraps the original protocol in TLS, and it exists mainly to satisfy legacy systems. SFTP is the modern answer: same drag-and-drop experience, one port, and nothing readable on the wire.

Throughput on a single large file is bounded by bandwidth. Throughput on thousands of tiny files is bounded by round trips, which is why a wp-content directory full of thumbnails transfers far more slowly than its total size suggests. Latency, not megabits, is the constraint.

Where you have shell access, archiving first is dramatically faster: one tar file up, one extract at the far end, no per-file negotiation at all. That is the single biggest speed-up available on a migration and it costs one command at each end.

Compare file counts at both ends before you call it done — find . -type f | wc -l on each side is enough for most jobs. Clients silently skip files they cannot read and quietly fail on names with awkward characters, and a missing directory is far cheaper to notice now.

Check permissions afterwards too. A transfer that resets execute bits or ownership will produce a site that loads but cannot write uploads, which is a confusing failure to debug two days later.