Why your transfer infrastructure can't keep up with modern production

Every facility in your pipeline needs current data. That's not a new requirement. What's changed is the scale of the problem.

Productions today generate terabytes daily, camera originals, editorial cuts, VFX plates, renders, finishing deliverables, moving between sites that may be spread across multiple time zones and vendors. The logistics compound fast. Every additional facility in the pipeline multiplies the coordination, the risk, and the manual effort required to keep assets current.

Most transfer infrastructure wasn't built for that. It was built for a simpler problem: moving a file from one place to another. And it's starting to show.

‍

The hub-and-spoke problem

Traditional transfer models route everything through a central node. Assets land at one facility, get transferred out to the next, then the next. It's a logical architecture when work moves sequentially. It breaks down when production doesn't.

The failure modes are predictable:

• VFX vendors work from yesterday's plates while editorial has already moved on
• Dailies sit in a queue while the edit team waits
• A central node goes down and every downstream site loses access simultaneously
• Overnight windows mean the first thing every facility does in the morning is wait

‍

None of these are edge cases. They're structural, because the architecture has a single point of failure built in: the hub. Every site's access to current data depends on it.

‍

The scheduling problem

Point-to-point transfer tools, however fast, share the same underlying assumption: a transfer is something you initiate, monitor, and complete. That made sense when content moved in discrete handoffs. It doesn't scale when assets are being updated continuously across multiple sites at once.

Scheduling more frequent transfers doesn’t fix it. It just creates more jobs to manage, more failures to catch, and more coordinators and engineering teams spending their day watching progress bars instead of supporting the work. The manual overhead is built into the model, and the cost of pulling highly skilled engineers into file movement workflows adds up fast.

What production infrastructure actually needs is a pipeline where assets at one facility are virtually available everywhere, automatically - no scheduling, no triggers, no constant oversight.

‍

What to look for in a modern sync architecture

If you're evaluating whether your current setup can carry a modern production pipeline, these are the questions worth asking:

• Does it have a single point of failure? If a central node goes down, what happens to downstream sites? The answer should be: nothing. Every node in the mesh should be able to continue independently.

• Is transfer continuous or scheduled? Scheduled windows are a bottleneck waiting to happen. Continuous peer-to-peer sync means assets are always current, without intervention.
• How does it handle large media files at scale? Directory enumeration, delta sync, and chunking matter more than headline throughput numbers. A tool that moves files fast but transfers whole files on every change will choke on production-scale assets.
• Can it integrate with your pipeline tooling? REST API and event-based triggers let sync initiate automatically based on production events, no separate tooling layer sitting outside the workflow.
• What happens when connectivity drops? Work should continue uninterrupted because files are physically present at every site. When the connection comes back, sync should resume from where it stopped - no manual restart, no re-transferring data that already moved.

• Can teams prioritise what matters first? Not every file has the same urgency. Modern sync architectures should allow teams to prioritise critical assets, sequences, or folders so artists get what they need immediately, instead of waiting for entire datasets to finish transferring.
• What does it cost at scale? Per-transfer pricing escalates quickly when production ramps. A flat throughput-based fee means you know what you're paying before the project starts, regardless of how many sites come online.

‍

The operational argument

The technical case for rethinking transfer infrastructure is clear. The operational case is just as important.

Managing transfers across multiple point-to-point tools means multiple relationships, multiple SLAs, and multiple places to look when something goes wrong. In practice, that means time spent diagnosing where the problem sits before anyone starts fixing it. On a live production, that time is rarely available.

A continuous, peer-to-peer sync architecture changes the relationship between your team and the pipeline underneath them. When assets stay current automatically, coordinators stop managing transfers and start supporting the show. When a node drops, the rest of the pipeline keeps running. When something does go wrong, there's one place to go.

‍

The question worth asking now

If any of this maps to how your current infrastructure behaves, it's worth a look at what a different architecture could do for your pipeline. Resilio Active Everywhere on Sohonet is built for exactly these conditions. Talk to our team.

‍