Manufacturer moved 50 million small files between Windows servers — 12× faster than Robocopy.
A manufacturing company was running a hardware refresh on its Windows file servers — same data center, new hardware. Each server held roughly 50 million small files. At Robocopy's typical pace of about 8 hours per million files, a single server would take over 16 days of straight copying. With multiple servers to migrate, the project would have spanned months. They needed a fundamentally different transport, not just a faster script.
A standard hardware refresh that wasn't standard at all.
The manufacturer's IT team was replacing aging Windows file servers with new hardware in the same data center — a routine refresh in concept. The problem was the dataset. Each old server held around 50 million small files: engineering drawings, CAD revisions, quality inspection records, machine telemetry exports, and the tens of thousands of small project files a manufacturing environment naturally accumulates over years.
Anyone who has run a small file migration at this scale knows the brutal truth: file count, not data volume, sets the clock. SMB-based tools like Robocopy spend most of their time on per-file overhead — open, authenticate, write metadata, close, repeat — and at tens of millions of files, that overhead dwarfs actual data transfer. The team's initial testing with Robocopy confirmed it: about 8 hours per million files, which extrapolated to over 16 days per server. Across multiple servers, the refresh was going to take months.
Same files. Same servers. Different transport.
Per-server timing comparison, calculated from the team's own benchmarks.
SMB was designed for shares — not for moving 50 million files.
The problem isn't the network or the disk. It's the protocol overhead per file, multiplied by 50 million.
Per-file SMB overhead is enormous
Every file moved over SMB carries a sequence of handshakes — open, authenticate, lock, write metadata, close. At 50 million files, that per-file overhead is the whole job.
Throughput is invisible at small file sizes
A 10 Gbps network means nothing when each file is a few KB and the protocol spends most of its time on metadata round trips, not data. The pipe sits mostly empty.
No batching, no compression in transit
Robocopy and most SMB-based tools move files one at a time, uncompressed. Small files don't benefit from raw bandwidth — they benefit from batching and in-flight compression, which SMB doesn't do.
Firewall complexity at scale
Some "alternatives" use multiple ports or dynamic port ranges, which require coordination with security teams — adding days of approvals to what should be a straightforward refresh.
GS RichCopy 360 Enterprise + the RTA client.
The team deployed GS RichCopy 360 Enterprise on the source Windows server and the RTA (RichCopy Transfer Agent) client on the destination — bypassing SMB entirely.
Single Multi-Channeled TCP Port
RTA uses one TCP port that's multi-channeled, accepting many files simultaneously on a single connection. One firewall rule, one port, no coordination — straightforward to deploy in any IT environment.
Small-File Batching
Instead of one open/close cycle per file, RTA picks up small files in batches and streams them together. The per-file overhead that crushes SMB-based tools effectively disappears.
In-Transit Compression
Files are compressed on the source side before transmission and decompressed by the RTA on the destination — then written to their target paths exactly as they were on the source. Less data on the wire, faster overall transfer.
The key insight is that SMB isn't a bug — it's just the wrong tool for this job. SMB was designed for interactive file access across a network share, not for moving tens of millions of files between servers. RTA replaces it with a transport purpose-built for migration: one multi-channeled TCP port carrying batched, compressed file streams. The result is roughly 1 million files in 40 minutes, sustained — versus Robocopy's 8 hours for the same million.
Just as important from an operations perspective: deployment was simple. Install RichCopy 360 Enterprise on the source server, install the RTA client on the destination, open one TCP port between them, and start the job. No SAN reconfiguration, no jump hosts, no protocol gymnastics. The manufacturer's IT team got the first server migrated in a day and a half — and rolled the same approach across every subsequent server in the refresh.
A months-long project finished in days.
Real benchmarks. Real servers. Real hardware refresh, completed on schedule.
For small files at scale, the transport is the bottleneck.
Most file-copy tools — Robocopy, sync utilities, even some commercial migration software — share the same blind spot: they ride SMB, and SMB collapses under per-file overhead at scale. By replacing SMB with the RTA's batched, compressed, single-port transport, GS RichCopy 360 Enterprise turned a months-long project into a multi-day one. For small-file migrations, the right transport is the difference between an IT project and an IT crisis.
Migrating millions of small files between servers?
GS RichCopy 360 Enterprise with the RTA client bypasses SMB's per-file overhead — delivering server-to-server migration speeds that SMB-based tools can't match.