Client Offboarding for Freelancers: A Handover That Holds Up

The invoice clears. You send a warm note. Three weeks later the client emails asking why their contact form stopped working, and you realise the form was wired to a service still billing your card, under an account still using your email, on a domain still sitting in your registrar account.

Nobody planned that. It is just what happens when a working relationship ends the way most of them do: on goodwill, verbally, with no list. Onboarding gets all the attention in freelance advice because it is the part that feels like marketing. Offboarding is the part that decides whether the client can operate without you, and whether you can walk away without leaving your name attached to their infrastructure.

The relationship ends twice

There is the commercial ending, the final invoice, and the operational ending, the day nothing of theirs depends on anything of yours. Most freelancers treat those as one date. They are almost never one date, and the gap is where the awkward emails live.

The commercial ending you already manage — you have terms, you have a due date, you probably chose between net 15 and net 30 when you wrote the contract. The operational ending has no default. No invoicing tool prompts you for it. So it does not happen, or it happens badly, in a scramble of password screenshots sent over Slack.

Sort the engagement by custody, not by task

The usual advice here is a checklist of tasks: export the files, send the passwords, ask for a testimonial. Task lists fail because they mix things with completely different failure modes into one list of equal-looking bullet points. Handing over a Figma file and handing over a domain registration are not the same kind of act, and only one of them can go wrong in a way that takes two months to unwind.

A more useful sort is by custody — who currently holds the thing, and what the consequence is of that not changing. Every engagement resolves into three classes.

Custody class	Typical examples	What goes wrong if you skip it	When it has to be handled
Registered in your name	Domain, hosting plan, SaaS seats you pay for, an app you created inside their platform	You are still the legal or billing party for a business you no longer work for	Earliest — it has external waiting periods
Theirs, held by you	Their customer data, their logins in your password manager, drafts, raw files	You are holding personal data with no lawful reason and no contract covering it	After delivery is confirmed, on a stated date
Yours, used by them	Your process docs, templates, scripts, unlicensed working files	Ambiguity later about what they bought and what they borrowed	Stated in writing at handover
Shared history	Thread archives, project notes, the reasoning behind decisions	The next person redoes your work badly and blames the previous freelancer	Bundled with the handover document

Only the first class has clocks you do not control. That is why it goes first, and why the rest of this is arranged around it rather than around the calendar.

Things registered in your name are the ones that bite

The category is bigger than people expect. It is not just the domain. It is the hosting account opened on your card during the build, the transactional email service where you are the owner and they are a “team member”, the analytics property created under your personal login, the developer app registered against your account so an integration would ship on time.

Each was a small, reasonable decision made under time pressure, and each leaves your identity welded to their operation. The test worth running before the last month of any engagement: if I disappeared tomorrow, what of theirs stops working or stops being reachable? Everything on that list is class one.

Billing ownership and account ownership are different switches

Changing the card on file does not make them the account owner. Adding them as an admin does not remove you as the owner. On most platforms these are two separate settings in two separate screens, and doing only the first is the most common half-finished handover there is — the client pays for a tool that you still ultimately control, which is the worst of both arrangements.

ICANN’s policy tells you the order, and it is the reverse of what most people do

The domain is the one asset where an internet-wide rule, not a vendor, sets the pace. If you registered the client’s domain under your own name or email, handing it back involves two distinct operations that people routinely perform in the wrong order.

The first is a Change of Registrant — updating who the registered name holder is. ICANN’s Transfer Policy defines this as a material change to the registrant’s name, organisation, or email address, which means simply swapping your email for theirs counts. The second is an inter-registrar transfer — moving the name from your registrar to theirs.

Here is the trap. Under the policy as published, the registrar “must impose a 60-day inter-registrar transfer lock following a Change of Registrant”, unless the holder was offered and took an opt-out before the change. So if you update the registrant details first and then try to move the domain to the client’s registrar, you can find the transfer blocked for two months. The policy itself anticipates this: it requires the registrar to tell the prior registrant that if the goal is to end up at a different registrar, they are advised to request the inter-registrar transfer before the Change of Registrant. Almost nobody reads that notice, and almost nobody does it in that order.

Two further details matter in practice. A completed inter-registrar transfer cannot be repeated for 60 days, and a newly registered domain cannot be transferred at all for its first 60 days — so a domain you bought last month for a project that just ended may simply refuse to move. And a registrar is not allowed to hold the transfer authorisation code hostage over a billing dispute: the policy obliges it to supply the code and lift the transfer prohibition within five calendar days of your request.

One caveat on freshness, because this area is moving. The 60-day lock regime is what the current published policy requires, but it is being revised: at ICANN’s March 2025 meeting the 60-day transfer lock was eliminated in favour of a 30-day lock on new registrations and transfers, with implementation rolling out to registrars over the following period, as Wikipedia’s summary of registrar transfer rules records. Which regime your registrar is running today is a question for your registrar’s help pages, not for a blog post. The sequencing advice survives either way: move the domain first, change the holder second. (Policy text read at the ICANN Transfer Policy, consulted 20 September 2026.)

Things of theirs sitting in your tools

The mirror image of class one is everything of the client’s that lives inside your stack. Their customer list in your email tool. Their brand assets in your cloud drive. Their staff logins in your password manager, added during the build so you could test something.

Two moves close this out. First, return anything they would need and might not have: exports rather than screenshots, in formats their next person can open. Second, and more often skipped, delete your copies and say that you did, with a date. Holding a former client’s customer data indefinitely is not a favour to them — it is an unexamined liability sitting in your account, and if it includes personal data about their customers, it is one with a regulatory dimension in most of the markets freelancers serve.

Revoke your own access, deliberately

Remove yourself from their workspaces rather than waiting for someone to notice. It reads as professional and it ends the quiet risk that a breach of your account becomes a breach of theirs months after you stopped working together. If your CRM holds the record of the engagement, mark the account closed there too, so a future pipeline report does not treat a finished client as a live one.

Things that stay yours

The third class is the one freelancers under-claim. The deliverable is theirs — that is what they paid for. Your working method is not: the intake questionnaire, the brief template, the QA checklist, the scripts you reuse across clients. If those were shared during the engagement, the handover is the moment to state plainly that they were provided for use on this project and are not part of the transfer.

Portfolio rights belong here too, and they are easiest to secure while goodwill is still fresh. One sentence in the handover note — may I show this work, with or without your name, from what date — settles a question that is unpleasant to raise eighteen months later. This is also the natural moment for a testimonial request, for the same reason: the client’s memory of the work will never be better than it is this week.

Sequencing access against the final invoice

The genuinely difficult question in offboarding is whether you hand over access before or after you are paid, and the honest answer is that neither pure position works. Withholding everything until payment clears turns a normal closing into a standoff and is often not what your contract actually permits. Handing over everything first removes the only leverage you have.

The workable version is to split the handover along the custody classes. Deliverables and their data — class two — go across on acceptance, because that is what the engagement was for. Ownership transfers of things registered in your name — class one — are scheduled for a named date tied to payment, because those are administrative acts, not the product, and because they take time anyway. Written and agreed in advance, that reads as a project plan. Improvised at the end, the identical arrangement reads as a hostage situation.

Set that expectation at the start, not the finish. The same document that carries your welcome packet can carry a two-line closing clause describing what happens at the end of the engagement, and your onboarding process is the only place it will actually get read. If you are still assembling that side of the business, the rest of the proposals, contracts and CRM material covers the documents this attaches to, and the invoicing tools comparison covers the side that triggers the date.

Charge for the handover

The last reframe is commercial rather than procedural. Everything above is real work: account migrations, exports, a written record of decisions, sequencing around a transfer lock. Freelancers do it for free, at the exact moment they have the least motivation to do it well, and then absorb the follow-up questions for months.

It prices better as a line item. A named handover package — ownership transfers completed, access revoked, a short document of what lives where and why — is easy to justify because the alternative is visible to the client the first time something breaks and nobody knows the password. It also sets a boundary on the unpaid support tail, because a documented handover has a defined end and a verbal one does not.

The freelancers who never seem to have messy endings are rarely the ones with better relationships. They are the ones who wrote down, at the start, what the last week would look like — and then treated that week as a deliverable rather than a formality.

This article describes contractual and administrative practice, not legal advice. Domain transfer rules vary by registry and registrar, and data protection obligations vary by jurisdiction. Check your registrar’s current policy and your own contract before acting.