How to leave a client without breaking production

The handover isn’t the last meeting. It’s the last three weeks.

TL;DR — the short version

Do any of these sound familiar?

• Your contractor’s last day was a Friday. By Thursday a nightly job had quietly stopped, and nobody knew whose it was.
• The handover was one long document. Nobody has opened it since.
• Months later, someone who left still has admin access to something. You found out in an audit.
• The README says the pipeline runs hourly. It runs daily.

People leave. Contractors leave on purpose — that’s the deal. The question is whether the system keeps working when they do. This summer I wrapped up a long engagement on a client’s GTM data platform: pipelines, internal apps, scoring, the lot. Here’s the short version of how I left without leaving a mess:

• Start early. The wind-down was planned two and a half weeks out, not on the last Friday.
• Hand over by topic, not by date. Five sessions, one subject each, with the new owner driving.
• Fix what you’d be blamed for later — stale docs, stopped jobs, flaky checks — while you’re still there to fix it.
• Keep an access ledger. Hand over what they need, then take yours back.

Here’s what those eighteen days looked like, and the five questions I’d ask before anyone’s last day.

Start the handover two and a half weeks out

The engagement had run most of the year. By the end I’d built a lot of what the go-to-market team ran on: the warehouse models, a couple of internal apps, an account score, the nightly checks that told us when something was off. When the client and I agreed to wrap up, the first thing I did wasn’t write a document. It was a planning call with the people who’d own things next, about two and a half weeks before my last day.

That call produced one list, in writing:

• What’s live — every job, app and report that runs without someone pressing a button.
• Who owns it next — a person’s name for each line, not a team.
• What’s unfinished — ranked, so nobody inherits a pile with no order to it.

Everything after that was working down the list.

Hand over by topic, not by date

The usual handover is one long meeting on the last day, or one long document nobody reads. Both fail for the same reason: they cover everything at once, so they cover nothing well enough for someone to act on alone. I ran five sessions instead, each on one subject, each with the person taking it over at the keyboard.

1. Data enrichment — how accounts get enriched, what triggers it and what it costs.
2. Hosting and deploys — how a change gets from dev to production, and how to read the nightly checks.
3. The internal app — where every number in it comes from, down to the one reporting table it reads.
4. Repos, single sign-on and access — how people get access, and how it gets taken away.
5. The last day — open questions, plus a walkthrough of the automated checks for someone who hadn’t seen them yet.

One timing detail mattered more than I expected. The last big launch went live a week before my final day. That meant I was still around for its first week of questions. If it had landed on my last day, that week would have been someone else’s problem.

Fix what you’d be blamed for later

A wind-down is the last time you’ll have full context on the system. So I spent part of it fixing the small things that would have turned into “the contractor left it broken”:

• Docs that didn’t match reality. Four repos said the pipeline ran hourly. It had moved to daily a month earlier to save cost. I corrected all four.
• Jobs that had quietly stopped. Two scheduled production jobs were suspended. A suspended job doesn’t fail loudly; it just stops. I repaired both.
• A check that cried wolf. One deploy check was failing a correct deploy. Left alone, the next person learns to ignore it, and then it can’t protect them. I fixed it before I left.

Access: hand it over, then take yours back

Access is where handovers quietly go wrong, because nothing breaks on day one. It breaks the first time someone needs a permission only you could grant — or it never breaks, and your old login sits there for a year. So access got its own session and its own ledger.

The rule I use: anything the system needs moves to a named person. Anything that exists only because I was there gets revoked on the last day. Tool seats tied to me were offboarded, and the new owner learned how sign-on groups map to each app, so the next access request doesn’t need me.

Leave the unfinished work in writing

There’s always unfinished work. The mistake is leaving it in your head. Before the last day I wrote a ranked list of what was left, plus a short note for the people a recent change would affect, so they heard it from a document instead of discovering it.

Five questions before anyone’s last day

Whether it’s a contractor or your own data hire, ask these with two or three weeks to go:

1. Does every running job have a named owner? A person, written down.
2. Do the docs match what the system actually does? Check the schedule against the scheduler, not the README.
3. Has each topic had its own handover session? With the new owner driving.
4. Is there an access ledger? What they hold, what moves, what gets revoked, by when.
5. Is the unfinished work written down and ranked? In a list someone else can pick up on Monday.

Two or more “no” answers and you don’t have a handover yet. You have a last day.

Which of the five would trip up your team today? And if you’ve been part of a handover that went well, what did it have that this list doesn’t?