What actually changes hands
A vendor transition is usually described as a code handover, and that description is what makes it go wrong. Code is the one asset that copies perfectly. What does not copy is the running system: the cloud organization somebody's corporate card pays for, the certificate renewing through an account nobody has opened in two years, the deploy step that works only because an engineer's laptop holds a key, and the decisions that explain why the retry logic looks insane and is actually correct. The repository arrives intact on day one. Everything that turns a repository into a service arrives late, partially, or not at all.
The knowledge concentration is worse than most buyers assume. Avelino, Passos, Hora and Valente measured the truck factor of 133 popular GitHub projects in 2016 and found 65 percent had a truck factor of two or fewer: the departure of one or two people would leave the project without anyone who understood it. Those are open projects with public contributors and outside review. A system built by one vendor for one customer starts from a narrower base, and the people holding that knowledge are the ones whose contract just ended.
So the transition runs on a clock unrelated to the contract end date: the clock on cooperation. For a few weeks the departing engineers answer quickly, because they still feel ownership and their manager still cares. Then they are staffed elsewhere, and every unasked question becomes one you answer by reading code, which is far slower than asking the person who wrote it.
Where a vendor transition loses its schedule
Editorial ranking of the failure modes we see discussed in transition literature and practitioner accounts — illustrative ordering, not a measured statistic.
Read those bars as an ordering, not measurements. The top of the list is administrative and the bottom is technical: buyers prepare for the technical work and get stopped by an expired domain registration.
Settle what you own before you open the editor
The first question is not how the code works. It is what the contract lets you do with it, and the answer is frequently worse than the buyer expects.
On a commercial engagement, paying for software does not by itself make you its owner. Under 17 U.S.C. 101 a work made for hire is either a work prepared by an employee within the scope of employment, or a specially ordered work falling into one of nine enumerated categories with a signed written agreement: contributions to collective works, motion pictures and audiovisual works, translations, supplementary works, compilations, instructional texts, tests, answer material for tests, and atlases. Computer software is not on that list. A contractor's code is therefore not a work made for hire whatever the statement of work calls it, and absent a signed assignment the vendor may own what you paid to build. The fix is an assignment, or a license broad enough to cover modification by a successor.
On a federal contract the shape is different. The Government does not take title; it takes a license, and which license depends on who paid for development. FAR 52.227-14 (May 2014) gives unlimited rights in data first produced in performance, along with form-fit-and-function data and operation and maintenance manuals, with narrower categories for privately developed software and limited-rights data. For noncommercial computer software on defense work, DFARS 252.227-7014 (Aug 2025) sorts everything into three buckets: unlimited rights where the Government funded development exclusively, government purpose rights for mixed funding, and restricted rights where development was entirely at private expense. Government purpose rights run five years from contract execution unless negotiated otherwise, then convert to unlimited automatically.
| Question | Commercial engagement | Federal contract |
|---|---|---|
| Who holds the copyright | The vendor, absent a signed assignment; commissioned software is not a work made for hire under 17 U.S.C. 101 | The contractor. The Government takes a license, and FAR 52.227-14 gives unlimited rights in data first produced in performance |
| Can a different vendor modify it | Only if the assignment or license reaches modification and successor use, in writing | By DFARS 252.227-7014 category: yes under unlimited, yes for government purposes under GPR, largely no under restricted rights |
| How long a restriction lasts | Whatever the agreement says, including forever | Government purpose rights run five years from contract execution, then become unlimited |
| Where the answer is written down | The IP section of the master agreement, plus every task order that amended it | The assertions table submitted under DFARS 252.227-7017 (Jan 2025), incorporated into the contract |
| If nobody ordered delivery | You may have bought a service and no artifact at all | DFARS 252.227-7027 permits ordering within three years after acceptance of all items, the contractor paid for conversion, reproduction and delivery |
| Third-party components inside it | Commercial licenses are often non-transferable and tied to the vendor's entity | Same exposure, and the license inventory has to be delivered rather than assumed |
Two federal clauses rescue programs. DFARS 252.227-7017 requires an offeror to identify and assert, before award, every piece of technical data and software it intends to deliver with restrictions, and failure to submit that identification may render an offer ineligible for award. Whatever the incumbent listed became part of the contract, so read it first: it is the map of what the Government can hand a successor. DFARS 252.227-7027 (Apr 1988), prescribed at DFARS 227.7103-8(b), lets the Government order technical data or software during performance or within three years after acceptance of all items, paying the contractor to convert, reproduce and deliver it. If the code was never ordered, that clause is still a door.
One caution on citations in 2026: the Revolutionary FAR Overhaul is reissuing parts of the regulation, with OMB announcing formal publication of regulatory changes in June 2026, and section numbering is moving in places. Confirm the deviation text your contracting activity is operating under. The structure described here has not changed.
The inventory, and everything in it that is not code
Write the inventory with an owner and a status against every line, and treat any line marked "the vendor has it" as an open risk. This is the list our engineers work through in week one.
- Repositories with full history, not a zip of the current tree. Commit history is the only surviving record of why the code is shaped the way it is.
- Build and pipeline definitions, including configuration living in the CI tool's console rather than the repository, where undocumented steps hide.
- Artifact registries, plus any private package the build pulls from a vendor-owned index.
- The cloud organization and payer account. If the accounts sit inside the vendor's organization, ownership transfer is a project of its own with a lead time.
- Every secret: API keys, service accounts, signing keys, database credentials, and where each one lives. Enumerate before rotating.
- Domains, DNS zones and the registrar login, with renewal dates and the billing contact.
- TLS and code-signing certificates with expiry dates and the identity that can reissue them.
- Third-party SaaS and API accounts with the billing relationship named, including free tiers running under a personal email.
- Data stores and backups, with retention settings and the date of the last successful restore test.
- Monitoring, logging and alert routing, including who currently receives the pages.
- Runbooks and the incident history, which is the fastest description of where the system is fragile.
- The ticket and issue archive, exported. It holds the requirements nobody wrote into a document.
- A dependency and license inventory generated from the build, not from a spreadsheet.
- The access list: every human and machine identity with a path into production, and the system that grants it.
Federal transitions add two mechanisms a commercial buyer does not have. FAR 52.237-3 Continuity of Services (Jan 1991), prescribed at FAR 37.110(c), obligates the incumbent to furnish phase-in and phase-out services for up to 90 days after expiration on the Contracting Officer's written notice, to negotiate a transition plan with the successor in good faith, to provide sufficient experienced personnel, and to make employee records available and permit the successor to interview staff. It is the most useful clause in a services contract during a takeover, and it is routinely left unexercised until the window has mostly closed. FAR 52.245-1 (Sep 2021) governs Government property: final physical inventory, disposal schedules to the Plant Clearance Officer, auditable records, closeout reporting. Hardware, test equipment and furnished data move under that clause, not under a handshake.
The continuity window is short and it starts on written notice
The 90 days of phase-in and phase-out support under FAR 52.237-3 begin when the Contracting Officer gives written notice, not when the successor is ready to use them. Get the notice issued early, schedule the sessions inside the window, and spend the incumbent's time on what only they know.
Three tests that tell you whether you own it
A handover meeting proves nothing. Three mechanical tests, run in the first two weeks, tell you what you control, and each produces a number worth reporting upward.
Build it on a machine that has never seen it. Take a clean workstation or a fresh container image, follow only the written instructions, and produce a deployable artifact. Time it. If the build depends on an undocumented tool version, a package on a vendor-owned index, or a file living on one departing engineer's disk, this test finds it in an afternoon rather than during an outage. The elapsed time is a real metric: it is roughly how long a new engineer takes to become useful, and the floor on your recovery time if the build environment is lost.
Restore the data into an empty environment. Backups that have never been restored are a hypothesis. Restore the most recent one into an isolated environment, point the application at it, and run whatever test suite exists. Record the duration and what was missing. Object storage, message queues, search indexes and secret stores are the four things that reliably fall out of a backup plan written around a relational database.
Ship a trivial change and roll it back. Change one visible string, move it through the real pipeline into production, verify it, then reverse it. That single motion exercises source control access, the build, the artifact store, deployment credentials, the approval path, monitoring and rollback at once, and it fails informatively at whichever link is broken. Until this test passes, the buyer does not control the system regardless of who holds the source.
Rotate everything, and prove the old keys are dead
Every credential the departing vendor's staff could see needs replacement, and that is not an accusation against anyone. It is the reasoning that closes a badge on the last day of employment. A key sitting in a former vendor's password manager, on a personal laptop, or in an old CI log is an exposure the buyer can no longer manage.
Do it in a stated order, because careless rotation is an outage. Enumerate first, using the inventory above plus a scan of repository history for secrets committed and later removed, a common finding the removal commit does not fix. Then rotate in dependency order: leaf credentials with a single consumer first, shared service accounts next, signing keys and root credentials last with a rehearsed rollback. Handle the identity provider and break-glass accounts separately, with two people present. Finish by proving revocation rather than assuming it: authenticate with the retired credential and log the failure. An old key that still works is a finding you want to make yourself.
Reading a system you did not write
The instinct is to open the largest source file and start at line one. That is the slowest path. Work from the outside in.
Start at the entry points. Enumerate every way work enters the system: HTTP routes, scheduled jobs, queue consumers, file drops, webhook receivers, database triggers. That list is the true feature inventory, shorter than the documentation and longer than anyone remembers.
Read the deployment configuration before the source. Infrastructure definitions, environment variables and the job schedule describe the system's real shape and operating assumptions more honestly than any design document, because they have to be correct or nothing runs.
Use the history as documentation. Version control history, blame output and linked tickets recover intent. A strange conditional whose commit message references an incident is not a bug; it is a scar, and removing it re-opens the wound.
Pin behavior before changing it. Michael Feathers named the technique in Working Effectively with Legacy Code (2004): a characterization test does not assert what the code should do, it records what the code does. Feed real inputs, capture the outputs exactly, and pin them. When a captured behavior looks wrong, pin it anyway and raise it as a question for the business owner. Silent correction is how a new maintainer gets blamed for something that was already broken.
Instrument to find the dead parts. Add coverage or logging at the entry points and let production traffic run. Paths nothing reaches are deletion candidates, and deleting them is the cheapest way to shrink the surface you now own. Confirm against a full seasonal cycle first: quarterly reporting and fiscal-year-close paths look dead for eleven months.
The dependency tree you inherited
Generate a software bill of materials from the build itself rather than accepting a list. The two formats in general use are SPDX, standardized as ISO/IEC 5962:2021, and CycloneDX, standardized as ECMA-424, second edition December 2025. Either one, produced by the pipeline on every run, turns a vague question into a file you can query.
Three findings come out of that file with money attached. Components past end of support, a security clock you inherited and did not set. Copyleft licenses whose obligations depend on how the product is distributed, which matters once a system moves from internal use to a hosted offering or a delivered appliance. And commercial libraries licensed to the departing vendor's entity rather than yours, a purchase you did not budget and cannot defer past the next renewal. For the practice baseline underneath all of it, NIST SP 800-218, the Secure Software Development Framework version 1.1 (February 2022), is the reference most federal and enterprise customers recognize.
The first ninety days
The ordering below front-loads whatever depends on the incumbent's cooperation and defers what you can do alone. That is the scheduling principle: spend the perishable resource first.
Takeover sequence for a mid-size production system
Structure the knowledge sessions rather than booking a generic walkthrough. Five questions get more out of an hour than any architecture tour. What breaks at three in the morning, and what do you do about it. What would you not build that way again, and what depends on it. Which part were you most worried about handing over. What is true here that is written down nowhere. Who outside your team should we talk to. Record the sessions, transcribe them, and file the transcripts in the repository: a transcript is a document even when nobody had time to write one.
What to fix first, and the rewrite to refuse
Ward Cunningham introduced the debt metaphor in a 1992 OOPSLA experience report on the WyCash portfolio system: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." A system arriving from a departing vendor carries years of unpaid interest, and the new maintainer's first temptation is to declare bankruptcy and start over.
Refuse it at the start, and the reason is precise rather than sentimental: a rewrite is a promise to reproduce behavior you cannot yet describe. You do not know what the system does, you have not run a full seasonal cycle, and the characterization corpus that would make a rewrite verifiable does not exist. Anyone proposing a rewrite in month one is proposing to convert a known system with known defects into an unknown system with unknown defects, on the transition budget.
Fix in this order instead. First, anything blocking deployment, because a system you cannot deploy is a system you cannot fix. Second, observability, since inherited systems are instrumented for the questions the last team had rather than yours. Third, security exposures carrying a clock: unsupported components, expiring certificates, credentials that resisted rotation. Fourth, correctness and design, once characterization tests make a change provable. By the time you reach that fourth category the list will be shorter and different from the one you would have written in week one.
Write the next contract so this is cheap
The transition you are running now is evidence about the terms signed three years ago. The terms below turn a handover from an archaeology project into a scheduled event, and they cost the incoming vendor very little when they are in the agreement from the start.
| Term | Language that does not survive contact | Language that works |
|---|---|---|
| Documentation | "Contractor shall maintain adequate system documentation" | Named artifacts with an acceptance test: instructions that produce a running system on a clean machine within a stated number of hours |
| Source delivery | "Deliverables include source code at contract completion" | Continuous commit to a buyer-owned repository, the build source of record from day one |
| Credentials | "Contractor shall provide access as required" | Secrets in a buyer-owned vault; vendor identities federated, individually named, revocable by the buyer alone |
| Infrastructure | "Contractor shall host and operate the application" | The buyer owns the cloud organization and payer account; the vendor holds a scoped role inside it |
| Transition out | "Contractor shall support transition activities" | A priced, scheduled transition-out line item with named artifacts, rehearsed before the final option period |
| Verification | "Contractor shall certify handover completeness" | An annual clean-machine build and restore rehearsal witnessed by the buyer, result recorded |
Federal buyers have levers here that commercial buyers must negotiate. Settle data and software rights at solicitation, since DFARS 252.227-7017 puts the assertions on the table before award and what is asserted there governs later. Keep DFARS 252.227-7027 available so software can still be ordered within three years after acceptance. Include FAR 52.237-3 on services work and exercise it deliberately. And the SHARE IT Act, Public Law 118-187, enacted December 23, 2024, directs governmentwide practices for sharing and reusing custom-developed source code across agencies, which makes a buildable, license-clean repository an obligation rather than a preference.
Escrow deserves a plain assessment: it is a fallback, not a plan. A deposit never verified, never built and never restored produces a package you cannot use on the day you need it. If escrow is in the agreement, require periodic verification against the same clean-machine standard, or treat its value as legal comfort rather than operational recovery.
How we take a system over
Precision Federal builds and operates AI, data and software systems for federal, state and commercial customers, and inherited systems are a normal part of that work. Our first two weeks are fixed regardless of stack: secure the accounts and the history, run the clean-machine build, run the restore, ship and reverse one trivial change, and publish a written finding on each with the elapsed times attached. The buyer has a risk register by the first Friday with the ugly items on page one.
From there we run the knowledge window against the outgoing team, build the characterization corpus on the paths where a mistake shows up in a financial statement or a compliance report, and hand back a sequenced maintenance plan. We work as a prime or as a subcontractor to the integrator holding the contract, and on transitions the subcontract position is often faster, because the vehicle already exists and what the program needs is engineering depth inside the window.
Bottom line
Treat the transition as an operations problem with a legal component and a reading component, in that order. Settle the rights, take the accounts, prove the build, prove the restore, prove a deployment, rotate the keys, and spend the incumbent's remaining goodwill on the questions only they can answer. Do that inside the window and you inherit a system. Skip it and you inherit a repository, a vendor who has stopped replying, and a rewrite proposal arriving right on schedule in month four.
Frequently asked questions
Not automatically. Under 17 U.S.C. 101 a specially ordered work is a work made for hire only if it falls into one of nine enumerated categories with a signed written agreement, and computer software is not among them. Without an assignment or a license that reaches modification by a successor, the vendor may hold the copyright in software you funded. On federal contracts the Government takes a license rather than title, with the category set by who funded development.
FAR 52.237-3 Continuity of Services obligates the contractor to furnish phase-in and phase-out services for up to 90 days after expiration when the Contracting Officer gives written notice. Within that period the contractor must negotiate a transition plan with the successor in good faith, provide sufficient experienced personnel, make employee records available and permit the successor to interview staff.
Build it on a machine that has never seen it, following only the written instructions, and time the attempt. That test surfaces undocumented tool versions, private package sources, and files living on one engineer's disk. Follow it with a restore of the latest backup into an empty environment, then a trivial change shipped through the real pipeline and rolled back.
Not in the first months. A rewrite commits you to reproducing behavior that has not been described, and on an inherited system that description does not exist. Pin the behavior with characterization tests, run a full seasonal cycle, then decide. Fix deployment blockers, observability and security clocks first; design work is cheaper once changes are provable.
Only if the deposit is verified. An escrow package that has never been built or restored is a legal instrument rather than an operational one. Require periodic verification against the same clean-machine standard used at handover, and pair escrow with the terms that matter more day to day: a buyer-owned repository and cloud account, secrets in a buyer-controlled vault, and a priced transition-out line item.