What a handover actually includes

Handover is the part of a project everybody agrees is important and nobody specifies. It usually arrives as an archive, a walkthrough call and a document, and it reads as complete until the first time you need it.

The test is not what you were sent. It is whether your team can make a change next month, on their own, and put it in front of visitors.

That is a higher bar than it sounds, and most of what fails it fails quietly. Here is what has to be in place, in roughly the order it matters.

Accounts, in your name

Every service the site depends on should be owned by your organization, on a billing account you control, with the person who built it holding access you can revoke. Not a seat on their agency plan. Not their personal account with your card attached.

The list is longer than people expect: the domain registrar, DNS, the host, the repository, the CMS, the analytics property, the error reporting, the form or CRM endpoint, any transactional email service, and every third-party key used in the build. Missing one of these does not stop the site working. It stops you moving, which is the same problem you were trying to solve.

The registrar is the one to check first. It is the single account that, if you do not control it, makes every other item on the list negotiable.

A repository you can actually build

Having the code is not the same as being able to run it. The check is specific and takes an afternoon: somebody on your side, on their own machine, clones the repository, installs it, builds it, and gets the same site.

What usually blocks this is not the code. It is the parts that were never written down. An environment variable that lives in one person’s shell. A build that only passes on a particular version of the runtime. A step that somebody has been doing by hand for months without noticing it was a step.

Do this once while the person who built the site is still available. An unbuildable repository discovered in month one is a question. Discovered in month eight it is an archaeology project.

The decisions, not just the instructions

Most handover documents explain how to do things. The more valuable half explains why the site is the way it is, because that is the part nobody can reconstruct.

Why the content model has these types and not others. Which URLs were deliberately retired and where they now point. Which integrations are load-bearing and which were inherited. Where a shortcut was taken, and what would have to be true to undo it. Which parts were built to vary and which were not.

Without this a new developer does the reasonable thing, which is to assume every existing decision was deliberate and work around it. That is how a site accumulates a decade of constraints nobody can name.

One real change, made by your team

This is the only part that actually tests the rest, and it is the part that gets skipped because the project is over and everybody is tired.

Pick something small, visible and reversible. Have somebody on your team make it, review it, and release it, while the person who built the site watches and does not touch the keyboard. Whatever they reach for and cannot find is the gap, and it will be found now or during an incident.

What makes this cheap is the same thing that makes a site safe for a contributor who is new to it: stated patterns, checks that catch the obvious mistakes, and a preview before anything is public. That is covered in what makes a site safe for an agent to change, and it applies equally to a person on their first week.

What support should be after that

A good handover does not end the relationship. It changes what the relationship is for.

Before handover, the people who built the site are the only ones who can change it. After, they are the people you call about the things you decided not to learn. The difference is that stopping is now an option, which is the only thing that makes the arrangement honest.

If a support agreement is the only way the site keeps working, the handover did not happen. It was renamed.