The day a website goes live feels like the end of the project. It is not. It is the moment the project shifts from being the developer’s responsibility to being yours, and the quality of that handover determines whether the next few years feel like ownership or like dependence. A proper handover gives you the keys, the documentation, and the standing to run the site without needing to call the original developer every time something changes. A rushed one leaves you guessing.
The difference between the two rarely shows up at launch. It shows up six months later, when a plugin needs updating and nobody is sure which login to use, or when a form stops sending emails and nobody knows where the SMTP credentials live. The cost of a thin handover is paid in those moments, repeatedly, for as long as the site exists.
Here is what a proper handover actually includes — and what a rushed one quietly omits.
The accounts you must own
The most important part of a handover is not technical. It is administrative. By the end of the project, you should be the registered owner of every account the site depends on, with credentials in your name and billing on your card.
That list usually includes the domain registrar, the hosting account, the email delivery service (if separate), the content delivery network, the SSL certificate provider, any premium plugins or themes, any analytics tools, any backup services, and any monitoring services. Each of those is a small thing in isolation. Together, they are the deed to the property.
A common pattern in rushed handovers is that some of these accounts remain in the developer’s name “for convenience.” This is not convenience; it is a tether. Insist on having every account in your own name before the project closes.
Credentials, stored properly
Alongside ownership of accounts, you need the credentials for them — stored somewhere you can find them, in a form you can use, in a system that survives staff changes on your side.
A spreadsheet of passwords is not the right answer. A password manager — 1Password, Bitwarden, or similar — is the right answer. A proper handover delivers a complete vault of credentials, organised by service, with admin notes where the username is non-obvious. If the developer is sending passwords over email or in the body of a Word document, the handover is being done badly, regardless of how good the underlying work was.
While you are at it, check that the credentials work. A handover document with a wrong password is the same as no password at all. Test each login in front of the developer before signing off.
Documentation that actually documents
The handover document is the artefact you will return to most often. A good one does not have to be long. It does have to be specific.
It should describe the basic architecture of the site — what hosting it lives on, what stack it uses, what content management system runs it, what plugins or extensions are active, and what role each one plays. The reader does not need a developer’s understanding; they need enough context to follow a conversation with the next developer they hire.
It should describe the things that are unusual about the site. Every site has them — a custom integration with another system, a non-standard form handler, a quirk in how the navigation is structured, a specific reason a particular plugin is configured a particular way. These are the details that the original developer carries in their head, and that the next developer will spend hours rediscovering if they are not written down.
It should describe the editorial process. How posts are added, how images are uploaded, how navigation gets changed, how forms get edited. Not in technical terms, but in plain steps.
It should describe what happens when things go wrong. Where the backups are. How to restore one. Who to call. What the disaster plan is. Nobody wants to need this section. Everyone is glad it exists when they do.
The training conversation
A handover document, however good, is not a substitute for a conversation. A proper handover includes at least one training session, ideally recorded, that walks the client team through the parts of the site they will be expected to maintain.
The training should cover the things they will actually do, not the things the developer enjoys explaining. Adding a new page. Updating the homepage. Changing the team photo. Inviting a new editor. Running an update. Restoring a backup, just so they know it works. The session ends when the client can do each of these things themselves, in front of the developer, without prompting.
If you are taking handover and the developer is not offering this, ask for it. It is normal and reasonable. A developer who resists training a client is positioning themselves as permanently necessary.
A maintenance plan, even if it is “we do not have one”
Every site needs maintenance. Updates, backups, security, performance, the occasional fix. The handover should make clear what is going to happen to those needs after the project ends.
There are three reasonable answers. The original developer continues to maintain the site under a separate agreement. A different maintenance provider is brought in. The client team handles maintenance themselves. Each of these is fine. What is not fine is leaving the question unanswered. A site that lands at handover with no maintenance plan is a site that, within months, will be running outdated software, missing security patches, and accumulating risks nobody is monitoring.
If the answer is “the client team handles it,” that is the moment to confirm the team has the knowledge, the access, and the time to do so. If any of those are missing, the maintenance question is unresolved, regardless of what the contract says.
The source files
For any custom work — themes, plugins, integrations — you should receive the source files. Not just the compiled assets running on the live site, but the editable source the developer worked from. If the build is in Git, you should have access to the repository. If it is not, you should have the files in a clean, organised form.
This is the part of handover that is most often skipped, and the part that becomes most painful to recover later. Without the source files, the next developer who has to make a change is working blind. Both rebuilding from scratch and patching around it are expensive.
A clean handover includes the source files, the build process, any dependencies, and a brief note on how to set up a local development environment. The note can be one page. It is the difference between the next developer being productive on day one and being productive in week three.
The things a rushed handover omits
For comparison, here is what a rushed handover typically leaves out. Account ownership is informal. Some credentials are missing or wrong. The documentation is a single paragraph in a Word document. There is no training session. There is no maintenance plan. The source files are wherever the developer left them. The unusual aspects of the site live entirely in the developer’s memory.
None of this is malicious. It is just what happens when the handover is treated as a final task at the end of a long project, rather than a deliverable in its own right. The developer is tired. The client is keen to launch. The handover gets compressed to fit whatever time is left. Everyone signs off, the site goes live, and the gaps reveal themselves slowly.
What to do if you are receiving a thin handover
If you are taking ownership of a site and the handover so far has been thin, do not wait. Schedule a handover review while the original developer is still engaged and still responsive. Use the list above as a checklist. Identify the gaps. Get them filled before final payment is released, while you still have leverage.
This is not a sign of distrust. It is a sign of professionalism. A good developer welcomes it, because it formalises the close of the project. A developer who resists it is telling you something about what the next year is going to look like.
The short version
A project is not done when the site goes live. It is done when you have ownership of every account, working credentials for every login, documentation that explains how the site is put together, a training session that proves you can actually run it, a plan for who maintains it, and the source files for any custom work. A proper handover delivers all of those. A rushed one delivers a launched site and a slow accumulation of problems that arrive later, when fixing them costs more. The handover is the deliverable that determines what owning the site actually feels like.
