Almost every software contract carefully describes what will be built. Very few describe what you will receive.
They are different things. What gets built is the system. What you receive is the system plus the ability to operate it without depending on whoever built it. The second part does not come by default, and the moment to find that out is not when you decide to change vendors.
Use this as a check before signing and as the agenda for the final weeks of any project. A responsible transfer does not fit into one closing meeting. Each item needs an owner, a date and a practical way to confirm that it works.
1. The repository, with its full history
In your company's account, not the vendor's, and not as a zip file emailed over on the final day.
The history matters more than it appears to. It is one of the best records of why things are the way they are: the commit message explaining why that odd calculation rule exists, the discussion that preceded a structural change. Whoever inherits code without history inherits a system with very little memory and may spend months rediscovering decisions that were already made. Or, worse, reversing them without knowing.
Common failure: the code is handed over, but the origin repository is still the vendor's, and what you hold is a copy that is out of date the moment it arrives.
2. Infrastructure in your company's name and on your invoice
Servers, database, storage, email service. All of it lives in provider accounts, and those accounts have an owner.
Common failure: everything sits under the vendor's account, mixed in with other clients, and the transfer is left "for later". Later becomes a migration project with real downtime risk, done in a hurry at the worst possible moment, which is once the relationship has already soured.
Ask for this at the start. Accounts in your company's name, your company's card, and administrative access held by you, with the vendor invited in. It is the inverse of the usual arrangement, and it is the correct one.
3. The data, with the export already tested
Not the promise of an export. The export, performed at least once, with you looking at the file that came out.
There is a wide gap between "the system allows exporting" and "there is a path that produces a complete, intact dataset that another tool can actually import". The gap only shows up when someone tries.
4. Domain and DNS registered by you
The most mundane item on the list, and the most frequent hostage. A domain registered under the personal account of someone who worked on the project is a dependency on a person, not a company. When that person moves on, changes jobs, or simply forgets the password, the cost is your brand going dark.
5. Third-party accounts, one by one
Payment gateway, transactional email, maps, identity provider, monitoring. Every integration has an account and a key somewhere.
Common failure: the keys are configured and working, and nobody knows which account they were created under. It works perfectly until the day one needs renewing.
6. Observability, so you find out before your customer does
You need to learn that something broke from an alert, not from an annoyed customer. That means error logging, basic availability metrics, and someone on your side receiving the notifications.
Without it, operating the system still depends on whoever built it, even with all the code in your hands. It is the quietest form of dependency: you own everything and still have to call them.
7. Documentation of what was decided, not what is obvious
Useful documentation does not describe what the code does; the code is there for that. It records what is not there: why this approach and not the other, which alternatives were rejected and why, what the known limits are, what breaks if you touch a given area.
Add two operational things to that: how to run the system on a new machine, and how to ship a change.
8. Someone on your side who has already done it, supervised
The last item is not an artefact, it is a person. Before the project ends, someone on your team, or a partner of yours, needs to have shipped a change to production at least once, with the vendor watching over their shoulder and available to help.
Training in the form of a presentation does not count. Either the person has done it, or they don't know how.
The question that sums up the list
If you want a single test, it is this one:
If the vendor vanished tomorrow, what would stop?
Ask it before signing, not after. The honest answer separates whoever built a system for you from whoever built a dependency on themselves. The two look very much alike while everything is going well.
Where we come in
In our case the list above is not a closing procedure, it is a phase. The last of four, and the one that gives the rest its name: Ownership.
It starts being prepared at the beginning, not in the final meeting. Ownership, accounts, access, documentation and transition must be defined in the contract and scope. Not because we expect the client to walk away, but because a product that can continue with another team tends to be better documented and less tied to its supplier.
The uncomfortable part of working this way is that it removes the commercial lock-in that many vendors treat as an asset. That is deliberate. We would rather the renewal happened because the work is good.