Changing software supplier: what to ask for, and in what order

Before the code, ownership. What follows tends to sit in the outgoing supplier's name without anyone having decided it: on day one that was the quick way to do it, and eleven months later nobody remembers.

The repositories

Not access — the organisation. Being granted read permissions is worth nothing the day the account closes. The GitHub, GitLab or Bitbucket organisation has to be yours, on your billing.

The domains

Who is listed as registrant in the whois, who can log into the registrar, and when each one expires. A domain that lapses mid-handover takes the service and the email down together.

Certificates and DNS

Where the DNS zones live and who can edit them. If the certificate renews itself from a server the outgoing supplier owns, it stops renewing the day they switch it off.

Cloud accounts and the container registry

The root AWS, GCP or Azure account, with its payment method. And where the container images live: a private registry that closes leaves your deploys with nothing to deploy.

Third-party subscriptions

Payment gateway, email delivery, SMS, monitoring, error tracking, maps. Each has an account holder and a card. The ones in the outgoing supplier's name end when they cancel.

The secrets

Where the API keys, database credentials and app signing certificates are. And the plan to rotate all of them: whoever is leaving has seen them.

The system of record

Which database is authoritative, where the backups are, how often they run and — and this last one is the check that decides — the last time anyone restored one to see whether it worked.

The app store signing keys

The Apple and Google developer accounts, and the certificate that releases are signed with. Losing the Android signing key means never updating that app again: you publish a different one.

The question people leave latest is who owns the code you have paid for. In Spain the answer starts in your contract, and only reaches the law if the contract is silent.

Software is protected by copyright. Under Spanish law — Royal Legislative Decree 1/1996, the consolidated Intellectual Property Act — article 97.4 settles one case only: where software is written by an employee in the course of their duties, the exploitation rights belong to the employer unless agreed otherwise.

An external supplier is not your employee, so that article does nothing for you. For commissioned work the rights are assigned, and article 43 limits an assignment to the forms of exploitation expressly stated, while article 45 requires it to be in writing. The practical consequence is worth knowing before the meeting rather than during it: if your contract does not say the code is yours, it may not be.

And code without what surrounds it is half of it. Ask for the full version history too — not a zip of the last day — the dependency file with its versions pinned, the deployment scripts, and the database migrations in order.

A handover with no overlap is a file transfer. What it takes is for the incoming team to deploy the system to production once while the outgoing one is still reachable, because that is where everything nobody wrote down turns up.

1. Weeks 1 and 2 — inventory and ownership

   Work through the list above and transfer whatever expires. In parallel the incoming team stands the system up on its own machine: whatever they are missing to get there is exactly the documentation that did not exist.

2. Weeks 3 and 4 — the first deploy

   A small, low-risk change taken to production by the incoming team from end to end. The change does not matter; walking the path with someone alongside who knows it does.

3. Weeks 5 and 6 — on call

   The incoming team handles incidents and the outgoing one is there to be asked, not to act. This is where the scheduled jobs nobody mentioned surface, because they only run at month end.

Four to six weeks is reasonable for a system in production with thin documentation. You can do it in less, and then you pay for the overlap afterwards, in incidents.