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, but only if you treat it like a transfer workflow instead of a giant drag-and-drop. The difference is 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, but 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 Since storage is usually measured in bytes and bandwidth in bits, multiply terabytes by 8 before doing the math. Then account for overhead, throttling, packet loss, encryption, local disk speed, and the fact that “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 in production, add margin. For a one-time upload over a shared office connection, 30 percent margin is optimistic. For field networks, hotel internet, mobile routers, congested Wi-Fi, or an unknown client-side destination, double the estimate before promising a delivery time. The most important numbers 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, a locked master delivery, a VFX pull, and a full conform turnover all behave differently. The constraints that usually change the recommendation are:

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

The takeaway is simple: decide whether you're moving 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, stringouts, turnovers, or 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 often 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. This is usually better 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, but 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, painful through firewalls, weak on security unless you wrap it properly, and poor at giving non-technical recipients a clean 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, resume failed chunks, run multiple streams, or optimize TCP behavior. Some also support watch folders, transfer while a file is still growing, channel bonding across multiple networks, and direct ingest into object storage. 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, auto-resume, background agents, and unstable-network behavior matter more.

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 often 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 usually 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

For original camera data and high-value media, simple copy methods aren't enough because 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 usual verification pattern is:

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, xxHash, SHA-1, and SHA-256 all appear in real workflows. The “best” choice depends on tool compatibility and security policy. For media integrity, the most important thing 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 delivery isn't complete just because a transfer client says “done,” but when the receiver can confirm that the expected files exist, the byte counts match, the checksums pass, and the package is 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, and 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, write performance, permissions, and process. If the destination is cloud storage, you should check object limits, per-file limits, daily upload caps, lifecycle rules, and whether the recipient has egress concerns later. If the destination is on-prem shared storage, you should check available capacity, RAID or NAS write speed, network interface speed, and whether other work is 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 boring 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 at least a large enough sample 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, client assets, credentials embedded in project files, or copyrighted masters. 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 because 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.

The comparison should include the full path, not just courier time, because shipping a drive includes copying to the drive, checksum verification, packing, pickup, transit, possible customs delays, delivery, mounting, copying or ingesting at the destination, and verification 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.

If 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. If a 4 TB upload will finish overnight and upload directly into shared cloud storage where editorial, color, and VFX can access it, uploading is probably better than 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 usually too binary. Many real workflows benefit from both. For example, 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, revised shots, audio updates, and project files can move online without repeating the whole dataset. 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 usually looks like this in practice. Start by measuring the source size, file count, largest file, and deadline. Then measure sustained upload speed from the actual network you'll use. Ask the receiver where you should upload files, how much space exists, what limits apply, and who will verify arrival. Package the project into meaningful units. 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. Use a resumable client, agent, or managed transfer system rather than a browser tab. Keep logs. During transfer, watch sustained throughput, failed files, and 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. Multi-terabyte delivery over the internet is risky when the workflow is vague. Once you know the real bandwidth, divide the work into useful packages, use resumable transfer, verify integrity, and compare the internet path against courier time honestly, the decision becomes straightforward.

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. In real workflows, add margin for protocol overhead, throttling, packet loss, disk speed, encryption, and destination limits. For shared or uncertain networks, doubling the clean math estimate is often safer than assuming perfect throughput.

For most post workflows, splitting is safer. Package media by shooting day, card, reel, episode, department, priority, 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, hide useful logs, or fail when handling very large files or deep folder trees. Multi-terabyte deliveries should use a resumable transfer client, managed transfer platform, cloud agent, or other tool that supports retries, large files, parallel transfers, logging, permissions, and integrity validation.

Use checksums or a transfer system that provides equivalent integrity validation. The sender generates a checksum manifest at the source, transfers it with the files, and the receiver recalculates checksums after arrival. The results are compared and saved with the delivery record. A transfer shouldn't be considered complete until 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, upload bandwidth is poor, the connection is capped or unstable, or 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, selects, or priority reels 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.