The Handover Package: Making Sure Your Software Outlives Your Vendor

The Handover Package: Making Sure Your Software Outlives Your Vendor

Every consulting engagement eventually raises the same question, asked carefully: what happens if you disappear? Clients mean it about the one engineer who understands the codebase, and that's a fair worry.

But the more common failure mode isn't a person leaving — it's the agency itself. Agencies go bankrupt. They get acquired, and the new owner deprioritizes accounts that don't fit the roadmap.

The account team you trusted moves on, and the replacement never reads the handover notes. Sometimes nobody quits; the vendor just stops answering email. The dependency risk looks identical in every version: the software runs somewhere you don't control, and the knowledge to keep it running lives somewhere you can't reach.

What "held hostage" looks like in practice

The pattern repeats across industries — retail, healthcare, logistics, manufacturing. The repository sits inside the vendor's GitHub organization, not the client's. The cloud account and the domain registration carry the vendor's name and the vendor's payment card.

Nobody on the client side has ever seen the database password, let alone a deploy key. There's no deployment document; the one person who knows how to ship a release keeps the steps in their head.

Think of renting a house where only the contractor holds the spare key. Fine while the relationship is healthy. It becomes dangerous the moment things go wrong — a disputed invoice, a missed deadline, a falling-out over scope — because that's exactly when cooperation stops being free.

GitHub's own transfer documentation shows how much rides on plain account ownership: issues, pull requests, wikis, deploy keys, and full git history all travel with a transfer. But a private repo moved into a Free account can lose protected branches and Pages access on the way. If the account belongs to the vendor and the vendor won't move it, the client doesn't lose support. They lose the product.

Backups fail the same way when only the vendor controls them. In January 2009, a six-year-old blogging platform called JournalSpace shut down for good after a departing IT staffer had automated backups for the web server but left the SQL database protected only by RAID. When the database was wiped, there was no independent copy to restore from, and the company folded. Backup configuration had lived entirely with one person, on one side of the relationship.

The complete handover package, itemized

A vendor relationship that ends cleanly needs more than a folder of files emailed on the last day. The package that protects a client contains:

• Repository access under the client's own account — not a collaborator invite on the vendor's org, but real ownership, ideally set up that way from day one.
• Environment and deployment documentation — what runs where, how a release ships, what breaks if a step gets skipped.
• A credential inventory in the client's own password vault — every service, key, and login, not scattered across a vendor's notes.
• Database and backup access — read access at minimum, and a backup the client can verify independently of the vendor's infrastructure.
• A license inventory — paid SaaS, API keys, font licenses, SSL certificates, anything with a renewal date and an owner who isn't the vendor.
• A runbook — routine ops and incident response, written for someone who wasn't in the room when the system was built.

A widely used engineering handoff checklist backs this up from the receiving side. It ranks access to the previous engineers as the single most important factor in a smooth transition. It also requires deployment instructions tested on a clean machine, dependencies pinned rather than left to drift, and credentials for every third-party service transferred into the new owner's name.

Source code escrow, for bigger relationships

A handover package assumes the vendor is cooperative on the way out. Source code escrow is what you set up for when they might not be. It's a three-party arrangement: the vendor deposits a verified copy of the source with an independent escrow agent, and the agent releases it to the client if a defined trigger event occurs — bankruptcy, project cancellation, or a refusal to honor maintenance obligations.

A deposit worth paying for holds more than a zip of source files. Escrow guidance from providers in the space recommends including build instructions, architecture and API documentation, a dependency list, build-environment configuration, any encryption keys or passwords needed to access the deposit, and contact details for the original engineers. Source code nobody can compile is not much of a safety net.

Escode, one established provider, reports working with over 14,000 organizations across 135+ countries. It lists insolvency, post-acquisition end-of-life, service deterioration, withdrawal of support, and critical incident failure as its typical release triggers.

Escrow is proportional to what's at stake: a brochure site doesn't need it, a platform a hospital or bank runs daily operations on does. Two commonly cited examples get mixed up here, so it's worth being precise.

Qt's continuity has a real escrow-like backstop — the KDE Free Qt Foundation guarantees a BSD-style license if no free release ships within 12 months. Blender's survival after its company went bankrupt in 2002 is a different story: no escrow agreement existed, the community ran a public buyout and negotiated the rights directly. Both are good outcomes. Only one is what escrow is built to do.

The real test of a handover

Documentation doesn't matter until it's tested. Hand a new engineer — someone with zero access to the old vendor — a clean machine and the handover docs, and see if they can deploy without asking a question.

If they can't, the package is decorative. Instructions never run on a machine without half the setup already done aren't instructions. They're notes to self.

Anti-hostage clauses, negotiated before the relationship starts

The leverage point is the statement of work, not the exit interview. Once a relationship has soured, a vendor has every incentive to slow-walk a handover, and a client has no position left to force one. Naming account ownership, handover deliverables, and exit terms up front costs a line item in a contract. Negotiating them during a breakup costs the whole project.

UK government guidance on managing technical lock-in — defined as switching from one technology or provider to another being difficult, time consuming, and disproportionately expensive — recommends building architectural knowledge in-house. It also means reviewing vendor arrangements often enough to catch rising exit costs before they harden into permanent ones. It's the same pattern as any other single point of failure in a company's systems: don't let one party become the only route back to your own product.

What I put in the contract now

The checklist isn't complicated, which is why it's easy to skip: client-owned accounts from day one, documentation tested by someone outside the build team, a credential inventory in the client's vault, and escrow for anything the business can't survive losing.

None of it is expensive to set up front. All of it is expensive to negotiate for after the fact. Same lesson freelancers learn the hard way about IP ownership: get it in writing before the work starts, not after the relationship needs it.