Website client offboarding checklist: how to close a web project properly

The short answer

Closing a web project properly has five stages: final checks before launch closes, transferring ownership and access, handing over documentation, settling the commercial side, and recording a dated confirmation of what was covered and with whom. Offboarding is finished when neither side is waiting on the other and both know who is responsible for what.

The stages are in that order for a reason. Each one is cheaper while the project is still open, and every item that slips past its stage gets more expensive — a transfer chased in November costs a great deal more attention than the same transfer done in March.

Offboarding is bigger than the handover document

A handover document is one deliverable inside offboarding. Offboarding also covers the final quality checks, the account transfers, the money, and the agreement about what happens after launch. A perfect document does not close a project on its own.

It is worth being precise about this because the two get conflated, and the parts that get dropped are always the same ones. Agencies write good documents and forget to confirm that the analytics ownership transfer was accepted. Or they transfer everything cleanly and never say out loud where the warranty period ends, so month four brings a bug report that both sides believe the other should pay for.

The document is the artefact. Offboarding is the process, and the last stage of the process is the one that makes the difference: writing down that it happened.

1 · Before launch closes

The checks that are cheap now and expensive later: a final quality pass, a backup taken and restored once, analytics and search tools verified as actually collecting, forms confirmed as actually delivering, licences accounted for, and the admin users tidied.

Verify, do not assume

Three things fail silently after launch and are found weeks later by accident:

• Form delivery. Submit every form on the live site and confirm the message arrives at the address it is supposed to reach. Contact forms that post successfully and deliver nowhere are the most common post-launch failure, and the client discovers it by wondering why business is quiet.
• Analytics collection. Load the live site and confirm the traffic appears. A property that was set up but never verified is a year of missing data nobody can recover.
• Search tools. Property verified, sitemap submitted, and the staging site’s crawl blocking removed from production — while confirming staging itself is still blocked.

Backups and restores

Take a backup, and restore it once somewhere harmless. An untested backup is a belief, not a safeguard, and the moment to discover it does not restore is not the moment you need it.

Licences and users

Account for every commercial theme, plugin and font licence: whose account it sits in, when it renews, and what stops working if it lapses. Then remove the administrator accounts that only ever existed for the build — contractors, test users, the account named after a former colleague — and leave a named administrator for the client.

2 · Transfer

Move ownership of everything the client should own, and verify each transfer was accepted rather than merely offered. An invitation sitting unopened in an inbox is not a transfer, and recording it as one is a claim you may have to defend later.

The list is usually shorter than it feels: the domain and registrar access, hosting, the CMS or platform account, analytics and search tools, the business profile, any advertising accounts, the integrations the site depends on, and the design and brand assets. Work through it once and it is done.

Two rules make the difference between a transfer and a gesture:

1. Transfer access, not passwords. Where a service supports named users with roles, invite the client as owner and remove yourself when the engagement ends. There is then no shared secret to hand over at all.
2. Move any unavoidable shared credentials separately. Through a password manager or a channel that expires — never inside the handover document, and never in email or chat.

Then check each one. Accepted, not pending. It takes ten minutes and it is the difference between offboarding and optimism.

3 · Documentation

The client should end up with one document that says what was built, where everything lives, who owns each account, how to make the edits they will actually make, what recurring maintenance exists and who does it, and who to contact when something breaks.

That document is the subject of most of this site, so this section will not repeat it. What matters at the offboarding stage is that it is finished and reviewed rather than promised: a manual sent three weeks after the final invoice is a manual nobody reads, because by then the client has stopped thinking about the project.

Two parts of it belong to offboarding specifically rather than to documentation in general:

• The maintenance schedule with named owners. Some of those rows are the client’s. Those are the rows that quietly stop happening, and a name is what prevents it.
• The scope boundary after launch. What the ongoing arrangement covers, what is billed separately, and when the warranty period ends — as a date, not as “30 days”.

4 · Commercial closeout

Settle the final invoice, state when the warranty or bug-fix period ends, name what falls outside it, and make the ongoing arrangement an explicit yes or an explicit no. An unfinished commercial conversation is what turns into a year of small unbilled requests.

The awkward part is not the invoice. It is the boundary, because agencies avoid drawing it and then resent it every time it is crossed. The useful framing is that a boundary protects the client too: a client who does not know what is included cannot ask for anything without wondering whether they are imposing, and that uncertainty costs goodwill on both sides.

Four things to have written down before the project closes:

• Final payment — raised, and its due date agreed.
• Warranty period — what it covers, and the date it ends. Defects in what was built are usually in; new requests are usually out.
• Support boundaries — which channel requests arrive through, and what response time applies, if any. Only publish one you intend to honour.
• The ongoing arrangement — a care plan they have accepted, or an hourly rate they have agreed, or an explicit “no ongoing arrangement”. All three are fine. Silence is not.

“No ongoing arrangement” deserves saying out loud. A client who believes they are covered and is not will discover it during an outage, and that is a worse conversation than the one you avoided.

5 · Confirmation

Go through the handover with the client, then write down the date, the person you went through it with, and which items were transferred and reviewed. Keep it a record rather than presenting it as a signature.

The review is worth doing live, in a call or a meeting, because it is the only moment you will find out what the client did not understand. Reading a section aloud produces questions that reading it alone does not, and every one of those questions is a support request that now will not arrive later.

The record itself is three lines and settles the argument that actually happens six months on — which is never about what the document said, but about whether the registrar account was genuinely handed across. What it should not pretend to be is a signature: anyone can type a name into a web form, and a page with no login behind it cannot tell you who filled it in. If a countersigned document is genuinely required, use a signature tool and link the handover document from inside it.

Why this makes maintenance easier to sell

A client who can see a written list of the work that still exists after launch understands why an ongoing arrangement exists. A client who never sees that list assumes the website is finished, because from where they are sitting it looks finished.

This is worth stating carefully, because there is a manipulative version of it and that is not what is being described. The honest version is about clarity of responsibility. Backups happen or they do not. Updates are applied by someone or by nobody. The domain renews on somebody’s card. Enquiries are checked, or they arrive somewhere nobody is reading. Those tasks exist whether or not anybody has written them down.

All a good offboarding does is make them visible and put a name against each one. Some names are yours and some are the client’s, and a client looking at that split can make a real decision — take on the six rows with their name against them, or ask you to. Either answer is a good outcome. What is not a good outcome is the client assuming the rows are handled when nobody is handling them, which is the default when the list does not exist.

The commercial effect follows from the clarity rather than from any persuasion: an agreement about who does what is far easier to price than a vague sense of ongoing availability.

The checklist

All five stages as lines to work through. Strike out anything that genuinely does not apply rather than leaving it blank.

Related guides

• Website handover checklist

  The documentation stage in detail — what to give the client, in seven groups.

  Read the guide

• Website handover template

  The eleven sections a handover document needs, and a skeleton to copy into any tool.

  Read the guide

• Handing over passwords safely

  How to move credentials during the transfer stage without putting them in the document.

  Read the guide