AI, in plain words

Blog / Platforms & migrations

Old software, new rules: when to rewrite, and when to leave it alone

Old software is not a problem just because it is old. The signs it is time to act, the signs it is fine as it is, the middle paths between leaving it and rewriting it, and a checklist to decide.

Almost every business runs on some software that is older than it should be. An ordering system built ten years ago. A billing tool written by someone who left. A spreadsheet with macros that only one person dares to open. Sooner or later someone says “we should rewrite this”, and someone else says “it works, don’t touch it”. Both can be right.

This post is about telling which one is right in your case, whether you’re the person who approves the budget or the person who has to keep the thing running. AI tools have made rewriting faster and cheaper than it used to be. That changes the cost of acting. It does not change the question of whether you should.

Old is not the same as broken

Legacy software just means software you still depend on that was built with older tools, or by people who are no longer around. Old software is a bit like an old building: some are solid and only need paint, some have wiring that will start a fire. The age tells you very little. What matters is what it costs you to keep it, and what it stops you from doing.

Signs it’s time to act

  • Security patches have stopped. The language, framework or server it runs on no longer gets security fixes. A patch is a fix the maker publishes when a weakness is found. When patches stop, every new weakness found anywhere in the world stays open on your system, for good. This is the one sign that should not wait.
  • Nobody understands it. The person who built it left, there are no notes, and the team treats it like a locked room. Every question about it ends with “we’d have to look”.
  • Every change breaks something. A small change to an invoice template takes down the export. Changes take weeks, mostly spent testing by hand and hoping.
  • It blocks growth. You can’t add a payment method, connect a new tool, open a new market or handle more customers because the old system can’t keep up or can’t be connected.
  • Hiring for it is hard. Few people still work with the technology, and the ones who do are expensive or busy.

Signs to leave it alone

  • It’s stable. It does its job, it rarely fails, and when it does, someone knows how to fix it.
  • It’s cheap to run. Hosting and maintenance cost little compared with what a replacement would cost.
  • Nobody asks for changes. The business around it isn’t changing, so the software doesn’t need to either.
  • It’s still supported. The platform still gets security fixes, even if it isn’t fashionable.

If all four are true, the best plan is usually to write down how it works, make sure backups run, and spend your budget somewhere else. “Old and boring” is a fine thing for software to be.

The middle paths

The choice is rarely “rewrite everything” or “touch nothing”. Two middle paths solve most cases with much less risk.

  • Wrap it. Leave the old system as it is and build a modern layer around it: a clean connection that other tools can use, or a new screen on top of the old data. It’s like adding a new front door to an old house without rebuilding the walls. You get the connections you need, and the parts that work keep working.
  • Replace one part at a time. Pick the piece that hurts most, say invoicing or reports, rebuild just that, and switch it over when it’s proven. Then the next piece. The old system shrinks step by step, and at no point is the whole business riding on one big launch day.

A full rewrite still makes sense sometimes: when the platform is truly dead, when the system is small, or when the business has changed so much that the old design no longer fits. Even then, the safest rewrites run old and new side by side for a while and compare their results before anyone switches off the old one.

Where AI fits

AI tools help in two ways. They can read old code and explain it in plain language, which makes the “nobody understands it” problem much cheaper to solve. And they speed up writing the new code. What they can’t do is decide which behaviours of the old system your business depends on. That still takes people who know the business, checking the results.

If you want a structured way to look at your own system, our modernization check walks you through the questions in a few minutes.

Checklist: rewrite, wrap or leave it?

  • Does the platform it runs on still get security fixes?
  • Can at least two people explain how it works?
  • How long does a small change take, and how often does one break something else?
  • Is it stopping a specific business goal? Name the goal.
  • What does it cost per year to keep it as it is?
  • Could a new layer around it solve the problem without touching the inside?
  • Which single part hurts most, and could you replace only that part first?
  • If you rewrite, how will you compare old and new results before switching?

Written from our engineers’ work on production systems. Want a second opinion on your project? Talk to an engineer.

See the work →

Want us to look
at your site?

Tell us where traffic, revenue or your numbers stopped making sense. We will tell you what we would check first.

Book a 15-min call

We only send what you ask for. Privacy

Prefer to write directly? enable JavaScript to see the address

Talk to an engineer

No sales theater. Tell us where your operation feels slow, repetitive or difficult. An engineer reads every message and replies by email.

Prefer to talk? Pick a 15-minute slot →

Your message goes straight to our engineers at our address.