What good looks like at handover

The pass condition

Most handovers are graded on whether documents were produced. That is the wrong test, because documents can be complete and useless, and every organization that has inherited a beautiful architecture diagram alongside a system nobody can deploy already knows this. The right test is behavioural: put two of your own people in front of the system, have them perform the real operations while the builders watch in silence, and see what happens. Everything below exists to make that test passable.

Handover deserves attention out of proportion to its share of the budget because it is where the value of the whole engagement is either banked or lost. A system your team cannot operate is not an asset; it is a liability with a support contract attached. And the failure is quiet — it does not appear at the closing meeting, where everyone is agreeable. It appears eleven weeks later when something breaks and nobody knows why.

We build systems and hand them over, so read this as the standard we hold ourselves to. It is also a standard you can apply to any vendor, and the useful thing about it is that it cannot be satisfied with paperwork.

The nine artifacts

The code, in your repository, building from clean. Not a zip file, not a copy in the vendor’s account. Your organization’s repository, with the history, and a documented build that succeeds on a machine that has never seen the project.

Infrastructure defined as code. The environment should be reproducible from a definition rather than from somebody’s memory of what they clicked. Where parts were configured by hand, that must be written down explicitly, because the undocumented click is the thing that fails during your first recovery.

A runbook for the things that go wrong. Not an overview. A list of the specific failures this system actually has — the upstream feed arriving late, the job that occasionally needs re-running, the credential that expires — with symptoms and the exact steps for each. The good version was written from real incidents during the build.

Credentials rotated and owned by you. Every key, token and service account inventoried, rotated at handover so that no departing engineer holds a live credential, and each one recorded with an owner and an expiry. Expiry is the most common cause of a system that runs perfectly for four months and then stops.

Data lineage. Where each input comes from, on what schedule, what happens when it is late or malformed, and which source wins when two disagree. This is the knowledge that is most expensive to reconstruct and most often left in people’s heads.

The evaluation set and its baseline numbers. For anything with a model or a ranking in it: a held-out set of examples with correct answers, the score the delivered system achieves on it, and the command that reproduces that score. Without it your team cannot safely change anything, because they cannot tell an improvement from a regression.

A dependency and licence inventory. What the system depends on, at which versions, under which licences, and which of those have commercial terms that follow usage. Nobody enjoys this document and it prevents a specific, expensive surprise.

A cost model. What it costs to run per month at current volume, which components dominate, and how the cost moves if volume doubles. Systems handed over without this produce their first unpleasant invoice in your name.

The honest backlog. What was deliberately not done and why, what is known to be fragile, and what the builders would fix first if given two more weeks. A handover with no such list is not a handover with no such items.

The transfer test

Schedule a day. Name two people from your side — the ones who will actually own this, not their managers. The builders attend and do not touch the keyboard. Then work through the real operations in order.

Deploy it. Your people, following the written steps, into a real environment. This alone finds most of what is missing.

Break it deliberately and recover. Revoke a credential, feed it a malformed input, stop a dependency. Your people diagnose it using the runbook and fix it. If the runbook does not cover it, that is a finding, not an embarrassment, and it gets written in on the day.

Ship a real change. Something small but genuine — a new field, a threshold adjusted, a report column. Your team writes it, tests it, and puts it into production. This is the step most often skipped and the one that proves ownership, because a team that has never changed a system does not own it.

Reproduce the numbers. Run the evaluation and get the same score the vendor reported. A number that cannot be reproduced on your machines is a claim, not a measurement.

Everything that does not work becomes a written item with an owner and a date, and the handover is not complete until those close. A day spent this way is worth more than any amount of documentation review, and it is remarkably hard to fail quietly.

Ownership questions, settled at the start

The end of a project is the worst possible time to discover who owns what. Every item below should be answered in the contract, and each has a default that may not be the one you assumed.

Asset	The question	What to require
Custom code	Assigned to you, or licensed to you?	Assignment on payment, in your repository
Model weights	Yours, or the vendor’s reusable asset?	Yours, with the training configuration
Prompts and rules	Often unmentioned, and load-bearing	Named in the deliverables, versioned in the repository
Training and labelled data	Who may reuse it afterwards?	Yours; specify what the vendor may retain
Vendor frameworks	Pre-existing tooling, licensed to you	Written licence, transferable, no expiry
Third-party components	Licences that follow usage or revenue	Full inventory before the last invoice

A vendor reusing their own framework is normal and often good for you; it is how a small team delivers quickly. What is not acceptable is discovering at the end that the reusable part is licensed annually and the system does not run without it. Ask in week one. The answer is not a problem — a surprise is.

The knowledge nobody writes down

Every system carries decisions that look arbitrary and are not: this library rather than the obvious one, because the obvious one failed on your data volumes. This threshold, because the operations team asked for fewer false alarms. This apparently redundant step, because a source system occasionally sends duplicates.

None of that survives in code. Without it, the first inheriting engineer “cleans up” something load-bearing within a few months, and the failure is confusing because the code that broke looks unnecessary. The counter-measure is a decision log — one short entry per non-obvious choice, kept in the repository, written when the decision is made rather than reconstructed at the end. Twenty or thirty entries is typical, and each is three sentences: what was decided, what the alternative was, why.

The thirty-day tail

A handover that ends on the last day of the contract is an event, not a transition. Real systems produce their first surprises after two or three weeks of ordinary operation, which is precisely when the builders have gone.

Structure the exit in three stages. In the final fortnight the vendor is present but your people do the work, with the builders answering questions rather than typing. For the following month, keep a small support commitment — a named contact, a response time, and a modest block of hours — drawn on as needed. After that, a defined and optional arrangement for anything further.

Budget it explicitly. A proper handover with the transfer test, the artifact gaps closed and a month of support typically runs somewhere around five to ten percent of the engagement. Left as an assumption it becomes a rushed week at the end, paid for out of goodwill, and goodwill is thin in the final fortnight of a project.

A handover with stages

The stage most often cut is the shadow period, and it is the one that makes the rest work. Watching a walkthrough teaches almost nothing; doing the operation while somebody experienced watches teaches almost everything. Two weeks of that is worth more than any document in the list above.

Why vendors are frequently bad at this

Worth saying plainly, because the incentive is structural rather than personal. Handover work is unglamorous, it is often the least well specified part of the contract, and it happens exactly when the team has been reassigned to the next engagement. In some firms a customer who cannot operate the system is also a customer who keeps paying for support, which is a conflict nobody states out loud.

The counter is contractual and simple. Write the artifact list and the transfer test into the statement of work at the start. Make final payment contingent on the test rather than on a date. And ask any prospective vendor what their last handover consisted of; the ones who do it well answer with specifics and the ones who do not answer with a description of their documentation standards.

If the handover already went badly

Common, and recoverable, though it costs more than doing it properly would have. Work in this order: get it deploying from clean, because everything else depends on that; rotate every credential and inventory what exists; write the runbook from whatever incidents you have had since; then build an evaluation set so changes can be made safely.

Expect two to four weeks of a competent engineer’s time for a system of moderate size. And if the original team is still reachable, a small number of paid hours from them is usually the cheapest money in the whole exercise — far cheaper than reconstructing their reasoning from the code.

The mistakes we are called in to fix

• A documentation package instead of a transfer test, signed off by people who will never operate it
• Credentials never rotated, leaving departed engineers with live access for months
• No evaluation set, so no change can be made without risking a silent regression
• Model weights or prompts owned by the vendor, discovered at the final invoice
• Infrastructure configured by hand and undocumented, failing at the first recovery
• Handover compressed into the last three days when the build ran late
• No support tail, so the first real incident arrives with nobody to ask

Handover acceptance

• Your two named people deployed it from written steps, unaided
• They broke it deliberately and recovered it using the runbook
• They shipped one real change into production themselves
• The reported evaluation numbers reproduced on your infrastructure
• Every credential rotated, inventoried, owned and dated for expiry
• Code, weights, prompts and data confirmed as yours in writing
• Dependency and licence inventory delivered, with the monthly cost model
• Decision log present, and an honest list of what was left undone
• A named support contact and response time for the following thirty days

Bottom line

Judge a handover by what your people can do, not by what the vendor produced. Two of your own engineers should deploy it, break it, fix it and change it while the builders watch without touching anything — and the reported numbers should reproduce on your machines. Write that test into the contract at the beginning, budget five to ten percent for the transition, keep a support tail for thirty days, and settle the ownership questions in week one rather than the final week. A system handed over this way is an asset your team can improve. One handed over as a folder of documents is a system you will pay to understand twice.

Frequently asked questions