Move Large Files Between Office Branches Is FTP the Right Tool
The server is already there, the protocol is already known — and for branch-to-branch file movement, that familiarity can hide real weaknesses. An honest audit before you build on it.
✍️ Technical Anshu🪟 Windows Networking⏱️ 7 minute read
🎥 The full deployment is in the video — the FTP feature install, users, folder permissions, firewall and passive mode, shown live step by step
Every multi-branch office hits the same need: get a 4 GB backup file, a design folder or a month of CCTV exports from branch A to branch B. FTP is sitting right there in Windows, so it becomes the default by gravity. Sometimes that is fine. Often it quietly lacks the three things branch transfers actually need — resume you can trust, integrity checking, and security across the internet. This page audits FTP against the real alternatives and tells you plainly when to keep it and when to retire it from this job.
What a Branch Transfer Actually Needs vs What Plain FTP Gives
⚠️ Resume after a dropped connection — basic support, varies by client
❌ Built-in integrity check — no hash comparison by default
❌ Safe across the internet — plain text without FTPS or a VPN
✅ Simple, scriptable, works on every Windows — FTP still wins here
Three gaps, one strength. Whether FTP is right depends on how much the gaps matter for your files.
1
Where FTP Genuinely Still Earns Its Place
One-off, very large files inside one LAN — an ISO or disk image from server to desk. No sync overhead, no third-party accounts.
Device-driven transfers — scanners and machines that can only push files by FTP. The protocol is chosen for you.
Human-in-the-loop exchanges where someone watches the transfer finish and opens the file — a natural integrity check.
In these cases the deployment in this series, with named users and user isolation, is a perfectly respectable tool.
2
Where It Quietly Fails Branch Work
Branch links drop. A plain FTP transfer interrupted at 90 percent may restart the file or resume unreliably depending on client and server settings, and FTP's original design carries no checksum — a file can arrive complete yet silently different, and neither side knows. Across the internet add the standing problem: credentials and data in plain text unless you upgrade to FTPS. And FTP is a courier, not a system: no sync, no version history, no conflict handling. If two branches edit the same folder, FTP will happily let them overwrite each other.
3
The Alternatives, Named and Judged
SMB share over a site-to-site or Tailscale VPN: branches browse one shared folder as if local; robocopy with /Z restarts interrupted copies and /MIR mirrors folders. Best when branches need a living shared drive, not deliveries.
Syncthing: free, encrypted, peer-to-peer folder sync that survives drops and verifies every block by hash. Best for keeping a folder identical in two places without any server.
SFTP with a scriptable client: the courier job done properly — one port, encryption, reliable resume in good clients, and easy automation for nightly transfers.
Cloud drive (SharePoint, Google Drive): best for documents people edit together — versioning and conflict handling included — and wrong for multi-gigabyte machine files.
4
A Simple Decision Rule
Ask three questions. Does it cross the internet? Then plain FTP is out — FTPS, SFTP or VPN, pick one. Must the file arrive provably identical? Then use a tool with hashing (Syncthing, robocopy with verification habits, or compare a SHA-256 hash after FTP). Is it the same folder, kept in step daily? Then you want sync or a shared drive, not a courier. If all three answers are no, the FTP server you already run is honestly good enough — and now you know exactly which risks you accepted, which is the difference between a decision and a habit.
5
If You Keep FTP for Branches — Minimum Standards
Named user per branch with user isolation, never one shared login for all sites.
FTPS enabled, or FTP reachable only through the branch VPN — never naked on the internet.
For critical files, exchange a SHA-256 hash alongside (a phone call or message) and verify on arrival with Get-FileHash.
A weekly glance at the FTP logs, per the log-reading page in this series.
🔴 One rule before anything else: classic FTP sends the username, the password and every file in plain readable text. Inside a trusted office LAN it still has honest uses. On the open internet it does not — there the answer is FTPS or SFTP, and these pages will keep saying so.
🎥 Watch the Complete FTP Server Deployment
The video sets up the whole FTP server on Windows live — including the fast automated route — so you can follow it on your own server, click by click.
The protocol supports restarting a transfer and good clients like FileZilla and WinSCP handle it — but behaviour varies, and FTP gives you no built-in proof the resumed file is intact. For critical files, verify a hash, or use a tool designed for unreliable links.
Is robocopy over VPN really better than FTP for branch backups
For folder-shaped jobs, usually yes: robocopy restarts interrupted files with /Z, skips unchanged files, and logs what it did. FTP moves files; robocopy maintains a copy — different jobs, and branch backups are the second one.
Our branches already use FTP with no problems — why change anything
If it is LAN or VPN contained, uses named isolated users, and the files are verified or low-stakes, you may genuinely be fine. The audit on this page is about knowing your three answers — not about replacing working systems for fashion.
This guide is based on the Technical Anshu video — Windows FTP Server Deployment Guide for IT Admins • Stuck on a step — ask in the video comments and you will get an answer there 🙏