The rewrite can wait. Find the actual problem.

Inherited software arrives with baggage. Unfamiliar conventions. Missing documentation. A screen nobody admits to owning. Somewhere in the first conversation, someone proposes a rewrite.

That might be the right decision. It is a lousy diagnosis.

Before authorizing replacement, identify the business work that cannot happen. “The application is a mess” describes a reaction. “Dispatch cannot release an amended order” gives someone a problem to investigate.

Follow the stranded work

Choose a failing journey with a person at the start and a business result at the end. Ask the person doing the work to walk through it, including the spreadsheet or phone call that keeps things moving. Don’t tidy their account into the workflow the software was supposed to support.

Consider this fictional scenario: a distributor can approve new orders, but an order amended after approval never reaches dispatch. Staff print the amendment and carry it downstairs.

Start there. Record the starting state, the action, the expected result, and what happens instead. Establish whether the failure affects every amendment or a particular combination of status and permissions. Ask what happens to the order while everyone waits. That determines urgency better than the age of the framework.

Make the failure safe to repeat

Build a sanitized case that preserves the relevant relationships without copying customer details or credentials. Use synthetic names and addresses. Keep the status transitions and permission differences that appear to matter. Sanitization that removes the trigger produces a reassuring but useless test.

Run it in an isolated environment with outbound messages and fulfillment disabled. Record the software version and configuration differences from production. Keep a comparable case that succeeds so the investigation has something to contrast.

If the failure cannot be reproduced, say so. Capture the next occurrence through approved, narrowly scoped diagnostics. Do not turn “we couldn’t reproduce it” into “the users are confused,” and do not poke at live orders to manufacture certainty.

Map what this journey needs

Draw the path from amendment to dispatch. Include the application, data store, scheduled work, external services, and human handoffs that participate. On each connection, note what moves across it and who can inspect a failure.

Then add the operational facts: where this version runs, how it gets deployed, who holds access, and how restoration works. Mark unknowns plainly. Record whether anyone has tested restoring the backup, and what that test covered.

This map has a boundary: the stranded order. You do not need a museum catalog of every package in the repository. You need to know whether a repair touches dispatch alone or changes the records accounting also depends on.

Choose a repair you can undo

Suppose the fictional investigation shows that amendments retain an approval state the dispatch screen excludes. A narrow correction may be enough. Preserve other order states, test the failing case alongside ordinary orders, and have dispatch confirm the result.

Write the rollback before release. Reverting code does not reverse changed records. If the intervention modifies data, define how to identify those records and restore or reconcile them. Name who can stop the rollout and what observation would trigger that decision.

A temporary workaround can be responsible when it has an owner and an expiry condition. An undocumented workaround with an indefinite lifespan is just another damn inheritance.

Sometimes replacement is the responsible choice

Replacement deserves consideration when the platform cannot meet required security controls, support has ended with no viable upgrade, or core data structures cannot express the business correctly. It may also win when repeated repairs cost more than a credible migration.

Compare those options honestly. Replacement includes data conversion, coexistence, staff training, cutover, and retirement of the old system. Repair includes its continuing constraints. A newer stack alone settles neither case.

You can replace the dispatch capability without replacing the entire business application. Scope follows the failure and the constraints, not the enthusiasm for a clean repository.

The one-page rescue brief

Fill this in before approving a repair or a replacement investigation:

• Business journey: Who is blocked, doing what, and what counts as completion?
• Impact and containment: What work is stranded? What safe workaround exists, and who owns it?
• Reproduction: Sanitized case, expected versus observed behavior, environment, and successful comparison case.
• Operational map: Participating systems, human handoffs, owners, deployment path, and restoration gaps.
• Known cause or open question: Separate observations from the current explanation.
• Proposed intervention: Smallest useful change, affected records, validation, rollback, and stop authority.
• Replacement threshold: Which constraint would make repair unsuitable? What migration work must an alternative include?
• Decision: Named approver, next review date, and evidence still needed.

If that page cannot explain why the order is stuck, a rewrite proposal is premature. Fund the investigation first.