Major studio replicated 5 petabytes between buildings — in 3 weeks, with deltas running right to cutover.
A major Hollywood studio needed to relocate 5 PB of post-production media from one building to a new facility — moving from NetApp and Dell EMC Isilon to VAST Data — and keep both sides in sync until the official cutover. The data is the studio's working master archive, so every byte and every piece of metadata had to land intact. With a 100 Gbps link in place and a hard move-in date, the question wasn't whether the network could carry it — it was whether anything could drive the network hard enough.
A building move, a storage refresh, and 5 petabytes in the middle.
The studio was relocating between facilities and modernizing storage in the same project. Active production shares — spread across multiple NetApp and Isilon systems in the old building — had to land on a fresh VAST Data platform in the new one. The total dataset weighed in at 5 petabytes spread across more than 750 million unstructured files and folders: raw camera media, project files, renders, dailies, and finished masters, all sitting in deep, real-world post-production directory trees across many SMB shares.
Two constraints made this harder than a standard large-scale file server migration. First, the source was live — editors, colorists, and VFX teams kept working through the entire window, which meant new files and changes had to be picked up continuously, not just in a single bulk pass. Second, the data is the studio's working archive: original media files where any silent corruption, truncation, or metadata loss would be unacceptable. There was a 100 Gbps link between buildings, but a fast link only helps if the copy engine can actually push it.
Robocopy got them started. It couldn't get them finished.
The team started where most Windows-shop IT teams start, then ran into the wall everyone hits at petabyte scale.
Robocopy was hard to manage at scale
Running dozens of Robocopy jobs across multiple servers meant juggling scripts, scheduled tasks, and command-line flags. There was no central view of progress and no easy way to rebalance work as it ran.
Logs were nearly unreadable
Robocopy logs at this scale become millions of lines. Finding what failed, what skipped, and what actually transferred required custom parsing — and that's not what anyone wanted to be debugging at 2 a.m. mid-migration.
No native service mode
Robocopy doesn't run as a Windows service. Long jobs depended on an interactive session staying alive, which is not how an enterprise IT team wants to bet a multi-week, multi-petabyte project.
Alternative tools couldn't deliver
Other Robocopy alternatives the team evaluated were either too complex to learn and stand up inside the window, or simply didn't deliver the throughput needed to saturate a 100 Gbps link across multiple source filers.
Multiple GS RichCopy 360 stations, working in parallel.
Instead of a single migration server bottlenecking the move, the team deployed multiple GS RichCopy 360 Enterprise stations and partitioned the work across them — so the 100 Gbps link saw load from many directions at once.
Distributed Stations
Multiple RichCopy 360 stations were deployed, with jobs divided across them by share, by source filer, and by data set. Each station drove its slice of the workload independently, contributing to the total throughput.
Around-the-Clock Replication
Running as a Windows service, RichCopy 360 kept jobs moving 24/7 across the 100 Gbps link — multi-threaded, resumable, and faithful to original files, timestamps, and folder structure across NetApp, Isilon, and VAST.
Delta Sync to Cutover
Once the bulk pass completed, jobs kept running in delta mode — picking up only what changed on the live shares. The destination stayed continuously in sync with the source until the official cutover date arrived.
The defining choice here was treating petabyte-scale replication as a parallel-architecture problem, not a single-tool problem. One server, no matter how well-tuned, can't saturate a 100 Gbps inter-building link against multiple source filers. By running several RichCopy 360 stations in parallel and assigning each one a portion of the share set, the team turned the migration into something the network could actually feed at line rate.
Just as important was what didn't happen. Because RichCopy 360 runs as a Windows service, jobs didn't depend on console sessions staying alive. Because logs are structured and human-readable, the team could see exactly what each station was doing in real time. And because every file, timestamp, and folder structure was preserved precisely, the studio's master archive landed on VAST Data with the same fidelity it had on NetApp and Isilon — which, for original production media, is the only acceptable outcome.
5 PB delivered. Production never stopped.
Real volume, real production load, real cutover.
At petabyte scale, the migration is an architecture.
Moving 5 PB between buildings isn't really a copy job — it's a small, purpose-built replication system that you stand up, run, and tear down. The studio's win came from treating it that way: multiple stations in parallel, running as services, with delta sync keeping the destination live until the move date. The 100 Gbps link finally had something that could feed it.
Migrating a NetApp, Isilon, or VAST environment?
GS RichCopy 360 Enterprise scales horizontally across multiple stations to deliver the throughput petabyte-class migrations actually require — across SMB shares, NAS devices, and cloud targets.