How to Transfer Large Field Files When Email Won't Work

The files that matter most from a day in the field are the ones email cannot carry. A raw GNSS session, a LAS point cloud, an hour of drone footage, a 300-photo set, a multi-gigabyte zip of the whole job: each of these is bigger than any mailbox will accept as an attachment. So the crew improvises. They split the send across a dozen messages, drop a personal file-share link into a thread, or leave a thumb drive on someone's desk next week. Every workaround gets the bytes moving and loses the thread of what was actually delivered.

Moving large field files is a different problem from sending a message, and it needs a method built for the size, the connection, and the handoff all at once. This post is that method: why email hits a wall, why the way you move the bytes matters as much as the bytes themselves, and a concrete sequence a crew can follow every time. It sits inside the larger picture of moving work from the field to the office, which is the workflow this fits into.

Why email hits a wall on size

Email attachment limits are small and unforgiving. Most providers cap a message around 25 MB, and some corporate gateways sit lower. A single modern phone photo can run 5 to 12 MB, so a real photo set blows past the ceiling before you have covered one room. Raw survey data, laser scans, and video are not close: they are tens or hundreds of times too large to attach at all.

The worse part is how email fails. A message that is too big does not always bounce immediately. It can sit in a queue and bounce hours later, or get silently stripped of its attachment by a gateway, or be downsized by a phone mail client that quietly re-compresses images to fit. In every one of those cases the crew sees a message leave the outbox and assumes the job is delivered. They drive away. The office never gets a complete packet, and nobody learns that until someone opens the folder days later and counts eighty photos where there should be three hundred.

The way you move the bytes matters

Once files are too big to attach, the natural next step is a send-a-big-file service or a shared drive. Those clear the size problem, but many of them route the file the wrong way. The bytes travel from the device, up to an application server, and back down to storage, so a busy server or a small laptop acting as the middle hop becomes the bottleneck for a 40 GB upload. On a job trailer running one weak connection, that middle hop is exactly where large transfers stall and time out.

The transfer should go direct from the device to storage. The file never passes through an app server or a field laptop; the device streams it straight to the storage bucket, and the server only records that it happened. That single design choice removes the slowest link in the chain and lets the upload use whatever bandwidth the connection actually has. It is the difference between a transfer that scales with your signal and one that is throttled by a machine in the middle. If you are weighing the categories of tool that do this well against the ones that do not, the rundown of what to use instead of email for large files walks through the trade-offs.

Resumable uploads survive a dropped signal

Field connections drop. A truck moves behind a hill, a hotspot runs out of bars, a phone rolls over from one tower to the next. An ordinary upload treats that interruption as fatal: the transfer fails and starts over from zero. On a large file over a thin connection, that means a 90-percent-complete send is thrown away and re-attempted from the first byte, often failing again before it finishes.

A resumable upload breaks the file into parts, confirms each part as it lands, and picks up from the last confirmed part after the signal returns. A dropped connection costs you the one part in flight, not the whole file. This is the single most important property for large transfers in the field, because it turns an unreliable connection from a showstopper into a delay. The mechanics of why this works, and how multipart uploads recover, are covered in the companion piece on uploading jobsite files on an unreliable connection.

One packet, not a scatter of sends

Even when the bytes move reliably, a large handoff falls apart if it arrives as loose pieces. Split a job across ten messages, three links, and a drive, and the office has to reassemble it from fragments that landed in different places at different times, with no way to know when they have all of it. Missing one fragment looks exactly like having the whole thing.

The fix is to treat the whole delivery as one unit. The crew composes a packet: all the files, a short cover sheet that says what the packet is and which job it belongs to, and a job number, kept together and sent to one central intake queue instead of scattered across inboxes and services. The office receives one thing with a clear boundary, not a pile it has to guess the edges of. A packet either arrived complete or it did not, and you can tell which at a glance.

Verify the transfer, do not assume it

“Sent” is not “delivered,” and “delivered” is not “complete.” A large file is exactly where the gap between those shows up, because a truncated point cloud or a photo set that lost its last hundred images still opens and still looks like a file. The only way to know a transfer finished intact is to check the bytes against a fingerprint.

That fingerprint is a checksum. A SHA-256 hash is computed for each file on the device before it leaves, and the same hash is recomputed on the server after the bytes land. If the two match, every byte arrived; if they do not, the file is re-sent. Only when all the files verify does the packet count as submitted, and only then does the crew get a numbered receipt with the file count and the total verified size. That receipt is proof the transfer is whole, not a hope that it is.

A method a crew can follow

Put the pieces together and the routine is short. It works the same for a survey crew with raw rover files, a construction crew with drone footage, or anyone else whose real files are too big to email.

1. Gather everything into one packet on the device. All the files for the job, a one-line cover sheet describing what they are, and the job number. Do not send pieces as they finish; assemble the whole delivery first.
2. Fingerprint each file before it leaves.A checksum is computed on the device so there is a known-good hash to verify against later. This is what makes “complete” something you can check rather than assume.
3. Upload direct to storage. Stream the files straight from the device to the storage bucket, not up through an app server or a laptop, so the transfer uses the full connection instead of a middle hop.
4. Let it resume; do not babysit it. If the signal drops, the upload picks up from the last confirmed part when it returns. A packet composed with no signal at all can wait on the device and send itself once a connection is back.
5. Wait for server-side verification and the receipt.The packet is not submitted until every file's checksum matches on the server. The numbered receipt, with file count and verified size, is your confirmation the transfer is whole.
6. Let the office take it deliberately. Ownership stays with the crew until an office tech accepts the packet by name. Viewing or downloading to check it never moves responsibility; one deliberate accept does, and a write-once archive copy is stored the same moment.

Notice what this routine never asks the crew to do: split a file, chase a bounce, keep a list of which link had which folder, or re-drive to hand off a drive that did not upload. The size problem, the connection problem, and the handoff problem are handled by the method, not by anyone remembering to be careful.

What this replaces

This is not a better email habit and it is not a bigger attachment. It is a transfer built for the shape of the job: large files moved direct to storage, resumable over a connection that comes and goes, packaged as one tracked packet, and verified byte-for-byte before it counts as delivered. If your current answer is a link-based service that expires and leaves no lasting record, it is worth comparing that against a tracked intake queue; the writeup on choosing a tracked alternative to a send-a-big-file link covers where the two differ. Either way, the goal is the same: when the crew drives off, the office already has a complete, verified packet and a receipt to prove it.