How to replace a video without changing the link
Send v2 down the link they already have.

The distinction matters because almost everything a delivery depends on is attached to the record, not to the file. The stored file is swapped, and the numbers that describe it are rewritten from the new upload: size, duration, frame rate and dimensions. The record keeps its id and its slug, so the watch URL does not move. It keeps its embed options, so every iframe already placed keeps working. It keeps its view count, its visibility and its password. The old object is then deleted from storage.

That is the whole feature. There is no second link to send, no note to write explaining which of two links is current, and no page anywhere that quietly keeps serving last week’s cut. A client who forwarded the link to three colleagues has, without doing anything, forwarded the new cut to three colleagues.

Google documents this plainly for YouTube. Its help pages state that “YouTube always re-encodes videos to optimize their playback quality”, that “when you upload a video, it will initially be processed in low quality”, and that a 60-minute 4K 30 fps video “can take up to 4 hours to finish high-resolution processing”. Vimeo’s help centre describes the same shape of step: during transcoding “your video file is re-encoded into several formats that will be available to view on Vimeo”, and its published playback ceilings top out at 22 Mbps for 4K and 7 Mbps at 1080p60.

For a re-delivery, that window is the dangerous part. A client who opens the link ten minutes after you say the new cut is up is not watching a soft version because your grade is soft. They are watching an intermediate. The notes that come back from that viewing are notes about an encode, and you will spend the next call explaining a problem that does not exist in your file.

Nothing is transcoded here and there is no rendition ladder, so there is no intermediate to catch. The player streams the exact bytes you uploaded, which means the new cut is live the moment the upload finishes and the first frame anyone sees is yours. The honest trade is on the other side of that: with no lower rendition to fall back to, a thin connection buffers instead of quietly switching to a mushy version. For an approval round, buffering that resolves is better feedback than a soft picture that does not.

The clean division is worth spelling out. Rounds of notes belong in the review room, where versions sit beside each other and approvals are recorded against the cut they were given for. The replace is for the moment after that: the film is signed off, the link is already in the client’s hands, in their deck and possibly on their site, and the only thing that should change is the file behind it.

If access is the thing you actually need to change, replacing the file does not do it. A swap leaves visibility and the password exactly as they were, which is deliberate. Cutting people off is its own operation, covered in revoking access to a shared link.

Most re-deliveries are the left column. A colour fix, a corrected supered name, a logo the client changed after sign-off: none of those are new work in the client’s mind, and handing back a new URL for them makes a two-minute fix look like a new deliverable. The right column is for cuts that are genuinely separate objects, where somebody will eventually need to open both.

One practical note for anyone arriving from another platform. If the copy of a film you are hosting today came across as whatever the old platform served rather than your master, the replace is also the upgrade path: put the true master onto the same record later, and every link and embed you have already placed starts serving it. The wider handoff, including which files a finished delivery should contain, is covered in delivering final video files to clients.