Every takeover starts with the same optimism: the code is written, most of the features work, so the new team should be productive in a fortnight. In practice the first three months of an inherited codebase deliver a fraction of normal output while the team reconstructs decisions nobody wrote down. That cost is real, it is estimable, and if you do not price it in, it comes out of the delivery schedule instead. Occasionally the honest answer is that the code should not be taken over at all.
01Why takeover is not normal development
New development spends most of its effort deciding what to build. Takeover spends most of its effort deciding what already exists and why - which is slower, because the source of truth is code and behaviour rather than a conversation.
Expect a deliberate productivity curve. On a moderately healthy codebase a senior team reaches roughly 50% of normal output in month one, 75% by month two and full speed around month three or four. On an unhealthy one, full speed never arrives without structural work first, which is exactly the case people fail to price.
| Codebase condition | Month 1 | Month 3 | Steady state reached |
|---|---|---|---|
| Documented, tested, conventional stack | 60% | 90% | 6 - 10 weeks |
| Undocumented but conventional | 40% | 75% | 3 - 4 months |
| No tests, heavy custom framework | 20% | 50% | 6 - 9 months, after remediation |
| No tests, no environments, no access | 10% | 35% | Unpredictable |
02What a proper takeover assessment costs
Before committing to maintain anything, buy a bounded assessment. It is cheap relative to the decision it informs, and it is the only way to distinguish a codebase that is merely untidy from one that is structurally unsafe.
A useful assessment is one to three weeks depending on size, done by engineers with repository and environment access rather than by reading documentation.
| System size | Assessment cost | Duration | Covers |
|---|---|---|---|
| Single app, under 50k lines | $6k - $12k | 3 - 5 days | Build, run, tests, dependencies, security scan |
| Product with 2 - 5 services | $15k - $30k | 1.5 - 3 weeks | Add data model, integrations, infrastructure |
| Platform, 6+ services or multi-tenant | $30k - $70k | 3 - 5 weeks | Add scaling, tenancy isolation, operational readiness |
| Legacy system over a decade old | $50k - $120k | 5 - 8 weeks | Add behaviour archaeology and characterisation tests |
03The remediation you will pay for before you can ship
Almost every takeover requires a stabilisation period before feature work is safe. The items below are not gold-plating; without them the team cannot change anything with confidence, and the first production incident will cost more than the remediation would have.
- A reproducible local environment: 3 - 15 days, and it is often the single worst item.
- A working CI pipeline and a deployable path that is not one person's laptop: 5 - 15 days.
- Characterisation tests around the most critical flows: 10 - 30 days.
- Dependency and runtime upgrades to a supported version: 5 - 40 days depending on how far behind.
- Secrets extraction from source control and rotation: 2 - 8 days, non-negotiable.
- Observability - logs, error tracking, basic alerting: 3 - 10 days.
04When to refuse the takeover
There are codebases where the responsible answer is no. Refusing costs a vendor revenue, which is why it is worth knowing the criteria yourself rather than relying on them to volunteer it.
The clearest refusal cases are not about code quality. They are about whether you can legally and practically own the thing at all.
| Finding | Verdict | Reason |
|---|---|---|
| IP ownership unclear or unassigned | Refuse until resolved | You may not own what you are paying to improve |
| Outgoing vendor controls production accounts | Refuse until transferred | No control, no accountability |
| Copyleft licence in a proprietary product | Refuse until remediated | Distribution obligation, legal exposure |
| Customer data in a system with no access control | Halt and remediate first | Live regulatory breach |
| No source history, only a zip file | Serious caution | No provenance, no attribution, no bisect |
| Heavy custom framework, original authors gone | Price as rewrite | Every change is research |
| Untested but conventional and documented | Proceed | Normal, remediable |
05Handover terms worth insisting on
Most takeover pain is created at the exit of the previous relationship, not at the start of the new one. Whether or not the outgoing party is cooperative, these are the things to secure while you still have commercial leverage - which usually means while a final invoice is unpaid.
- Full git history, not an export or a snapshot.
- Ownership transfer of cloud accounts, domains, DNS, app store accounts and CI.
- Credentials inventory and a documented rotation of everything the outgoing team knew.
- A written architecture and runbook handover, plus two to four paid hours of live question time per major subsystem.
- Signed IP assignment covering all contributors, including their subcontractors.
- A defined support overlap of two to six weeks, priced in the original contract rather than negotiated at exit.
06Take over or rebuild
The rebuild instinct is usually wrong, because a working system encodes years of edge cases you would have to rediscover. The bar for rebuilding should be high: the codebase is small, or it is structurally unsafe, or nobody can determine what it does.
A workable rule is to compare remediation cost against rebuild cost, and to weight strongly toward remediation whenever the system has real users and real business behaviour embedded in it. If remediation is under 30% of rebuild cost, remediate without further debate. Between 30% and 60%, remediate the parts you must change and leave the rest alone. Above 60% on a system under about 30,000 lines, rebuilding the component - not the whole product - is usually the cheaper path.
- Never rebuild a whole product because one module is bad - replace the module.
- Check usage before rebuilding anything; unused features are cheaper to delete than to port.
- Keep the old system running until the new path is genuinely proven in production.
- A rebuild with no characterisation of the current behaviour is a bug-compatibility project in disguise.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.