Repair or rewrite?

A rewrite is a conclusion, not a starting point. Most of the systems we are asked to rewrite do not need it. They need an owner, a repair plan, and a few months of patient work. A few of them do need a rewrite, and the only way to tell the difference is to understand the system first.

Why rewrites are proposed

Rewrites are rarely proposed because a system is technically beyond repair. They are proposed because nobody on the current team understands the system, and rebuilding it feels like the only way to get that understanding back.

That is an honest motivation. It is also the most expensive way to achieve the goal. A rewrite recreates the knowledge by recreating the software, and everything the old system learned from years of production, every edge case and every fix, has to be learned again.

The second common reason is frustration. Slow changes, recurring incidents, and an unfamiliar stack make a fresh start attractive. The frustration is real. The remedy is usually ownership, not replacement.

What we look at before deciding

We do not answer the repair-or-rewrite question in the first meeting. We answer it after a review that covers five things.

What the system does. Not what the documentation says or what the founder remembers. What it does in production, for which users, and how often. Many rewrites are scoped against imagined usage.

Where the risk is. Which parts break, which parts nobody touches, and which parts hold data that cannot be lost. Risk is usually concentrated in a small part of the codebase.

Whether it can be changed safely. Is there a way to deploy a change and know it worked? Are there tests, staging environments, backups, and rollbacks? If not, those come first regardless of the final decision, because a rewrite without them is a bigger version of the same problem.

What the stack costs to keep. Frameworks and runtimes reach end of life. Hosting bills grow. Some stacks are hard to hire for. These are real costs, but they are measurable, and they are often smaller than a rewrite.

What the business needs next. A system that needs three small features a year has different requirements from one that needs to double its capability. The rewrite decision depends on the destination, not only on the current state.

When repair is the answer

Repair is the answer more often than teams expect. The signs:

• The core data model is sound, even if the code around it is messy.
• Problems are concentrated. Two or three modules cause most incidents.
• The system is in production with real users, and the behavior they depend on is mostly undocumented.
• The stack is old but supported, or can be upgraded in steps.

Repair means establishing ownership, adding the safety equipment (tests around the risky parts, monitoring, reliable deployments), and then improving the system in place, one bounded change at a time. Users see stability first and improvements second. Nothing is thrown away until its replacement is proven.

When a rewrite is the answer

Some systems do need to be replaced. The signs are specific:

• The platform is unsupported and cannot be upgraded. A framework with no security fixes is a deadline.
• The data model is wrong for what the business now does, and every feature fights it.
• The system was built for a scale or a use case that no longer exists, and most of it is dead weight.
• The cost of understanding it exceeds the cost of specifying it, which happens with generated or heavily copied code that has no coherent design.

Even then, we rewrite in pieces where we can. A new system that takes over one responsibility at a time from the old one keeps the business running and keeps the decision reversible.

A decision matrix

The five review areas above reduce to a small table. Score each row for the system in front of you; the column with the most marks is the recommendation, and a single "replace" in the platform row overrides the rest.

Question	Points to repair	Points to modernize in place	Points to rewrite or replace
Is the platform supported?	Yes, current versions	Yes, but several upgrade steps behind	No, and it cannot be upgraded
Does the data model fit the business?	Yes	Mostly; a few structures fight new features	No; every feature works around it
Is there a safe way to change it?	Yes	Partly; tests and rollback exist for some parts	No, and adding them costs more than the parts are worth
Where is the risk?	Concentrated in two or three modules	Spread across a layer that can be replaced alone	Everywhere; no coherent design to preserve
How much of it is still used?	Most of it	Most of it, with dead areas to delete	A minority; the rest serves cases that no longer exist
What does the business need next?	Small features and stability	Significant new capability on the same foundation	A different product

Repair is maintenance with a plan. Modernizing in place is our modernization service. A rewrite is still done in pieces where we can, with the old system running until each piece has proven itself.

The position

Understand the system, make it safe to change, then decide. Teams that skip to the rewrite skip the part where they learn what they are replacing, and that knowledge is the most expensive thing to rebuild.