Software Handover That Reduces Vendor Dependence

Software handover should let a new team operate the system without relying on the old vendor. Obtain accounts you control, code under the rights agreed in your contract, backups, license records and operating instructions. Have someone outside the build team test those instructions. A code folder alone does not prove the business can keep running.

A dependency can outlast an individual employee: the agency itself may become unavailable. 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 supporting hospital or bank operations warrants a formal continuity assessment, which may include escrow. Two commonly cited examples get mixed up here, so it's worth being precise.

Qt has a contractual continuity safeguard. The KDE Free Qt Foundation has the right to release Qt under a BSD-style or other open-source license if Qt Group discontinues development of the Free Edition under the required licenses. This is a conditional right, not an automatic license change. The current page's twelve-month provision concerns applying required license terms after a release.

Blender's official history describes a different route: after the company closed in 2002, community fundraising enabled a negotiated rights buyout and open-source release. That was not a release from an existing escrow deposit. Both illustrate continuity, through different arrangements.

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's practical options may be limited, even where the contract provides handover rights. 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.