The build is late. Progress meetings repeat the same blockers. A demonstration works on one laptop, but nobody can explain what it would take to run the product reliably for customers. Someone suggests starting again.

A rewrite can feel like relief because it replaces a complicated present with a clean future. Before choosing it, establish what is preventing useful software from reaching users. The answer may be a fragile integration, an unclear decision or a release process that depends on one person. Replacing the application would leave some of those problems untouched.

A rescue should produce a clearer picture of the system and a credible next move. That begins with evidence from the work itself.

Establish what the business needs to recover

Ask the business owner to describe the consequence of the delay. Are staff spending hours reconciling records? Is a customer waiting for a promised feature? Does an existing system stop the company accepting more orders?

Those answers establish priorities. A product with a broken payment flow and an unfinished settings page has two incomplete features, but the consequences are different. A useful recovery plan makes that difference visible.

Choose a short list of outcomes that would demonstrate recovery. For example, a customer can complete an order, the team can release a fix without the original developer and support can identify why a transaction failed. Agree who can accept each outcome. Avoid starting with a new delivery date for the entire old backlog; that turns diagnosis into another promise made without enough information.

The outgoing team should be part of this conversation where possible. Ask what they have learned and which decisions remain unresolved. Blame makes people defensive and can remove access to the most useful knowledge in the room.

Prove that the system can be operated

Begin with the current source, deployment process and running environments. Check whether a new engineer can build the application using the documented instructions. Establish which revision is running and where configuration comes from. Find the owner of the infrastructure and the person who can grant appropriate access.

If the build cannot be reproduced, investigate that before making broad changes. Otherwise, a local success may have little connection to what customers receive. An undocumented dependency or a manually edited server can invalidate an apparently simple release.

Map the main dependencies at the level needed to work safely. Which external services receive data? Which scheduled jobs move records overnight? Which queue can accumulate work? The aim is a usable map with named owners, not an exhaustive architectural report before anyone is allowed to fix a bug.

Check how the team would recover from a failed change. A database backup matters only if someone can restore it to an appropriate environment and verify the result. Treat that as controlled operational work: agree the environment, access and recovery objective before running an exercise.

Trace one failed journey from beginning to end

Pick a business-critical failure and follow a concrete example through the system. Start with what the user tried to do, identify the affected record and inspect the points where it changed state.

Imagine a warehouse application that sometimes creates duplicate dispatch requests. Rewriting the warehouse interface may do nothing to fix the cause. The problem could occur when a caller retries after a timeout and the receiving service cannot recognise a repeated request.

In that example, useful investigation would compare request identifiers, stored records and the timing of acknowledgements. The repair might require repeat-safe processing and a reconciliation workflow for existing duplicates. The exact change depends on the evidence. A screenshot of two duplicate rows is the starting point, not a diagnosis.

Keep observations separate from explanations. ‘Two requests share this reference’ is an observation. ‘The mobile app sends twice’ is a hypothesis until the request path confirms it. Writing the distinction down makes it easier for another engineer to challenge the theory without reopening every fact.

Protect the behaviour that already matters

A troubled system may still contain years of useful business rules. Some will look odd because the circumstance that produced them is no longer documented. Removing them without checking can turn a recovery project into a new operational problem.

For the area you are changing, gather representative inputs and record the outputs that the business expects. Include cases people remember causing trouble: a cancelled order, a partially received shipment or an account with an unusual permission. These examples can become tests around behaviour that must survive the repair.

Do not attempt to test every line before improving anything. Concentrate on the journeys with material consequences and the boundaries your change touches. A narrow check that catches a duplicate dispatch is more useful than a large collection of tests that only confirm internal implementation details.

When existing behaviour is wrong, agree the correction explicitly. Preserving everything would preserve the defects too. The question is whether the change is understood, accepted and recoverable.

Compare repair, replacement and removal

For each troublesome area, consider the smallest intervention that could meet the agreed outcome. A repair may be enough. A replacement may be justified where the component cannot be supported or its structure blocks necessary change. A feature nobody needs may be removable.

There is an established approach to gradual replacement: Martin Fowler’s Strangler Fig pattern describes moving behaviour into new components over time. It gives teams a way to modernise part of a system while the rest continues to serve the business.

That option still needs careful data planning. Decide which component owns a record during the transition, how you will compare results and what happens if the new path fails. Avoid allowing two systems to update the same information independently without a deliberate reconciliation design.

Our preference is to make a replacement decision at the smallest useful boundary. A reporting component may need to change while order entry remains serviceable. Replacing both at once adds a dependency to the recovery plan unless the business can explain why they must move together.

Give the recovery a stopping point

Unbounded cleanup is an easy way to turn a rescue into another stalled build. Define what the first recovery phase will leave behind:

  • A repeatable way to build and release the relevant software.
  • A working critical journey, demonstrated against agreed examples.
  • A way to detect and investigate the failure being repaired.
  • Named responsibility for the remaining risks and the next decision.

Keep a short recovery log. Each entry should connect a change to the problem it addresses and the evidence used to verify it. This is especially useful when several teams are involved or confidence has been damaged by previous promises.

Show unfinished work honestly. ‘Order creation is verified; cancellation still needs an agreed rule’ is more useful than a completion percentage. It tells the business which decision can help the team move forward.

When a rewrite earns its place

A rewrite may be the right choice when the current system cannot meet an essential requirement and a smaller change is impractical. It may also be reasonable for a small application whose useful behaviour is well understood and cheap to reproduce.

Write down the costs beyond new code. Data migration, integration changes, user retraining and the period of supporting both versions all need owners. Include a way to validate the replacement and a decision point at which the business can reassess the investment.

The next meeting should end with an intervention that can be reviewed against evidence. Bring the failed journey, the likely cause, the proposed change and the conditions for accepting it. A team can rebuild confidence through that work, one demonstrated result at a time.

Use a deliberately small first slice to turn the recovery decision into a release people can evaluate.