Taking over someone else's code: a checklist before the first deploy

The developers are gone, the documentation is thin, and somewhere the system keeps running and serving real customers. We see this situation often. The reflex is to start cleaning up immediately. That is almost always the wrong first move.

Before we change an inherited application in production, we work through the list below. It costs a day or two and regularly saves weeks.

1. Can we even build it?

Sounds trivial. It is not. We check whether the project starts on a fresh machine straight from the repository — without access to the laptop of someone who no longer works there.

If that fails, that is the first job. A codebase that only builds on one specific machine is not maintainable in any practical sense.

2. What is actually running in production?

The state of main is not necessarily the state that is live. We compare the deployed artifact against the repository. Divergence is more common than people expect, and it often explains exactly the bugs nobody could reproduce.

3. Where is the data, and is there a backup?

We establish three things:

• Where does the database live, and who has access?
• When was a backup last restored — not merely created?
• What personal data is processed, and on what legal basis?

A backup that has never been restored is an assumption, not a backup.

4. Which dependencies are end-of-life?

A quick look at outdated packages and open security advisories shows how urgent the situation is. The distinction matters: an outdated package is a maintenance item. A package with a known vulnerability in the authentication path is an emergency.

5. Is there any test at all?

Often the answer is no. That is not a reason to panic, but it sets the approach: without a safety net, you do not make large changes. We write a few coarse tests around the critical paths first — sign-in, payment, data export — before restructuring anything.

Only then: clean up

Refactoring is not the first step. It is the fourth or fifth. Understand first, then protect, then stabilize — and only then improve.

Work in the reverse order and you end up with clean code on a foundation you do not understand. That catches up with you eventually, usually on a Friday afternoon.