How to Deliver Multi-Terabyte Projects Over the Internet

The first question is: “will the upload finish, verify, and be available somewhere useful before the delivery window closes?” For multi-terabyte projects, internet delivery is completely viable. It only works, though, if you treat it as a transfer workflow instead of a giant drag-and-drop. Four things make the difference: planning around real upload bandwidth, splitting the delivery into sane units, using a transfer method that can resume after failure, and verifying the result before your team deletes source media or tells editorial they're clear to proceed. A 4 TB turnover can be painless on a prepared connection with the right transfer client. The same 4 TB can become a three-day mess on hotel Wi-Fi, a throttled cloud drive, or a remote office where the receiving storage fills up halfway through.

The decision starts with time

Terabytes sound abstract until you convert them into hours. The rough transfer-time formula is:

The same data can take very different amounts of time depending on sustained throughput.

total bits / usable bits per second = transfer seconds Storage is measured in bytes and bandwidth in bits, so multiply terabytes by 8 before doing the math. Then account for overhead, throttling, and packet loss. Encryption and local disk speed cost you more. And “1 Gbps internet” rarely means 1 Gbps sustained upload to your destination. Here are useful ballpark estimates for a 1 TB upload at sustained throughput:

Sustained upload speed	Approximate time for 1 TB	Approximate time for 5 TB
25 Mbps	3 days, 17 hours	18 days, 12 hours
50 Mbps	1 day, 20 hours	9 days, 6 hours
100 Mbps	22 hours	4 days, 15 hours
250 Mbps	9 hours	1 day, 20 hours
500 Mbps	4.5 hours	22 hours
1 Gbps	2.2 hours	11 hours
2 Gbps	1.1 hours	5.5 hours
10 Gbps	13 minutes	1.1 hours

These are clean math estimates, so add margin in production. For a one-time upload over a shared office connection, 30 percent margin is optimistic. Double the estimate before promising a delivery time on field networks, hotel internet, or mobile routers. Do the same for congested Wi-Fi and any unknown client-side destination. The two numbers that decide everything are the sustained upload speed from the source and the sustained ingest speed at the destination. A sender with 1 Gbps service, a NAS that reads at 120 MB/s, and a destination that throttles after 750 GB per day won't deliver like a true 1 Gbps path.

Know what kind of delivery you're making

Not all multi-terabyte deliveries have the same risk profile. A camera-card backup from set behaves nothing like a locked master delivery, a VFX pull, or a full conform turnover. Five constraints change the recommendation:

Total volume, because 800 GB, 4 TB, 20 TB, and 100 TB are different problems.
Deadline shape, because “as soon as possible” is different from “editorial needs the first reels tonight.”
Network stability, because a fast but flaky connection needs different handling than a slower but stable one.
Security requirements, which may include encryption, expiring access, audit logs, and named users for unreleased media.
Post workflow, which decides whether files need to land in cloud storage, a MAM, shared storage, or a specific folder structure for automation.

So decide which kind of delivery you have. You are moving either a finished package, a stream of incoming media, or a staged delivery that needs to become useful before the full transfer completes. If the whole show must arrive before anyone can work, your only lever is total transfer time. If editorial can start with proxies, reels, or stringouts — or with turnovers and priority bins — split the delivery so the earliest usable material moves first.

Break the project into delivery units

The fastest way to make a large transfer fragile is to treat it as one enormous folder with no internal structure. If the transfer tool has to scan millions of files, retry a half-failed tree, or rehash everything from scratch, you lose time before the upload even begins. A better unit is a package that's large enough to transfer efficiently, small enough to retry, and meaningful enough for the recipient to ingest.

Smaller packages make failed retries manageable.

Common package boundaries in post workflows include:

Shooting day or card, which is useful for original camera media and dailies.
Reel, act, sequence, or episode, which is useful for editorial and finishing turnovers.
Department, such as VFX plates, audio, color, graphics, project files, and references.
Priority, such as proxies first, then audio, then high-resolution camera media.
Storage target, with one package per destination bucket, workspace, or ingest folder.

For very large projects, avoid creating a package for every tiny folder unless the receiving system requires it. Too many small files can be a performance problem by itself. Cloud and enterprise transfer systems handle large datasets better when the file tree is balanced and individual source folders don't contain absurd numbers of files. There are two common ways to package media:

Preserve the folder tree and transfer files directly.
Archive groups into tar, zip, or similar container files before transfer.

Preserving the tree keeps the delivery transparent. The receiver can inspect partial arrivals, run folder-level ingest, and avoid a huge unpacking step. That makes it the better default for camera originals, editorial turnovers, and workflows where metadata sidecars matter. Archiving can help when there are hundreds of thousands of small files, when a destination performs poorly with deep folder trees, or when you need a single object per package. But archives introduce their own failure mode. One corrupted multi-terabyte archive can block access to everything inside it. If you archive, keep archives to a size you can reasonably retry and verify. For example, instead of one 8 TB archive, create reel or day packages in the 250 GB to 1 TB range, depending on your connection and deadline. A failed 500 GB retry is annoying. A failed 8 TB retry can kill a delivery window.

Use a resumable transfer method, not a browser hope-and-pray

Browser uploads are fine for small deliverables. Multi-terabyte transfers need a client, agent, or managed file transfer system that's designed for interruption. At minimum, the transfer method should support:

Resume after network loss without restarting completed files.
Parallel or multi-part transfers where appropriate.
Automatic retry with sane backoff.
Transfer logs showing success, failure, and skipped files.
Checksum or hash validation.
Large file support above your biggest expected file.
Authentication and permission control.
A destination that can accept the full payload.

FTP is still around, but it's rarely the best default for modern media delivery. Basic FTP can be slow over long distances and painful through firewalls. It is weak on security unless you wrap it properly, and it gives non-technical recipients a poor experience. TCP-based tools are reliable, but raw single-stream TCP can underuse high-bandwidth, high-latency paths because acknowledgments and round-trip time limit how much data stays “in flight.” That's why accelerated transfer tools, managed file transfer platforms, and cloud-native agents exist. They try to fill the available pipe more effectively and resume failed chunks. Some run multiple streams or optimize TCP behavior. Some also support watch folders, transfer while a file is still growing, and channel bonding across multiple networks. Direct ingest into object storage is common too. The useful decision is whether the tool can sustain throughput on your actual path while preserving integrity and giving the receiver a clean handoff. For a one-off client delivery, ease of download and auditability may matter more than squeezing out every last megabit. For dailies from a remote set, prioritize auto-resume, background agents, and good behavior on unstable networks.

Transfer approach	Best fit	Strengths	Watch for
Browser upload	Small ad hoc files and noncritical deliverables	Simple, no install, easy for casual recipients	Weak resume behavior, session timeouts, file size limits, limited logs
Cloud sync or desktop drive client	Ongoing folders, modest turnovers, teams already using the platform	Familiar interface, background syncing, easy sharing	Conflicts, throttling, unclear verification, accidental renames or deletions
Command-line or cloud-native agent	Planned large transfers into object storage or technical destinations	Resume support, multipart transfer, scripting, logs, predictable automation	Requires setup, credentials, and someone comfortable reading transfer output
Managed or accelerated media transfer	Time-sensitive terabyte delivery, long-distance links, unstable networks, remote set workflows	Better path utilization, auto-retry, audit logs, watch folders, named users	Licensing cost, recipient onboarding, destination compatibility
Physical transfer appliance	Tens or hundreds of terabytes into cloud when bandwidth cannot meet the schedule	Avoids weak internet paths and can seed a large cloud library	Lead time, chain of custody, shipping risk, later ingest and verification still required

Stage the upload so people can work earlier

Multi-terabyte delivery fails socially before it fails technically. Someone says “the upload is at 62 percent,” but nobody knows whether the missing 38 percent contains the shot the colorist needs tomorrow. Treat priority as part of the transfer plan. A staged delivery might look like this:

Project manifest, delivery notes, and folder map.
Low-resolution proxies or review exports.
Editorial project files, bins, XML, AAF, EDL, and reference media.
Audio turnover and mix references.
VFX pulls or color-critical selects.
Remaining camera originals or full-resolution plates.
Supplemental assets, stills, graphics, fonts, LUTs, and reports.

This exact order won't fit every show, but “everything at once” is the least helpful queue. Put the files that unblock human work at the front, then let the heavier media follow. If your transfer tool supports priority queues, use them. If it doesn't, create separate packages and start them in order. Make sure the recipient understands which packages are ready to ingest and which are still in flight.

Verification belongs inside the workflow

Simple copy methods aren't enough for original camera data and high-value media. Finder, Explorer, and basic drag-and-drop don't give you the confidence needed to wipe source media or release a drive. Professional camera workflows typically rely on checksum-verified copies for exactly this reason. A checksum acts as a calculated fingerprint of a file. If the sender calculates a hash and the receiver calculates the same hash after transfer, you have strong evidence that the file arrived unchanged.

Checksums compare matching file fingerprints after transfer.

The verification pattern runs in five steps:

The sender generates checksums at the source.
The sender transfers the files and checksum manifest together.
The receiver recalculates checksums at the destination.
The receiver compares the destination result against the source manifest.
The receiver saves the report with the delivery.

MD5 and xxHash both appear in real workflows, as do SHA-1 and SHA-256. The “best” choice depends on tool compatibility and security policy. For media integrity, what matters is that the sender and receiver use the same algorithm consistently and record the result. For higher-security environments, use the stronger hash required by the production or studio. Your team should verify at package boundaries. If you deliver by shooting day, verify each day. If you deliver by reel, verify each reel. That lets the receiver accept known-good packages while later packages continue to move. A transfer client saying “done” is not a delivery. The delivery is complete when the receiver can confirm that the expected files exist and the byte counts match. The checksums have to pass, and the package has to be readable by the next system in the workflow.

Plan for the destination, not just the upload

A lot of transfer plans only consider the sender’s side. That's how you end up with a perfect upload into a destination that can't ingest the package. The receiving side needs enough storage and write performance. It also needs the right permissions and a process for accepting the delivery. If the destination is cloud storage, check object limits, per-file limits, and daily upload caps. Check lifecycle rules too, and ask whether the recipient has egress concerns later. If the destination is on-prem shared storage, check available capacity, RAID or NAS write speed, and network interface speed. Then find out whether other work is already using the ingest machine. Common receiving-side failures include:

The destination account has a daily upload or storage quota.
The receiving drive uses a format with a file size limit.
The cloud bucket path or permissions are wrong.
The folder structure changes during download and breaks relinking.
The recipient can't see logs or verify what arrived.

These are unglamorous problems, which is why they hurt. They're easy to miss and expensive to debug during a deadline. For major deliveries, run a real test before the actual transfer. Don't test with a 200 MB file and assume the 6 TB handoff will behave the same. Use a sample large enough to exercise the path, ideally 100 GB or more, with a mix of file sizes similar to the real project. Measure sustained throughput, not the first minute of burst speed.

Don't improvise security at delivery time

Media delivery is part of the security boundary of a production. The transfer may include unreleased episodes, talent footage, or copyrighted masters. Client assets and project files with embedded credentials travel the same path. Convenience links and shared passwords aren't enough for sensitive material. For multi-terabyte internet delivery, security requirements usually include:

Named users rather than shared logins.
Encrypted transfer in transit.
Encryption at rest where the media is stored.
Access expiration or removal after delivery.
Audit logs for upload, download, and access.

Security also affects packaging. If one vendor only needs a VFX pull, don't send the whole turnover because it's easier. If a client only needs final masters, don't include project files, source media, or internal notes in the same package. Your team should upload files to a production-controlled destination first, then grant recipient access from there. That avoids losing control when someone uploads a transfer to someone’s personal cloud account or forwards it as an open download link.

When shipping a drive is faster

Sometimes the right answer is still to ship a drive. The internet isn't magic, and bandwidth isn't evenly distributed. A drive can win when:

The dataset is very large.
The available upload speed is poor or capped.
The distance is short or courier service is predictable.
The recipient can't accept cloud or managed transfer delivery.
The cost of cloud ingest, storage, or egress is higher than the courier workflow.

Compare the full path, not just courier time. Shipping a drive means copying to the drive, running checksum verification, and packing it. Then come pickup and transit, possible customs delays, and delivery. At the far end, someone mounts the drive, copies or ingests it, and verifies again. During transit, nobody can use the media unless you also started an internet transfer or sent a duplicate. A simple way to decide is to compare “time to usable files,” not “time to arrival.”

Compare the whole path to usable media, not just arrival.

Internet delivery time includes:

Preparing packages.
Uploading.
Verifying at destination.
Ingesting into the next system.

That's the online path to compare against the physical one. Drive delivery time includes:

Copying to drive.
Verifying the drive.
Courier pickup and transit.
Receiving and mounting.
Copying from drive.
Verifying destination storage.

Say a 10 TB upload will take six days on the available connection, and a courier can get a verified drive to the facility by tomorrow morning. Ship the drive. Now say a 4 TB upload will finish overnight, straight into shared cloud storage where editorial, color, and VFX can reach it. Uploading beats creating a physical blind spot. For extreme cases, cloud providers also offer physical transfer appliances. Those make sense when you need to move tens or hundreds of terabytes into cloud storage and the local internet path can't support the schedule. They're less relevant for everyday post handoffs, but useful for archive migrations, library moves, and large production ingest.

Hybrid delivery is often the best answer

The drive-versus-internet debate is too binary. Many real workflows benefit from both. Send proxies, project files, and priority selects over the internet immediately, then ship a verified drive with full camera originals. Editorial starts today, while the full-res safety copy follows. Or upload the day’s dailies every night, but rotate shuttle drives as a backup path. Or ship the first large baseline dataset, then send incremental changes over the internet after that. Hybrid delivery works especially well when the first upload would be huge but later changes are manageable. Once the receiver has the initial media, new turnovers and revised shots can move online without repeating the whole dataset. So can audio updates and project files. The key is to avoid two unsynchronized truths. If files travel by both drive and internet, maintain a manifest that says which package is authoritative, which version is current, and which packages the receiver has verified. Otherwise the team may waste hours comparing folders called “final,” “final_from_drive,” and “final_upload_retry.”

A sane multi-terabyte delivery plan

A reliable internet delivery looks like this in practice:

Measure the source size, file count, largest file, and deadline.
Measure sustained upload speed from the actual network you'll use.
Ask the receiver where to upload, how much space exists, what limits apply, and who will verify arrival.
Package the project into meaningful units, and put the units that unblock work first.
Generate checksums for each package, or use a transfer tool that does this in a way both sides can audit.

Then move the packages with a resumable client, agent, or managed transfer system rather than a browser tab. Keep the logs. While the transfer runs, watch sustained throughput and failed files, and keep an eye on destination capacity. If the connection drops, resume instead of restarting. If a package fails repeatedly, isolate it rather than rerunning the whole project. When each package completes, verify it at the destination and tell the team exactly what is ready. After delivery, keep the source copy intact until the receiver confirms verification and ingest. For camera originals or irreplaceable project assets, don't erase original media based only on “upload complete.” Wait for verified acceptance. Vagueness is what makes multi-terabyte delivery risky, not the size of the data. Measure the real bandwidth, cut the project into packages you can retry, and verify every package at the destination. If the math says six days and the courier says tomorrow morning, ship the drive.

FAQ

Convert the data size to bits, then divide by the sustained upload speed in bits per second. For example, 1 TB is roughly 8 terabits, so at a sustained 100 Mbps it takes about 22 hours before overhead. Then add margin. Protocol overhead, throttling, and packet loss all eat into the clean number, and so do disk speed, encryption, and destination limits. For shared or uncertain networks, doubling the clean math estimate is safer than assuming perfect throughput.

For most post workflows, splitting is safer. Good package boundaries are the shooting day or card, the reel or episode, and the department, priority tier, or destination. Smaller packages are easier to retry, verify, and ingest. A failed 500 GB package is manageable, while a failed 8 TB archive can put the whole delivery at risk. Large archives can help when there are hundreds of thousands of small files, but they should still be kept to a size that can be reasonably retried.

Browser uploads aren't designed for long, failure-prone media transfers. They may time out, restart poorly after interruption, or hide useful logs. Very large files and deep folder trees can break them outright. Multi-terabyte deliveries should use a resumable transfer client, a managed transfer platform, or a cloud agent instead. Whatever you pick has to handle retries, large files, and parallel transfers, and it has to give you logging, permission control, and integrity validation.

Use checksums or a transfer system that provides equivalent integrity validation. The sender generates a checksum manifest at the source and transfers it with the files. The receiver recalculates checksums after arrival, compares the results, and saves them with the delivery record. A transfer shouldn't be considered complete until four things are true: the expected files exist, byte counts match, checksums pass, and the package is readable by the next workflow system.

Shipping a drive can be faster when the dataset is very large, when upload bandwidth is poor, or when the connection is capped or unstable. The same is true when the recipient can't ingest from a cloud or managed transfer platform. Compare time to usable files, not just transit time. Drive delivery includes copying to the drive, verifying it, courier transit, receiving, copying to destination storage, and verifying again. If a 10 TB upload will take six days and a verified courier drive can be usable tomorrow, the drive likely wins.

Stage the delivery so project files, proxies, and priority reels or selects arrive first. In Aspect, editors can open media from a shared cloud filespace, which reduces the need to wait for every full-resolution file to land on a local drive before work begins.