Taking over an existing project: the ten entry checks

The four checks that decide

Four items are enough to know whether a takeover is possible. If one is missing, the first job is to rebuild it, and that is a project of its own.

1. The complete sources, with their history, not a dated archive.
2. The ability to rebuild the application from scratch, on a fresh machine.
3. The ability to deploy it, with the procedure actually used.
4. The secrets and access: who holds them, where they are stored, how to change them.

Six checks that size the effort

The third line holds the worst surprises. A fix applied directly on a server and never committed disappears at the first deployment — and the bug returns without anyone understanding why.

What not to do in the first weeks

The temptation is to rewrite what you do not understand. That is almost always premature: strange code often encodes a real business rule, learned the hard way, that nobody documented.

Start by making the system observable: usable logs, error measurement, the ability to replay a case. You will then know what actually breaks, rather than what looks fragile.

Write down what you found

A dated assessment, shared with the client, protects both sides. It separates what was observed, what remains to be explored for lack of access, and what was fixed on arrival.

That document also serves as a reference when a defect appears three months later: it says whether it was there at handover or introduced since, a question that quickly becomes contentious without a written trace.

You do not take over software: you take over a system, its access, its history and the knowledge of the people who kept it alive.