Old software still running your business? Rewrite it or fix it?

Somewhere in a lot of companies there is a system nobody wants to touch. It was built years ago, it runs something important, and the person who understood it best has moved on. It works. Mostly. Nobody is quite sure how.

That is legacy software, and the dilemma it creates is a classic one: leave it alone, patch it, or replace it. Each choice carries real risk, so it helps to think it through rather than reacting to the latest crisis.

First, what is actually wrong?

"It is old" is not a problem by itself. Plenty of old software runs fine. What matters is the specific pain, and there are usually only a few kinds:

• It is fragile. Small changes break unrelated things.
• It is slow or unreliable. Crashes, long waits, mysterious failures.
• It is insecure. It runs on components that no longer get updates. See security basics.
• It cannot connect to anything. Modern tools, payment systems, or mobile access are out of reach.
• Nobody can maintain it. The technology is obscure, the documentation is missing, and developers who know it are scarce and pricey.
• It no longer matches the business. You have changed; it has not.

Name which of these apply. The answer to "rewrite or fix" depends heavily on the list.

The tempting option: rewrite everything

Starting fresh sounds clean. No old baggage, modern tools, a chance to do things properly. And sometimes it is exactly the right call.

But full rewrites have a bad track record, for understandable reasons:

• The old system contains years of quiet decisions and edge cases that nobody wrote down. A rewrite has to rediscover them, often painfully.
• It takes a long time before anything is usable, while the old system still needs care.
• The old and new have to be kept in step in the meantime.
• Stakeholders get impatient because there is nothing to show.

So the rewrite rarely costs less or goes faster than the first estimate.

The calmer option: modernize in stages

Often a better path is to replace the system piece by piece, while it keeps running. Some ways to do that:

1. Wrap it. Put a modern layer in front of the old system so new tools and screens can talk to it, without changing the core.
2. Peel off one function. Pick one area, such as reporting or customer sign-in, rebuild it, and retire that part of the old system.
3. Fix the foundations. Update the platform, document how it works, and add tests, so it becomes safer to change.
4. Move the data first. Get your information into a clean, modern store, then rebuild the applications around it.

Each step delivers something useful and reduces risk. If priorities change halfway, you are not left with a half-built replacement.

When a full rebuild does make sense

Sometimes staging is not practical. A rewrite is more defensible when:

• The system is so small that rebuilding is cheap.
• The technology is truly dead and cannot be wrapped or upgraded.
• The business process itself has changed so much that the old design is wrong for it.
• You have a clear, stable list of what the system must do.

Even then, it is best done in phases with working releases along the way, in the spirit of starting with a minimum version.

Do the homework first

Before deciding, spend a little time on discovery:

• Map what it does. Every function, report, and integration, including the ones nobody mentions.
• Find out who relies on it. And for what. People use features you did not know existed.
• Capture the knowledge. Interview the people who know the quirks, while they are still around.
• Check the data. Its quality and format will drive a lot of the effort.

This work pays for itself whichever path you choose.

Count the cost of waiting

Doing nothing is a choice, and it is not free. Compare modernization costs against what the old system takes each year in maintenance, workarounds, outages, and missed opportunities. For a view of that, see what software costs after launch.

A realistic approach

Pick the pain that hurts most, solve that first, and keep the old system alive until the new parts have proven themselves. Boring, yes. It is also how most successful modernizations actually happen.

What a staged plan can look like

Here is an example of how a staged approach might unfold for a company with an aging order system.

Stage one: stabilize. Nothing visible changes to users. You move the system to supported infrastructure, set up proper backups, and add monitoring so you hear about problems before customers do. You also write down how it works, even roughly. This stage alone often removes the most frightening risks.

Stage two: open it up. You put a modern interface in front of the old system, so other tools can read from it and write to it safely. Suddenly a customer portal, a payment integration, or a mobile view becomes possible without touching the old core.

Stage three: replace the worst part. Choose the piece that causes the most pain, perhaps invoicing, and rebuild it properly. Run the old and new in parallel until you trust the new one, then switch.

Stage four: repeat. Each further piece is smaller and safer than the last, because you now have a stable base and a pattern that works. At some point the old system has so little left in it that retiring it is a non-event.

It is slower than a dramatic overnight switch on paper, but at every point the business is running and you have something that works.

The human side

Technology is usually the easier part. People who have used a system for years have built habits around it, including workarounds that never made it into any document. Change feels like a threat to them, and sometimes it is a reasonable one.

Involve the daily users early. Ask them what they would keep, what drives them mad, and what they do that nobody else knows about. Let them test new pieces before everyone else sees them. Teams that feel heard adopt the new system faster, and they catch problems that no specification would have found.

Plan training, and plan for a bumpy first week after each switchover. Keep a person available who can answer questions quickly.

Signs it is working

You should be able to tell, without a technical background, whether the modernization is on track:

• Something useful ships every few weeks, not only at the end.
• Incidents and emergency fixes are going down.
• New requests that used to be impossible are becoming possible.
• The team can explain how the system works, and the explanation lives in a document, not in one person's head.
• Costs are becoming more predictable.

If months go by with nothing to show and growing talk of how complicated it all is, step back and ask for a smaller next milestone. Complexity is real, but it should not be a reason to stop delivering.

If you have a system like this and are not sure where to begin, send us a description. A first review is often just a conversation.