Your working software doesn’t owe anyone a rewrite

I’m not rebuilding your app just because the code offends me.

If it takes orders, gets people paid and keeps the business moving, it has earned a more serious assessment than a developer opening the repository and announcing that they would have built it differently.

Of course they would. They have different tools, different preferences and the benefit of seeing what the last person learned the expensive way. That does not automatically make starting over a good use of your money.

A rewrite can be the right decision. But the case for it should survive a conversation about your business without relying on the phrase “modern tech stack.”

The ugly part might contain something you still need

Consider a hypothetical wholesaler with an old ordering system. The screens look dated. Generating a particular report is slow. A new developer proposes replacing the whole thing.

Then someone in accounts explains that several customers use negotiated prices. A delivery can be split across two dates. A credit note can apply to only part of an order. One long-standing customer needs a different export format.

None of that makes the old code good. Some rules may be obsolete. Some may be workarounds that deserve to disappear. But somebody has to find out which is which before the replacement starts taking real orders.

A clean new checkout that forgets an agreed price is not an improvement for the person handling the complaint. And rebuilding a workaround nobody needs is a particularly expensive way to preserve a mistake.

This is one reason the old application deserves investigation. Martin Fowler’s account of gradual modernization describes both difficulties: existing behavior can be hard to recover, and some of that behavior should not be reproduced at all. The work starts with understanding the outcome you want.

Make the problem specific enough to price

“The system is old” gives an owner very little to act on. “The monthly report ties up an employee for an afternoon because the export drops these records” gives the team something to investigate.

Those statements could lead to the same final decision. They should not lead to the same opening proposal.

For the wholesaler, I would want to follow an order through pricing, stock, delivery and accounting. I would also want to understand the report’s actual failure. Perhaps a query needs attention. Perhaps the reporting component needs replacing. Perhaps the data model makes the required report impossible without a larger change.

The point of that work is to distinguish those possibilities. It should have a defined scope, useful findings and a stopping point. An assessment that produces only a larger assessment is not much help to the person paying for it.

Code quality does matter here. If a routine price change requires touching unrelated parts of the app, or nobody can safely deploy a fix, the business is paying for that design. Explain the consequence and show the evidence. “I dislike this framework” is a preference; “we cannot support this dependency and here are the affected functions” is a problem to solve.

You can replace a part without gambling the whole operation

Suppose the reporting component really is the problem. One option is to build its replacement alongside the current system, compare the results using the same sample orders, and move that job over once the business has checked it. The ordering process can stay where it is while the report is improved.

That is an option to investigate, not a promise that every application comes apart neatly. You need to know where the data comes from, which component owns changes and how the two versions will coexist.

Microsoft documents this incremental approach as the Strangler Fig pattern. Its guidance also covers the costs: temporary infrastructure, cross-system dependencies and the risk of the routing layer becoming a bottleneck. It explicitly identifies cases where the approach may not fit, including a small system that is simple to replace or an old system that must be retired quickly.

You do not need to buy a microservices project to take the underlying question seriously: can we deliver the required improvement while changing less of the business at once?

If two versions will run together, put that period in the budget. Agree on the comparison, the switch and the cleanup. Ask what happens to records created after the switch if the team needs to go back. “We have a backup” does not, by itself, explain how yesterday’s orders survive that decision.

Sometimes I would recommend the rewrite

A familiar screen can hide a serious problem. Unsupported components, recurring failures, inaccessible source code or a design that cannot support a necessary business change can make keeping the application expensive or unsafe. Those deserve attention even when staff have learned to live with them.

A small, well-understood tool may also be cheaper to replace than to surround with temporary connections. There is no virtue in maintaining two systems merely to claim the migration is gradual.

I would compare the work still needed under each option: repair the current application, replace a bounded part, or build a replacement. Include data migration, integrations, staff training, support during the change and the work required to retire the old system. A proposal that prices only the new screens has left out a substantial part of the decision.

AI can help inspect code, draft changes and produce candidate tests. It can make useful modernization work faster. It cannot decide whether an undocumented pricing exception is a contractual promise, an obsolete workaround or a bug. Someone needs to resolve that with the business, then check the resulting behavior.

Before you sign the rebuild proposal

Ask the developer: “What would you need to find for you to recommend keeping this application?”

If there is no possible answer, you are being offered a predetermined solution. Ask for the evidence behind it before committing the budget.

At Rosecraft, we improve existing systems and the connections between them, as well as build new applications. Bring us the workflow that hurts, the changes you need and the reason you have been told to start over. We can scope an assessment and a practical next step, whether that means a targeted repair or a justified replacement.

If you are ready to hear what your software needs—even if the answer challenges the rebuild you have already been sold—send us a message. You should be buying a better way to run your business, not paying to make your code fashionable.