How to Transfer Raw Footage Between Two Editors

Handing raw footage to another editor looks like a file-transfer problem, but any editor who has received a "here's the footage" dump knows better: it's a project integrity problem. The gigabytes are the easy part. What actually breaks downstream edits is structure — renamed folders, cherry-picked clips pulled out of card structures, missing sidecar files — because the receiving editor's relinks, syncs, and multicam builds all depend on the footage arriving exactly as it was ingested.

This is a working checklist for footage handoffs between two editors — same studio or different continents — that arrive complete, verifiable, and relinkable.

Rule one: footage moves as folders, never as files

Camera cards aren't loose clip collections. A card offload contains structure the NLE and other tools rely on — spanned clips, metadata sidecars (XML, THM, LUTs), audio folders on sound recorders. Cherry-picking "just the good takes" out of that structure is how you get the classic disasters: a spanned clip missing its second half, audio that won't auto-sync because the recorder's folder layout is gone, or a relink that fails silently against renamed paths.

The rule: transfer the offload folder tree exactly as it sits on the source machine. Same names, same nesting, same everything. If the receiving editor wants a selects-only package, build that as a separate, additional folder — never by surgery on the original.

Rule two: agree the structure before the first byte moves

Thirty seconds of agreement saves a day of confusion. A minimal shape that works:

• PROJECT_NAME/01_FOOTAGE/DAY_01/A_CAM/ …card folders as offloaded
• PROJECT_NAME/01_FOOTAGE/DAY_01/AUDIO/ …recorder structure intact
• PROJECT_NAME/02_ASSETS/ …graphics, music, LUTs
• PROJECT_NAME/03_PROJECTS/ …the .prproj / DRP files, if this handoff includes them

The receiving editor should be able to point their project at 01_FOOTAGE and relink in one pass. If your handoff also includes the Premiere project itself, that's the same transfer with 03_PROJECTS riding along — the project file is tiny; it's the media that makes the handoff heavy.

Rule three: move it directly — the cloud round-trip is the bottleneck

A shoot day is routinely 100–500GB. Through a cloud service, that volume makes two full trips — up from the sender at upload speed, down to the receiver — with per-GB pricing or a storage plan in the middle, and a copy of unreleased client footage parked on someone else's server as a side effect.

A direct computer-to-computer transfer makes one trip, machine to machine. With ClickandSend the handoff looks like this:

1. Receiver opens the app, sets the destination to the actual edit volume (not the desktop — receive it where it will live), and shares the short connection code.
2. Sender drops the entire PROJECT_NAME folder in, pastes the code, sends. Folder structure — all of it, nested exactly as-is — travels intact.
3. Receiver approves the incoming transfer, and the copy runs disk-to-disk with progress on both ends.
4. If a connection drops mid-way through hour three, the transfer resumes where it stopped — per file, not from zero.

Two editors in the same building get an extra gift: on a shared local network the transfer runs at LAN speed, which turns "leave it overnight" into "grab a coffee." Two editors in different cities run at their connections' natural ceiling — still one trip instead of two, still no server in the middle. The broader storage-versus-transfer decision logic is covered in How to Send Large Video Files Without Uploading Them to the Cloud.

Rule four: verify before anyone deletes anything

The iron law of footage handling: no source copy gets deleted until the destination copy is verified. Verification doesn't need to be exotic:

• Count and size check. Total file count and total bytes should match between source and destination — the fastest way to catch a partial copy.
• Spot-play from the destination. Open several clips — first card, last card, longest file — from the received folder, not the source. Codec-level corruption shows up at playback.
• Relink test. If a project file traveled with the footage, open it on the receiving machine and confirm media links resolve before declaring victory.

Only after the receiving editor confirms all three does the sender's copy stop being the safety net.

The mistakes that actually burn people

• Zipping the footage first. Video is already compressed; zipping 300GB gains a rounding error and costs an hour of CPU on each end — plus a second 300GB of temporary disk space to unzip. Send the folder as a folder.
• Receiving onto the wrong drive. Landing footage on a laptop's internal drive and then copying to the edit volume doubles the total transfer time. Receive directly to the final location.
• Renaming "to be helpful." The sender tidies folder names in transit; the receiver's relink dies against the original paths. Structure is sacred; tidy on your own copy, never the handoff.
• No resume plan. Any tool that restarts a 400GB transfer from zero after a hiccup will, eventually, eat a weekend. Ask the resume question before you trust the tool.
• Deleting on "transfer complete." The progress bar finishing is not verification. Count, size, spot-play — then delete.

The full handoff, compressed

Agree the folder shape → receiver sets destination and shares the code → sender sends the untouched folder tree directly → transfer resumes through any hiccups → receiver verifies count/size/playback → source copy released. Once this is muscle memory, a footage handoff is an administrative task, not an event — and the receiving editor starts cutting the same day the drive would otherwise still be in a courier bag.

Once the footage is moving cleanly, the next bottleneck in a two-editor workflow is usually the review loop — for that, see How to Review a Premiere Pro Edit With a Client Remotely.

Download ClickandSend — portable, no installation, folder transfers with structure preserved and resume built in. 20 transfers free.

FAQ

What's the fastest way to transfer raw footage to another editor?

A direct computer-to-computer transfer — one trip at your connections' natural speed instead of a cloud upload followed by a download. On a shared local network, it runs at LAN speed.

Should I zip footage before sending it?

No. Video files are already compressed, so zipping saves almost nothing and adds compression time, decompression time, and temporary disk usage on both ends. Send the folder with its structure preserved instead.

How do I keep folder structure intact during a transfer?

Use a transfer method that sends folders natively rather than as loose files — ClickandSend transfers entire folder trees with subfolders and names exactly as they are on the source machine, which keeps relinks and audio sync working on the receiving end.

What if the transfer disconnects halfway?

With a resumable transfer it continues from where it stopped rather than restarting. For footage-scale transfers (hundreds of GB), resumability is the single most important feature to check for.

When is it safe to delete the source footage?

Only after the receiving editor verifies the copy: matching file counts and total size, spot-playing clips from the destination drive, and a successful relink if a project file was included.