Taking over someone else's software starts with an assessment, not with code. Before agreeing a price or a timeline, a new team needs to know whether it builds, whether it is tested, where it runs, who holds the accounts, and what the previous team knew that was never written down. Handovers fail on the last of those far more often than on code quality.
This guide covers what to demand before signing, how to run the transition, and what to do when the outgoing team is unavailable or unwilling.
Key takeaways
- Get access before you commit: A quote given without seeing the code is a guess.
- Accounts matter as much as code: Hosting, domains, stores and third-party services.
- Budget a stabilisation period: Four to eight weeks before promising new features.
- Undocumented business rules are the real risk: They live in people, not in the repository.
Assess before you price
A credible assessment takes one to two weeks and needs read access to everything. It should answer:
| Question | Why it matters |
|---|---|
| Does it build from a clean checkout? | If not, deployment knowledge lives in someone's head |
| Is there a test suite, and does it pass? | Determines how safely anything can change |
| How is it deployed, and by whom? | Manual deployment from a laptop is common and fragile |
| What are the dependencies and their versions? | Two major versions behind turns updates into projects |
| Where is it hosted, and in whose account? | Decides whether you control your own product |
| What monitoring exists? | Whether problems are noticed or reported by users |
| What is documented, and how stale is it? | Sets the discovery effort |
Any supplier quoting a takeover without this has priced a guess. Pay for the assessment separately and own the output. It is useful whoever you eventually engage.
Secure the accounts first
Code is recoverable; accounts frequently are not. Before anything else, establish who holds and controls:
- Source code repository, with admin rights
- Hosting and cloud accounts, billed to you
- Domain registrar and DNS
- Apple and Google developer accounts
- Third-party services: payments, email, SMS, maps, analytics, monitoring
- SSL certificates and any signing keys
Apps published under an outgoing agency's developer account are painful to move, and the moment you discover this is usually the moment the relationship is already difficult. Where accounts are in someone else's name, transferring them is the first task, not a later one.
Extract what only people know
The largest risk in a handover is not the code. It is the years of business rules, edge cases and operational habits that were never written down and leave with the previous team.
Where a handover period is available, use it for knowledge rather than code walkthroughs. Ask what breaks regularly, what nobody should touch and why, what the manual steps are, who calls when it goes down, and what the last three incidents were.
Record these sessions. An hour of conversation contains more than a month of reading the repository, and nobody remembers it accurately a fortnight later.
Plan for a hostile or absent handover
Frequently there is no cooperative outgoing team, the relationship ended badly, or the developer has moved on.
In that case, budget more discovery and expect the first weeks to be archaeology. Practical approach: get it running locally first, then in a staging environment, then make a trivial change and deploy it end to end. That single exercise, a one-word change shipped to production, surfaces most of what you do not know about the system.
Read the code paths that run most often rather than trying to understand everything. Production logs tell you what actually gets used, which is usually a fraction of what exists.
Stabilise before you extend
Resist the pressure to ship features immediately. The first four to eight weeks should go to: getting the build and deployment reliable, adding monitoring if it is missing, patching known security issues, and writing tests around the parts you are about to change.
This is not a delay; it is what makes everything afterwards predictable. A team that starts adding features to an unfamiliar system without tests will spend the following quarter fixing regressions, and the client will conclude the new team is worse than the old one.
Agree this period explicitly in the contract, with what it delivers. A stabilisation phase nobody agreed to looks like slow progress.
Fix documentation as you go, not as a project
A documentation project produces a document that is stale in a month. Instead, write down what you learn as you learn it, starting with a runbook: how to deploy, how to roll back, what to do when it goes down, and who to call.
Keep it in the repository so it is versioned with the code. Documentation in a shared drive is documentation nobody updates.
Set expectations about the first quarter
Be direct with whoever is paying: velocity will be lower initially, some estimates will be wrong, and some parts of the system will surprise everyone. That is what taking over unfamiliar code means.
The alternative, quoting confidently and then explaining variances, damages the relationship exactly when it is newest. Naming the uncertainty up front and then narrowing it as the assessment completes builds the credibility the engagement will need.
Decide what happens to the old team
Where possible, retain the outgoing developer for a defined consultancy period: a few hours a month for three months, paid, with a clear scope. It is far cheaper than the alternative and it covers the questions that only appear once you are operating the system.
Where that is not possible, say so in the plan and price the discovery accordingly. Pretending the knowledge gap does not exist is how takeover projects overrun.
Related guides
- Alongside How to Hand Over an Existing Software Project to a New Team, continue with AI Workflow Automation: Use Cases, Risks, and Roadmap.
- Alongside How to Hand Over an Existing Software Project to a New Team, continue with Admin Dashboard Development: Features, Architecture, and Cost Drivers.
If the work prompted by How to Hand Over an Existing Software Project to a New Team leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Modernization Plan.
Ali Boran Gazel