Somewhere in almost every established company sits the system nobody wants to touch. It might be a Visual Basic desktop app, a PHP monolith from 2011, or an Access database that somehow runs payroll. It works, mostly, and the person who understood it left years ago.

The instinct is to rewrite from scratch. Resist it. Full rewrites routinely take twice as long as planned, and while the new system is being built, the old one keeps accumulating changes the rewrite team never hears about. There is a better sequence.

Start with archaeology, and let AI do the digging

Before changing anything, understand what you have. This used to take months of reading code. Today it takes days: modern coding assistants can summarise a 100,000 line codebase, map its modules, flag dead code and generate documentation for functions nobody has opened in a decade.

Do this first, because the biggest modernisation risk is not technology, it is undocumented business rules. That odd conditional in the invoicing module probably encodes a real agreement with a real customer. Find those rules before you break them, and write characterisation tests that pin down current behaviour, bugs included.

Free the data before you touch the code

Most legacy pain is really data pain: the valuable records are trapped inside one application. So your first shipped milestone should be read access, not new features.

  • Stand up a replica or nightly export of the production database.
  • Build a thin API or reporting layer over it.
  • Let new tools, dashboards and even AI agents consume that layer.

This delivers visible value early, which buys patience from management, and it means every later step has a safety net: whatever happens to the app, the data is already liberated.

Strangle, do not demolish

The strangler fig pattern remains the most reliable route: put a routing layer in front of the old system and move one capability at a time to new services behind it. Users keep one URL and one login while the ground shifts underneath them.

Pick the first slice carefully. Good candidates are painful enough that users notice the improvement, but peripheral enough that a bad week is survivable. Reporting, notifications and document generation are classic first slices. Payroll calculation is not.

Each migrated slice should reach production and carry real traffic before the next begins. A modernisation programme with nothing in production after six months is a rewrite wearing a disguise.

Use AI to translate, but verify like a sceptic

Models are genuinely good at mechanical translation: old stored procedures to a modern ORM, jQuery spaghetti to typed components, COBOL-era logic to readable services. Teams that pair an engineer with an AI assistant on this work move several times faster than either alone.

But treat every translated module as guilty until proven innocent. Run the characterisation tests from your archaeology phase against both versions with the same inputs. The model will occasionally "fix" behaviour that was intentional, and those silent corrections are exactly the bugs that surface at month end.

Know when the answer really is a rewrite

Sometimes strangling is not worth it: the platform is dead (think Flash, or a framework with no security patches), the app is small, or the business process itself is changing so much that fidelity to old behaviour has no value. In those cases a rewrite is honest, provided you scope it as a new product with the old data imported, not as a clone.

This is also the moment to ask whether you should be building at all. For many Mauritian firms modernising a custom system from the 2000s, a configured off-the-shelf platform plus a few integrations beats another decade of bespoke code. Firms like nexus.mu spend a lot of their time on exactly this judgement call, and getting it right up front is worth more than any framework choice.

The quiet payoff

A modernised system is not the end state, it is a capability. Once your data is accessible, your logic is tested and your deployment is boring, you can finally do the things the old system forbade: automate workflows, expose customer self-service, and put AI to work on your own records. The goal was never new code for its own sake. It was a business that can change faster than its software.