Update, partly rewrite or replace? Five questions for ageing business software

Business software usually ages gradually. Over time it gets slower, collects workarounds, and at some point a small change takes three weeks. That is when a key decision comes up: should we fix it, rewrite parts of it, or replace the whole system?

You can get a good first answer on your own. Go through the five questions below with the people who use the system every day and with the person who pays for it.

1. Does it still do the job the business needs?

Write down the main tasks the system handles: orders, invoices, scheduling, reports. If it covers them and the feedback is mostly about speed or how the screens work, the core is probably worth keeping. If staff run half the process in spreadsheets because the way you work has moved on from the system, the question goes deeper than code quality.

2. Can it be changed safely?

Ask when the last change was made and how it went. A system that is easy to change has someone who knows the code, up-to-date documentation, automated tests, and releases that affect only what they are meant to. If the original developer has left, documentation and tests are missing, and each release causes side effects elsewhere, change has become a risk. Being able to change the system safely is a business need, even while it runs well today.

3. Is the technology still supported?

Check the versions of the programming language, framework, database and operating system it runs on. When a version reaches end of life, its maintainers usually end security updates for it. On the day support ends, the system keeps running as before. The risk grows gradually afterwards, because vulnerabilities found after that date stay open in your system.

4. Where do the problems come from?

List the last ten issues or incidents and note which part of the system each one involved. In many ageing systems the issues sit in a few places: one slow report, one fragile integration, one import job that needs attention every month. If the issues cluster, those parts are candidates for a partial rewrite. If they are spread across the whole system, a broader approach fits better than a targeted fix.

5. Is the data clean and easy to export?

Your data usually outlives the software. Check whether you can export it in a readable format, whether the database structure makes sense, and whether each field holds what it is meant to, without duplicates. Clean, accessible data makes every option cheaper. Data that needs tidying adds work to any rewrite or replacement, so it pays to know its state early.

Reading the answers

Fix and update: it does the job, problems are few, and the main issue is outdated components. Update them, add tests around the risky parts and keep going.
Partial rewrite: the core works, while issues cluster in a few modules or their technology has reached end of support. Replace those modules one at a time while the rest keeps running.
Replace: your way of working has outgrown it, changes have become risky, and issues are spread throughout. Plan a new system, and plan the data move as carefully as the build.

Most systems land in the middle. Full replacement fits fewer cases than it may first appear, because it repeats work the old system already does well and brings risks of its own. A step-by-step approach also lets you stop or change direction after each step.

Before you decide

Write the answers down and keep the evidence: version numbers, the incident list, a sample data export. The discussion then rests on facts, and any developer you bring in can start quickly.

If you would like a second opinion, our Old system renewal service starts with exactly this kind of review and gives you options with the cost and risk of each. Call us on +371 28786828.