The call sounds similar every time. The arrangement with the agency is ending, the software is supposed to come in-house, and then it turns out nobody at the company has ever looked into the repository. Sometimes nobody knows the address.
What follows usually gets treated as a legal question, and part of it is one. The larger part is a question of completeness: getting software back does not mean getting an archive. It means getting everything needed to operate and change it without the previous provider.
This article describes what belongs on the list, in which order to ask for it, and what to do when it stalls. It is not legal advice: whether and to what extent a claim exists is a matter of the contract and the rights granted in it, and that belongs in front of a lawyer.
What belongs on the list
The usual request is "we would like the source code", and it is too small. The code alone is the part you can do least with.
The history, not just the state. An archive of today's state takes away every answer to the question of why a piece looks the way it does. What you ask for is the repository with its history, in a form you can clone.
Everything that is not code. The description of the environment, the configuration values, the schema migrations, the scheduled jobs, and the certificates. A project without those can be read and cannot be operated.
The access. Server and database, the cloud account, the domain registration, the certificate, the accounts at the payment provider, the mail sender and the error reporting service, the credentials for the package registry publishing internal packages, and the app store accounts if there is a mobile app.
The data. A current database dump and the files the application has stored. This is the point where data protection gets settled before anything is copied.
And what only exists in heads. How deployment works, what goes wrong at night, which pieces are agreements with individual customers. There is no handover folder for that, only meetings.
The order is not arbitrary
Ask for everything at once and you get an answer full of questions and lose two weeks. The order that works sorts by what becomes impossible later without the other side.
First the accounts that run on people. Domain, certificate, cloud account, payment provider. These cost a support case with proof of identity later, once the contact person is unreachable. While the arrangement is still running, they are minutes.
Then the repository with history, pushed into an account of your own rather than sent as an archive by email. A clone in your account is a state; an archive is a photograph.
Then the environment, and the test for it is hard: somebody from your side starts the application on an empty machine. Whatever is missing is the list of things not handed over yet.
The data last, because it goes stale fastest and needs the most care.
What to do with the code once you have it is covered in Technical due diligence.
The day the code arrives
The code in your own account is not the end, it is the beginning. Three things belong in the first week, and none of them involves the provider any more.
A build of your own. Does the project build on your side without access to anything the other party owns? A private package registry, a key in a pipeline, an image from somebody else's registry: every one of those threads snaps the day the account is closed.
A deployment of your own. Not adopting the existing one but setting one up from scratch once. Only then is it proven that you can reach production without outside help.
An inventory. What is in there, what is out of date, what is homegrown. The handover is the only moment when somebody is still around to ask.
Escrow only helps when somebody checks it
Contracts that anticipate this case often include a source code escrow: a third party holds the current state and releases it when certain things happen. The legal side of that is a contract question. The technical side is a question hardly anybody asks.
What was deposited is almost never complete. The code gets deposited. What does not get deposited is the configuration values, the access to third-party services, the private package registry the build depends on, and the procedure that turns all of it into a running application. When it matters you have an archive and not software.
The remedy is unspectacular and still almost never done: once a year the deposited state gets released and built by somebody who did not write it. Whatever is missing goes into the escrow. Without that rehearsal the clause is a reassurance, and it fails on exactly the day it is needed.
The same holds for the milder case where the arrangement is going well: an annual build on an empty machine answers the question of whether you could if you had to.
When it stalls
Sometimes nothing arrives, or only part of it. There is a technical answer for that, and it comes before the legal one because it is faster.
First, record what is missing, as a list with dates rather than as a mood. An overview stating for every item when it was requested and what came back is the basis for every further conversation, and incidentally it is the first thing a lawyer wants to see.
In parallel, secure what is reachable. A copy of the running application from the server, the configuration from the environment, a database dump: that is not a reconstruction of the source code, but it keeps operations alive while the handover is being settled.
And then comes the uncomfortable calculation: what would it cost to rebuild the part being argued over? In a surprising number of cases that is smaller than the dispute, particularly when it concerns a piece that was due for replacement anyway. Knowing that number changes the conversation, even when you do not need it.
What the same situation looks like from the other side is covered in The handover day.
So that it does not happen again
The situation does not arise from bad faith but from a shortcut at the beginning: it was quicker if the agency created the account. Five years later that has become a dependency nobody decided on.
One rule prevents it, and it costs ten minutes on day one: accounts belong to the company, providers get access. The domain, the cloud account, the repository and the accounts at third parties run on the company, and the provider gets invited. At the next handover that is a revocation of access rather than a release of property.
The second rule is a rehearsal: once a year somebody from the company builds the project on an empty machine. That is the same test as above, only before it is needed, and it is the only one that answers honestly.
How a takeover runs afterwards, from the first week to the point where the team carries on alone, is described on its own page.
This article continues a series about systems that already exist. The retrospective on the first three months orders its articles by situation.
