What you get at handover

The checklist, in one place

This is what should be in your name and your accounts when a website project finishes. Take it to whoever built your site, ours or anyone else's. Every line is a thing you can check today rather than a promise about the future.

The timing matters as much as the list. None of this should arrive only at the end. If it is in your accounts from the point the site goes live, it is a position you hold. If it is promised for handover day, it is a promise, and promises are what get broken when a relationship ends badly.

Why this is so often missing

Very little of this is malice. It is convenience that hardened. It is faster for an agency to register the domain on its own account during a build, quicker to put hosting on a card already on file, and easier to keep the repository in an organisation they already control. Nobody decides to trap a client. The arrangement simply never gets undone.

The result is the same either way. The moment you want to leave, or the agency stops answering, every one of those conveniences is a locked door. The common version is not a dramatic dispute: it is a business that cannot update its own opening hours because the person who could is not replying.

• The domain is registered to the agency, so a transfer needs their cooperation at exactly the moment they have least reason to give it.
• Hosting is on their account, so your site is a line item on someone else's bill and can be switched off without you.
• There is no repository you can reach, so the only copy of the code is on a machine you do not own.
• The content lives in a system you do not have a login for, so an export means asking.
• Nothing is written down, so even with all of the above, a new developer starts by reverse engineering what exists.

Ask about this before you sign, not at the end. The answer is a fast read on how the relationship will work, and a supplier who is comfortable with the question is telling you something real. So is one who is not.

The question behind the checklist: what keeps running without them

Holding the assets is necessary and not sufficient. You can own the domain, the hosting and the code and still have a site that quietly depends on its builder. The second question is whether anything stops working when they stop being involved.

• Does the site call back to any service belonging to the people who built it?
• Is there a licence key, a seat, or a subscription of theirs that could lapse?
• Can your team still edit content, or does publishing go through them?
• If they disappeared tomorrow with no notice, what breaks first, and when?

That last one is worth asking out loud, because the honest answer from a small studio is not that they have a bench of people ready to step in. Most do not. The honest answer is that the project was built so it never depended on any particular person being reachable, and that is a claim you can check against the list above rather than take on trust.

This is our own position, so read it with that in mind: we publish it because a studio our size cannot credibly promise continuity through headcount. What it can do is build so that continuity does not require us. Those are different arguments and only one of them survives contact with a small team.

Moving to another developer

If the checklist is satisfied, changing supplier is an afternoon of admin rather than a rebuild. The order matters slightly, because you want to confirm the path works while the outgoing developer is still answering questions.

1. Give the new developer the repository and the deployment notes.
2. Have them deploy once, before changing anything, to confirm the path actually works end to end.
3. Remove the previous developer's access from the repository, the hosting project and any shared services.
4. Agree in writing what questions the outgoing developer will answer, and for how long after the engagement ends.

Step two is the one people skip and the one that catches problems. A deployment that has only ever been run on one person's machine is not a deployment process, and you would much rather discover that while the previous developer is still willing to talk.

What does not transfer, and why that is normal

Almost every studio reuses components, tooling and methods across projects. That reuse is why a build costs what it does rather than several times more, and it does not usually become yours outright. What matters is not whether the studio keeps it, but what you are permitted to do with the copy built into your site.

The arrangement worth having is a permanent licence to keep using what is in your site exactly as built, including changing and extending it. That is what lets a new developer run and modify the thing without going back to the original one. The arrangement to avoid is anything that expires, requires renewal, or needs permission later.

Get this in the agreement rather than in an email. Not because anyone expects bad faith, but because the terms of a relationship should not depend on the goodwill of whoever happens to be answering in two years, and a clause costs nothing to write while everyone is still friendly.

What this does not cover

• This is a checklist, not a contract and not legal advice. It tells you what to ask for and what to check. It does not tell you what your agreement says or whether it is enforceable where you are, and we are not lawyers.
• It describes how we work, so it is not neutral. Other studios structure things differently and some of those arrangements are perfectly reasonable. Treat it as one supplier's answer written down, which is more than most publish, rather than as an industry standard.
• It covers what you hold and how to move it. It says nothing about what a site should cost, how long a build should take, or how to judge whether the work is any good.
• Nothing here covers what happens to third-party accounts you signed up for yourself, such as analytics, email or payment providers. Those follow their own rules and are worth a separate list.
• The support period after an engagement ends is a term to negotiate, and we have deliberately not put a number on it here. The template it comes from carries it as a placeholder because it is agreed per engagement rather than fixed.

Sources

• What Scene client handover template, documents/transactional/continuity-and-handover. The public version of a template issued to real clients, defined in lib/documents/defs/transactional.ts. Read in full before publishing. The original contains no client names, rates or internal system details; every client-specific value in it is a placeholder. Run: documents/transactional/continuity-and-handover, version 2026.1, updated 2026-08-19.

Revisions

• 25 August 2026 First published, as the public version of the client handover template.

This page is revised in place rather than replaced, so its address does not change.