Configuring the FileZilla Transfer Queue for High-Volume File Migrations

Moving hundreds or thousands of files over FTP or SFTP fails in predictable ways: the server throttles you after too many concurrent connections, a large file drops mid-transfer and restarts from zero, or you re-upload files that were already identical on both ends. FileZilla Client's Transfer Queue, combined with a few settings most people never touch, addresses all three. This guide walks through configuring it for a bulk migration and verifying the behavior before you trust it with the full dataset.

What you need before starting

• FileZilla Client (the free cross-platform client, not FileZilla Server). Version 3.x is assumed throughout; menu paths below match the 3.6x series.
• Working credentials for the remote server, ideally saved in Site Manager so reconnects during a long queue run are automatic.
• Enough local disk space for downloads, and write permission on the target remote directory for uploads.
• Rough knowledge of the server's limits. Many shared hosts and hardened SFTP servers cap concurrent connections per IP. If you don't know the cap, assume one exists and start conservative.

Limit simultaneous transfers to avoid server-side bans

By default FileZilla opens up to two simultaneous transfers. Raising this number speeds up many small files, but each transfer is a separate connection, and security-hardened servers often respond to connection bursts with rate limiting or an automated IP ban that kills the whole queue.

1. Open Edit > Settings (FileZilla > Settings on macOS) and select Transfers.
2. Set Maximum simultaneous transfers. For an unknown or shared host, 2–3 is safe. For a server you control, 4–8 is a reasonable ceiling. Do not set 10 unless you have confirmed the server tolerates it.
3. In the same panel, review the file-exists action defaults (overwrite, resume, skip, or ask). For a migration, setting uploads and downloads to Resume if sizes differ, overwrite if source is newer-style rules prevents the queue from stalling on interactive prompts at 3 a.m.

Expected check: queue ten or more files (right-click a folder > Add files to queue, then Transfer > Process Queue or Ctrl+P). Watch the bottom panel — the number of files in the Transferring state at any moment should never exceed your configured limit.

Build and manage the queue instead of dragging files

Dragging a folder into the remote pane starts an immediate, unmanaged transfer. For a migration, add everything to the queue first so you can inspect, reorder, and stage the work:

• Queue, don't transfer: right-click local or remote items and choose Add files to queue. Nothing moves until you process the queue.
• Prioritize: in the Queued Files tab, right-click an item and use Set Priority or drag entries to reorder. Push small, critical files (configs, indexes) ahead of multi-gigabyte archives.
• Pause globally: Transfer > Process Queue toggles processing. Pausing lets in-flight transfers finish while holding the rest — useful if you need bandwidth for something else briefly.
• Handle failures selectively: after a run, the Failed transfers tab lists only what didn't complete. Right-click there and choose Reset and requeue all (or requeue individual entries) rather than re-adding the entire folder. This is your granular retry path.

Queue only what actually changed

Re-transferring unchanged files is the biggest time sink in repeat migrations. Two built-in tools prevent it:

• Directory Comparison (View > Directory Comparison, or the toolbar icon) color-codes files that exist only on one side or differ by size or modification time. With comparison enabled, right-click and use the synchronized browsing/queue options to enqueue only the mismatched files.
• File-exists rules (Settings > Transfers) act as the enforcement layer during the actual run, skipping or resuming files that match your criteria even if they slipped into the queue.

Note the comparison criteria: size and modification time are fast but can miss same-size content changes. FileZilla's comparison does not perform full checksums in the standard directory comparison view, so for tamper-sensitive data, verify integrity separately after transfer rather than relying on the comparison colors.

Adjust timeouts for large files on slow links

If the queue keeps dropping during multi-gigabyte transfers on a high-latency connection, the timeout is likely firing during long periods without control-channel activity. In Edit > Settings > Connection, raise Timeout in seconds from the default (20) to 60–120. Also confirm Settings > Connection > FTP > Passive mode is in use — active mode frequently breaks through NAT and firewalls and presents as random mid-queue stalls.

Verify resume behavior before the real run

Do this once, on a test file, before trusting the queue with the full migration:

1. Start transferring a single large file (several hundred MB).
2. Midway through, right-click the active transfer and cancel it, or disconnect the network briefly.
3. Requeue the failed entry from the Failed transfers tab and process the queue again.
4. Watch the transfer log: it should report resuming from a byte offset rather than restarting at zero, and the elapsed time for the retry should be roughly proportional to the remaining size.

Caveat: resume over plain FTP depends on server support for the REST command, and SFTP resume depends on the server's handling of append/seek. If the test restarts from zero, your server doesn't support resume — plan smaller chunks or accept full retransfers.

Preserve the queue across restarts

The queue is local application state. FileZilla normally persists it between sessions, but clearing application data or reinstalling discards it. Before any maintenance on the client machine, right-click inside the Queued Files tab and use Export Queue to save it to a file; restore later with Import Queue. For a multi-day migration, export at the end of each session as cheap insurance.

Final verification checklist

• Active transfers never exceed the configured limit during a test batch.
• A deliberately interrupted large file resumes from its byte offset.
• Directory Comparison after the run shows no differing or missing files (allowing for the same-size caveat above).
• The Failed transfers tab is empty, or every entry in it has a known, explained cause.