Moving your website or video host: keep project films connected

Inventory what exists before moving it

List each approved film and every known place it is used. Include project pages, embedded players, direct links, presentations and partner destinations where relevant. Identify the current owner of the hosting account and who can authorise changes.

Record the exact version and companion assets, such as caption files, transcripts, language alternatives and previews. A new video upload without its associated material may be an incomplete migration even when playback succeeds.

Separate current approved assets from retired or restricted material. A migration is not permission to make an internal film public or republish an old version that was deliberately withdrawn.

Ask the technical team what will change

Have the developer explain the proposed behaviour for existing page addresses, embed references and direct video links. Record decisions about redirects or replacements as applicable to the actual systems. Do not assume a host can preserve an old identifier or that a website redirect fixes a separately shared video URL.

Ask what happens to account access, privacy settings, caption support and any approved measurement arrangements. If historical analytics are needed, assign an owner to investigate export or retention before the old service is closed. Avoid promising that the new system will reproduce old metrics or comparisons.

Define acceptance evidence

Choose tests that cover the actual audience experience. They should include the correct film, required access conditions, companion material and next-step links. Test the new arrangement before the old one is retired where the migration plan permits.

The W3C media-player guidance identifies accessibility functions that depend on the player. A change of player therefore deserves a review against your established requirements, rather than an assumption that the same video file means the same experience.

Assign the relevant technical and accessibility reviewers. This buyer checklist is not a complete technical or accessibility audit.

Copy this migration register

Add the migration decision owner, planned change window, rollback contact and condition for retiring the old arrangement. Keep passwords and recovery information in the authorised credential system, not the register.

A fictional example: the proposal link is outside the website

A fictional company moves its project pages to a new website. Page redirects work, but its sales team has been emailing direct links to the old video host. Those links are not part of the website redirect plan.

The team adds them to the migration register, asks the hosting owner what continuity is possible and updates the sales resource index. This invented example illustrates an overlooked dependency, not a claim about how any named service handles links.

Plan the decision to switch, and the decision to stop

Agree who authorises the change after reviewing test results. Define which unresolved failures prevent release and what the technical team will do if a problem appears afterwards. A rollback plan should describe a feasible action confirmed by the responsible team, not simply say “restore the old site”.

Notify the people maintaining presentations, project indexes and partner links. Give them the approved replacement references and identify anything they must stop sharing. Record destinations you cannot control and the person responsible for contacting their owner.

After the move, test as the intended viewer rather than only through an administrator account. Keep the old arrangement until the authorised owner confirms it can be retired under the agreed plan. Update the release register with the new locations and ownership.

The practical finish is a verified set of working routes to approved films, with access and required companion material intact. It is not merely a successful file transfer or a new homepage going live.