Change vendors without stopping the roadmap.
The repositories transfer in an afternoon. The context does not. We take over systems built by someone else — and make sure leaving us is cheaper than leaving them was.
Talk to a tech lead ↗A takeover is engineering work, not a contract end date.
Overlap, and ship during it
We start while the outgoing team is still engaged, and we ship small changes through their review. You learn more from a rejected pull request than from any handover document.
Inventory before notice
A complete list of accounts, providers and credentials, with owners named — collected while there is still commercial leverage, not after.
Reconstruct the decisions
Architecture as built rather than as designed, recorded walkthroughs per subsystem, and an honest debt list. We write down what the last team knew.
Production inside the first month
A takeover has worked when the new team has merged production code, can deploy without the outgoing vendor in the room, and can explain a decision it did not make.
Your repos, your cloud
From day one, in your accounts. You are switching because leaving was hard last time; signing a replacement without fixing that means doing this again in three years.
Interview the tech lead
The person in that conversation is the person in your repositories. Nobody is swapped for a cheaper profile once the work starts.
Handover as definition of done
Documentation, ADRs and handover drills are part of shipping, not a closing favour. Leaving must always be cheap.
Taking over someone else’s codebase.
What questions should I ask a new vendor when replacing an existing engineering team?
Four that are awkward to answer if the practice is not real. Who exactly will be on the team, and can I meet them before signing? Whose accounts hold the repositories and the cloud? What is in the handover, as a list, before anything is signed? And what does the overlap with our current vendor look like in weeks and in deliverables? A vendor that answers all four in one conversation is telling you how the work is actually run.
We did not choose the engineers on our current team and cannot manage them directly. How do we move to a team we can?
Insist on the shape before the schedule. Named engineers you interview in advance, direct access to them rather than through an account manager, and your own repositories and cloud accounts so nothing has to be handed back later. The transition itself is then ordinary engineering work: an overlap period, an access inventory, and tests written around current behaviour before anything changes.
Can we change vendors without stopping the roadmap?
Yes, if the overlap is planned rather than skipped. Both teams are engaged at once and the incoming team ships small changes through the outgoing team’s review from the first week. Delivery slows during the overlap; it does not stop. What stops delivery is ending one contract on Friday and starting another on Monday.
What are the biggest risks when switching development vendors?
Losing context rather than code. Decision history, operational knowledge and access leave with the outgoing team, delivery stalls while the new one rediscovers them, and anything nobody wrote down gets rediscovered in production. The mitigations are an overlap period, an access inventory collected before notice is given, and tests around current behaviour before anything changes.
Will you work on a codebase you did not write?
Yes — most takeovers start that way. We begin with characterisation tests and a read of what production actually does, rather than a rewrite proposal.
What if the previous vendor will not co-operate?
It happens. Then the transition runs on artefacts instead of goodwill: production behaviour, the access inventory you can assemble yourself, and tests written around current behaviour before anything changes.
Do you recommend rewriting?
Rarely, and not first. A rewrite trades a system you understand badly for one that does not exist yet. Strangling the parts that hurt is usually cheaper and always reversible.
How long before you are productive?
Production code inside the first month is the bar we hold ourselves to. If the system makes that unrealistic, we say so before you sign rather than after.