How to take over a stalled software project without repeating the mistakes

Stop the loss of information

Gather the repositories, the backups, the server access, domains, databases, email services and external accounts. Do not change the infrastructure immediately; first check whether the backup can be restored and write down who has access.

Keep a copy of the running version and of the database before any intervention. Even a fragile system is a source of truth about the rules users depend on today.

Separate symptoms from causes

A list of errors is not yet an audit. The new team has to follow the architecture, the database, the dependencies, the delivery process, security, and how the requirements were decided. The same repeated error can come from missing tests, from inconsistent data, or from an unclear business rule.

The audit has to end with a document the person who approves the budget can also understand: what can stay, what is dangerous, what blocks the launch and what can wait.

Choose between repair, refactoring and rebuild

The decision must not be driven by the new team's technical preference. What has to be compared is the risk, the time to the first result and the cost of running two systems in parallel.

• Repair is appropriate when the architecture is sound and the problems are localised.
• Refactoring preserves behaviour while gradually replacing the areas that make every change risky.
• A rebuild makes sense when the data model, the technology or the security position make recovery more expensive than a new core.
• A hybrid option can isolate the old system and move the important flows across one at a time, without a large shutdown.

Build a stabilisation period first

Before new features, make delivery repeatable: a test environment, a verified backup, monitoring, an error log and a way back. Add tests around the flows that bring revenue or can lose data.

Then pick a few problems with a visible effect for users. Quick wins are only useful if they do not increase the technical debt you are trying to bring under control.

Handover to the new team

Agree a short period in which questions can reach the old team, if the relationship allows it. Ask for explanations about decisions and exceptions, not for justifications. The goal is business continuity, not assigning blame.

At the end of the takeover you should hold a map of the system, the list of accesses, the deployment steps, the work plan and the accepted risks. Without those, the project may look restarted while depending once again on a few people's memory.