The Legacy Modernisation Assessment: Keep, Refactor, Rebuild or Replace?

The Legacy Modernisation Assessment: Keep, Refactor, Rebuild or Replace?

A legacy modernisation assessment is a short, structured review of an old business system that ends in a clear recommendation: keep it, refactor it, rebuild it or replace it, with a cost and a plan for the path that wins. Ours covers six areas (what the system does, its data, its code, the business rules buried in it, security, and the people who use it every day). It starts with a free first look, and the full assessment is a fixed fee that we credit in full against the first phase if you go ahead. This guide explains what we look at, how the decision gets made, what you receive at the end and what we need from you to start.

What is a legacy modernisation assessment?

A legacy system is any software a business depends on that has become hard to change. It might run on a framework nobody supports anymore, be understood by one or two people, or be held together by spreadsheets around the edges. It usually still works. Because it works well enough, replacing it never reaches the top of the list, until a server fails, the developer resigns or an auditor asks for something the system can’t produce.

The assessment replaces guesswork with an inventory. Before anyone talks about technology, we establish what the system does, how much of it is still used, what state the data is in and what it costs to keep running as it is. Only then do we compare options.

AI-assisted development has made rewrites far cheaper than they were five years ago (we covered that shift in enterprise software development in the age of AI). Cheaper rewrites raise the stakes of the assessment, because the question moves from whether a business can afford to rebuild to whether it should.

When does a business need one?

Most of the companies that call us about an old system recognise two or three of these:

  • Only one person understands how the system works, and they are close to retirement, already part-time, or a contractor who has moved on.
  • It runs on a platform past its end of support. Common ones we see are AngularJS (support ended at the end of 2021), PHP 7.4 and older (end of life since November 2022), Windows Server 2012 (extended support ended in October 2023), Microsoft Access, and classic ASP or Web Forms applications.
  • Staff keep a parallel spreadsheet because the system can’t do something they need, and month-end depends on that spreadsheet.
  • Reports run overnight, or someone exports to Excel every week to build the report management actually reads.
  • It can’t connect to anything new: the accounting package, a customer portal, a mobile app, or an API a supplier wants to use. (Integration work can sometimes buy time here.)
  • A security review, POPIA assessment or client audit flagged it, and patching isn’t possible because the framework underneath no longer gets fixes.
  • Every change takes weeks and breaks something else.

None of these on its own means the system must go. Several together usually mean the cost of standing still is already higher than it looks.

What does the assessment look at?

We work through six areas, and the order matters. Behaviour and data come first and code comes third, because a system can have tidy code and still do the wrong things.

1. What the system does

We count everything: screens, reports, printed documents and templates, exports, scheduled jobs, integrations and user roles. Then we find out which of it is still used. In most older systems a surprising share of the reports and screens haven’t been opened in years, and every one you don’t rebuild is money saved. The inventory also becomes the checklist that proves the new system does everything the old one did.

2. The data

We profile every table: row counts, broken links between records, duplicate customers or products, and lookup values that exist only in the database and appear in no documentation. Data migration is the most underestimated part of any modernisation. This step tells us how much cleaning the data needs before it can move.

3. The code and architecture

Language and framework versions, third-party components and their licences, how the system is built and deployed, whether any automated tests exist, and where the code is fragile. This tells us whether parts of the existing code are worth keeping, or whether it is only useful as a reference for what to rebuild. If the system is an older PHP application, our PHP developers can usually tell within a day whether an upgrade path exists.

4. The business rules nobody wrote down

Older systems hold years of decisions in stored procedures, triggers and if-statements. One region gets a different discount, one customer type skips an approval step, one report rounds differently because an auditor asked for it in 2014. We extract these into plain-language rules that your team can confirm. They are what makes the old system valuable, and losing one is the most common reason a rebuild disappoints.

5. Security, hosting and compliance

We look at authentication, password storage, audit trails, backups, where the server runs and who can reach it, and how personal information is handled under POPIA. Some findings here need fixing in the old system straight away, whichever path the business chooses.

6. The people who use it

We sit with the users. Two hours watching someone process an order teaches more than a week of reading code: the workarounds, the screens they avoid, the spreadsheet next to the keyboard. Our business analysts turn their frustrations into the improvement list for whatever comes next.

Keep, refactor, rebuild or replace: how is the decision made?

Every assessment ends in one of four recommendations. Large systems often get a mix, with a different answer for different modules.

OptionWhat it meansWhen it fits
Keep and stabiliseLeave the system in place, fix the security findings, move it to supported hosting and document it.It does its job, changes are rare, and the main risk is the server or one person’s knowledge.
RefactorUpgrade the existing code in stages: newer framework, cleaner structure, tests added as you go.The code is sound underneath and the business logic would be expensive to re-create.
RebuildWrite a new system that reproduces what the old one does, then improve it.The platform is unsupported, the code can’t be changed safely, or the business has outgrown the design.
ReplaceMove to an off-the-shelf product and migrate the data into it.The process is standard (accounting, payroll, a basic CRM) and nothing about it sets the business apart.

We recommend an off-the-shelf product more often than people expect from a custom software company. If a standard package does the job, building your own costs more and gives you nothing extra.

The plan also has to say how the change happens. A single cutover weekend suits systems with clean data and a natural quiet period. A phased move, where the new system runs beside the old one and takes over module by module, suits systems that can’t stop. The price of phasing is a temporary link between the two systems while both are live.

What do you get at the end?

The full assessment ends with a written report and a working session to walk through it. The report contains:

  • an inventory of everything the system does, marked used or unused;
  • a summary of data quality and the migration approach;
  • the business rules we found, in plain language, for your team to confirm;
  • a risk register covering what could go wrong if you change nothing, and what could go wrong in the move;
  • the recommended path, with our reasons and the options we rejected;
  • a phased roadmap, so the first release delivers something useful early instead of everything arriving at once;
  • a fixed price for the first phase and a budget range for the rest.

The fixed price matters. Hourly quotes on modernisation work tend to grow, because old systems keep revealing surprises. We do the investigation before we price so that the surprises are ours to absorb, and the number you sign is the number you pay.

How long does it take, and what does it cost?

Every engagement starts with a free first look. We spend an hour on a screen-share walkthrough of your system with the people who know it best, ask about the code, the data and the hosting, and send you a one-page written view within a few days. It gives you the likely path, the main risks and a budget range. Some businesses can make their next decision on that alone. The first look can also happen at your office. We are on site in Johannesburg, Sandton and Pretoria the same day, and we regularly visit our Cape Town clients.

The full assessment is a fixed fee of R25,000 excluding VAT for a typical business system (one database, a few dozen screens, a handful of integrations). It takes one to two weeks once we have access, and it ends with the report described above and a fixed price for the first phase. If you sign that first phase within 90 days, we credit the whole fee against it, so the assessment costs nothing extra when we do the work. Discovery sessions elsewhere often cost more than this and come on top of the build.

Large platforms are different. When a system has hundreds of reports and templates, several user groups and many years of data, the detail a fixed price needs only comes out of workshops with each group, a full data audit and clickable prototypes of the new screens. These get the same free first look. The detailed discovery then becomes the first, separately priced phase of the project, usually four to six weeks, and it ends with signed-off scope and fixed prices for every release that follows.

What do we need from you?

For the first look, an hour with someone who knows the system well. For the full assessment we need:

  • Access to the source code, or contact details for the vendor if you don’t hold it.
  • A copy of the database or read-only access to it. We sign an NDA first and handle personal information under POPIA.
  • A login to the system with an ordinary user’s rights.
  • Two or three hours with the people who use it most, and an hour with whoever owns the budget.
  • Any documentation, however old, and a list of the other systems it talks to.

If you don’t hold the source code (it happens more often than you’d think when the original developer has gone), tell us at the start. It narrows the options but doesn’t stop the assessment, because the behaviour and the data can still be mapped.

What does a modernisation look like in practice?

The Work Expert runs rehabilitation and functional assessments, with reports for the people assessed and for their employers. Their existing platform had to be rewritten on a modern stack without losing anything the business relied on. The brief was easy to state and hard to deliver. Every existing function had to be reproduced first, and improvements came only where they were specified.

Discovery came first. The build followed in modules (client, visits, reports and administration), with prototypes reviewed by The Work Expert as each one landed. The new platform runs on .NET and Azure, works on mobile, adds biometric client identification and integrates with SAP and QMed. It went live in the first quarter of 2023.

Frequently asked questions

How much does a legacy modernisation assessment cost?

The first look is free. It is a one-hour walkthrough of your system followed by a one-page written view with the likely path and a budget range. The full assessment is a fixed fee of R25,000 excluding VAT for a typical business system, credited in full against the first phase if you go ahead within 90 days. Very large platforms get a separately priced discovery phase instead.

How long does a legacy system assessment take?

The free first look needs about an hour of your time, and the written view follows within a few days. The full assessment takes one to two weeks once we have access to the code, the data and the users. Large platforms with many user groups need a longer discovery phase, usually four to six weeks.

Do we have to rewrite the whole system?

No. Many assessments recommend keeping some parts, refactoring others and rebuilding only the modules that hold the business back. Some recommend an off-the-shelf product instead of custom software.

Can the old system keep running while it is modernised?

Yes. In a phased approach the new system runs beside the old one and takes over module by module. Where the data is clean and the business has a quiet period, a single planned cutover is simpler.

What happens to our data?

It moves with you. The assessment profiles the data, finds duplicates and gaps, and produces a migration plan that is rehearsed before go-live so nothing is lost in the switch.

Which legacy technologies can you assess?

Classic ASP.NET and Web Forms, older .NET Framework applications, PHP, Java, AngularJS and early Angular front ends, Microsoft Access and Excel-based systems, and SQL Server or MySQL databases. Because the assessment looks at what a system does and the data it holds, it also works for stacks such as Delphi or VB6.

Have a system everyone is afraid to touch? Book a free first look. We’ll tell you what we see, including when the right answer is to leave it alone.