Copying between two of your own machines was bound by network latency, not by bandwidth or by our workers: every chunk waited for the previous one to be acknowledged, on both hops. On a link with 30 ms of latency that caps a transfer at roughly 1 MB/s no matter how fast the pipe is.

Transfers now keep 64 requests in flight per file, in both directions. Measured on a zero-latency loopback — the floor of the improvement, not the ceiling — throughput went from 28.9 MB/s to 66.4 MB/s with byte-identical output. Over a real internet link the gain scales with the round trips removed.

Three more things that were quietly costing whole minutes:

• •Scanning a deep tree walked one directory at a time and asked the server to describe every file it had already described. Directories are now scanned in parallel, and the live view reports Scanning /var/www — 12,480 files so far instead of a silent "Scanning remote directory…".
• •Re-runs checked the destination one file at a time. The destination is now read once, up front, and compared in memory — on a 24,000-file job that replaces 24,000 sequential round trips with a few hundred concurrent ones.
• •Server-to-server runs use 4× the thread count you pick. Those runs wait on two remote machines rather than on our workers, so the plan's number is a floor, not a ceiling: Pro copies 16 files at once, Business 32. The picker tells you what the run will actually do.

See the migration guide for how jobs work.