Taking over code from a vendor: the checklist before changing providers
Taking over code from a vendor means handing a new team software it did not write, to maintain and evolve it. For companies changing providers: what to recover, what the incoming team must check before promising, and why a takeover is not a rewrite.
The provider who built your tool no longer answers, or answers too late, or too expensively. You look for someone else. And you discover that you do not have the code, that the server is in their name, and that nobody knows how it deploys. It is the most frequent scenario we meet, and it is almost always avoidable.
Taking over a provider's code means entrusting a new team with software it did not write, to maintain and evolve it. It goes well when three things come together: you hold what belongs to you, the incoming team looked before promising, and nobody talks about rewriting everything on day one.
A short list, to request in writing from the outgoing provider. If you are still under contract with them, do it now, while the relationship is cordial. These are your assets.
03
What must the incoming team look at before promising?
At Figue, we look at the repository and access on the first call, and say straight away whether we take it on. Here is what we look at, and what each point tells us. Ask the same of any provider.
01
The stack and its age
Which languages, which frameworks, which versions. A common, up-to-date stack is taken over in days. An exotic or abandoned stack can be taken over, but every intervention will cost more, and that has to be said beforehand.
02
Dependencies and known vulnerabilities
How many libraries, how long without updates, how many with security alerts. It is the first securing workstream, and its size is measured in an hour.
03
Tests, or their absence
If there are tests, we can change things without breaking them. If there are none, every change needs a manual check, and the first requests will be used to write tests on the flows that matter.
04
Deployment
Automated and reproducible, or manual and in someone's head? As long as we cannot deploy, we cannot deliver. It is often the real first request.
05
Readability
An engineer opens three random files and tries to understand what they do. If they can, the takeover will be smooth. If not, we say so, and we count the understanding time as time, not as a mystery.
“We never promise on a repository we have not opened. One hour of reading saves three months of bad surprises, on both sides.”
04
Takeover or rewrite: the wrong question for day one
Almost every incoming provider offers to redo everything. It is more comfortable for them (they know their own code) and seemingly more reassuring for you (a blank page). It is also, in the vast majority of cases, the wrong decision at the wrong time.
A rewrite costs the price of the software a second time, while the old one keeps running and asking for fixes. It reproduces known bugs and adds new ones. And it relies on an understanding of the business the incoming team does not have yet. The right order is the reverse: secure, understand while evolving, and decide to rebuild a part, later, with facts.
How does a takeover go at Figue? The steps, timings indicative
To make it concrete, here are the first steps of a takeover, for a client arriving with an existing product. These are ordinary requests in the queue, that you order like any other. Their duration depends on the state of the code and on how fast access comes in: timings are indicative.
01
Step 1: everything in your name
Repository, hosting, domain, third-party accounts, secrets. We gather, transfer, and document where everything is. You leave with a page listing your assets and their access.
02
Step 2: deploy and monitor
A reproducible deployment, a preview to approve, an alert when an error appears in production. From then on, we can ship without holding our breath.
03
Step 3: secure, then the first evolution
Priority security updates, tests on the flows that make money, and already the first request that matters to your users. The takeover ends when it becomes invisible.
What we get asked when a client arrives from elsewhere.
My provider refuses to hand over the code. What can I do?
Reread the contract: if the transfer of rights is in it, they are bound to hand over the code, and a formal notice is often enough. If it is not, negotiate it, possibly against the balance of an invoice. Without code, the only path is a rewrite, and it is better to know before choosing the next provider.
Do you take over any technology?
Most of them. We look at the repository on the first call and answer straight away, including when it is no. A rare stack can be taken over, but we tell you every intervention will take more time.
How long does a takeover take?
The first requests are used to put everything in your name, deploy properly and secure. These are ordinary requests, handled one at a time; their duration depends on the state of the code and on how fast the outgoing provider hands over access. We do not promise a date, we show progress.
Should I tell the former provider?
Yes, and as early as possible. A cordial takeover, with a one-hour handover, is worth weeks of investigation. Ask them for access and a deployment demonstration while you are still a client.
What if the code is really bad?
We tell you, with examples, and we estimate what it costs to keep it alive as is against what rebuilding a part would cost. The decision is yours, module by module. Bad code that runs is often worth more than good code that does not exist yet.
