Guide · Code takeover
How to take over code from a vendor
The agency has closed, the freelancer has stopped replying, or you simply want to switch IT vendors. The takeover goes well if it follows a precise order; it goes badly when you start by coding.
To take over code from a vendor, you first need to recover everything that belongs to you: the code repository with its history, access to hosting, the database and backups, the domain name, third-party accounts and configuration secrets. Next, a new vendor audits the code and operations before changing it, secures production, then resumes improvements by order of priority.
Before switching vendors: check what belongs to you
Start by re-reading the contract: it states who owns the code, and under what conditions it must be handed over to you. Then check, concretely, where the code is (on a repository in your name or the vendor's), in whose name the hosting, domain name and third-party services are registered, and who holds the passwords.
If any accounts are in the vendor's name, ask for them to be transferred before the relationship ends, in writing. If you're unsure of your rights, legal advice beats a guess. For the projects we build, the code is on your repository from the first commit and third-party accounts are in your name, precisely to avoid this situation.
The checklist of what to recover
Tick off each item. Whatever is missing becomes the first task of the takeover, before any development.
- The complete code repository, with its history, not just an archive of files
- Access to hosting (server or cloud) and to the database
- Backups, and proof that a restore has already been tested
- The domain name and certificates
- Third-party service accounts: payment, email sending, Apple and Google app stores, mapping
- Configuration secrets: API keys, technical passwords, environment variables
- Existing documentation: installation, deployment, database schema, even incomplete
- The list of known issues and pending requests
The code audit before taking over
The new vendor shouldn't start by changing the code. They need to understand it first: check they can install and deploy it, examine dependencies and known vulnerabilities, data quality, backups and the real ability to restore the service. They also meet the users, because some business rules are written nowhere except in the code.
The audit should end with a clear document: what can be kept, what needs fixing, what deserves a rewrite, and a breakdown costed by priority. This document belongs to you, even if you hand the rest of the work to someone else. Our software takeover page details the content of our audit.
The steps of a code takeover
Order matters more than speed. Each step reduces a risk before moving to the next.
- Recover access, code, backups and accounts
- Check that the software can be rebuilt and redeployed
- Audit the code, data and operations
- Secure production: tested backups, urgent fixes, monitoring
- Prioritise fixes and improvements into costed batches
- Resume improvements, with documentation and tests on every delivery
Do you need to rewrite everything?
Rarely. The temptation is strong when the code looks disorganised, but a complete rewrite forces you to rediscover every exception accumulated through real use and to switch everything over at once. A gradual overhaul, replacing one part at a time while the service keeps running, is often safer. The audit says, part by part, what's reasonable.
Be wary of a vendor who concludes a full rewrite is needed before even opening the code. Conversely, keeping a part that blocks every improvement at all costs is also costly, just more slowly.
The pitfalls of switching IT vendors
These mistakes come up often. They're avoidable once you know about them.
- Ending the contract before recovering access and the code
- Accepting a file archive without the repository's history
- Leaving the domain name or hosting in the former vendor's name
- Asking for a rewrite quote without a prior audit
- Repeating the same mistake: leaving the code and accounts in the new vendor's name again
Frequently asked questions
How do I recover the source code from my former vendor?
Start by re-reading the contract, then request in writing the handover of the complete code repository with its history, as well as the transfer of access and accounts. If there's disagreement over your rights, get legal advice.
Can another vendor take over an agency's code?
Yes, provided they have the code and the necessary access. They should start with an audit to understand the software before changing it.
What should I do if the freelancer stops replying?
Take stock of what you already control: hosting, domain name, accounts in your name. An audit can then measure what's missing and build a plan from what's actually available.
How much does taking over code from a vendor cost?
It depends on the state of the code, the access available, the data and the issues to address. The audit is costed first; the rest is costed from its findings. See Software takeover.
Do you need to rewrite everything when switching vendors?
Not necessarily. The audit says what to keep, fix or replace; a gradual overhaul is often safer than a complete rewrite.
A project, a question?
Describe what you need in a few lines: you deal directly with the team, in Lille.