Taking over someone else's software: the rescue process
How we take over an application built by a previous team, from securing access to deciding what to keep, in six stages.
The short answer
Taking over software built by someone else is a process, not a rescue mission improvised on the day. Six stages: secure access and assets so the business controls its own system; stabilise what is running with backups, monitoring and rotated secrets; understand the system by reading, running and tracing it; decide, per component and on evidence, what to keep, fix or replace; plan the work in stages; then execute with small releases while the system keeps serving users. The first week is about control, not code. And a takeover keeps more than expected and replaces less, because the decision is made per part from an assessment rather than from taste.
The six stages
| Stage | Goal | Activities | Duration |
|---|---|---|---|
| 1. Control | The business owns and can reach everything | Accounts, domains, repository, hosting and services moved to or confirmed in the company’s name; access lists reviewed; secrets rotated | First days |
| 2. Stabilise | Nothing gets worse while we learn | Backups verified by a restore; monitoring and error tracking added; a freeze on risky changes; a way to roll back | First week |
| 3. Understand | A written picture of what exists | Read the code; run it locally; trace the main flows; map data and integrations; list dependencies and their age; run security and performance scans | Two to four weeks |
| 4. Assess and decide | Keep, fix or replace, per component | Rank risks by likelihood and impact; estimate options; decide with the business | End of understanding |
| 5. Plan | Stages with releases | Order by risk and value; quick fixes first; larger replacements staged; client dependencies named | A week |
| 6. Execute | The system improves in production | Small releases through a pipeline; each stage leaves the system better and documented | Weeks to months, by plan |
The first week, in detail
- Inventory every account and asset: domain, DNS, hosting, database, storage, repository, third-party services, app store accounts.
- Move or confirm each in the company’s name, with two administrators and two-factor.
- Rotate every secret: the previous team’s access is assumed to persist until it does not.
- Verify a backup by restoring it somewhere; if there is no backup, take one now.
- Add monitoring and error tracking, so the next problem is seen.
- Freeze risky changes until the assessment; allow only fixes that reduce risk.
Keep, fix or replace
For each component, the assessment says whether it is sound, fragile or dangerous, and the decision follows: sound components are kept and documented; fragile ones are fixed with tests added; dangerous ones, security holes, unmaintainable frameworks, data handling that cannot be trusted, are replaced in stages, behind flags where possible, while the old part keeps running. Whole rewrites are chosen only when the foundations themselves fail the assessment, and even then executed in stages that deliver value along the way.
What this means for you
A takeover done in six stages gives you control in a week, a stable system in two, a written assessment in a month and a plan you can judge. Expect the first week to be about accounts, backups and monitoring rather than code. Expect the assessment before any large decision. And expect to keep more than you feared, replacing the dangerous parts in stages while the system keeps working for your users.
Frequently asked questions
The previous developer left with no documentation. Is the software salvageable?
Usually. Code is more legible than people fear, especially with tests, types and a running system to trace. The first two weeks establish control and understanding; the assessment then says what is sound, what is fragile and what is dangerous. Total rewrites are the exception, chosen when the assessment shows the foundations cannot be trusted, not as a reflex.
How long does a takeover take?
Control in the first week, stabilisation and understanding in two to four, a written assessment and plan after that. The plan's execution depends on what was found: from a few weeks of fixes to a staged replacement over months. The early stages are fixed; the later ones are decided by evidence.
Should we rewrite it from scratch?
Only if the assessment shows that the foundations cannot be trusted: no tests, no types, security holes throughout, a framework nobody can maintain. Rewrites take longer than planned and lose behaviours nobody knew were there. The usual answer is to stabilise, then replace the worst parts in stages while the system keeps running.