Custom Software

Legacy software modernisation services

The software that runs your business still works, which is exactly why it’s scary to touch. Modernising it safely is about doing it in small steps you can reverse.

Discuss Your Project

The big rewrite is the classic mistake. It takes longer than planned, the old system keeps changing in the meantime, and the new one launches with subtle gaps, since many of the business rules only ever existed in the old code. Sometimes it’s necessary, but it should be the last option you consider, not the first.

The alternative is often called the strangler fig pattern. You put a new layer in front of the old system, build new features in modern code, and move existing functions across one at a time. Users barely notice, and you can stop at any point with a working system. It takes discipline, because you’ll be running two systems for a time, but it swaps one huge risk for many small ones.

First, understand what you have

Before recommending anything, we map what the system does, who uses which parts, and what depends on it. Often a good chunk of it isn’t used any more and can simply be retired, which immediately makes the job smaller. Then we choose an approach module by module: rehost, refactor, replace or retire. For PHP systems in particular, see our PHP upgrade work.

Why this becomes urgent

End-of-support platforms

No security patches for the operating system, framework or database, which also becomes an issue for insurance and audits.

Disappearing knowledge

The people who understand the system are retiring, and it’s hard to hire for the old technology.

Business held back

Simple changes take months, and new channels and integrations aren’t possible.

How we modernise

System assessment

A map of functionality, dependencies, risks and usage, resulting in a written recommendation.

Safety net

Tests that capture current behaviour, so we notice if anything changes unintentionally.

API layer

A modern interface in front of the old system, letting new features work independently.

Incremental replacement

Moving one function at a time to new code, with routing that can be reversed.

Data migration

Staged moves with reconciliation, so old and new can be compared.

Infrastructure moves

Getting off ageing servers to supported cloud or hosted platforms.

A typical modernisation

  1. Assess

    Find out what’s there, what’s used and what’s risky.

  2. Stabilise

    Version control, backups, monitoring and tests.

  3. Wrap

    Add an API layer between users and the old system.

  4. Replace in stages

    Migrate highest-value functions first, and retire what’s left.

How all our projects run

Where it fits

  • Old PHP, classic ASP and VB6 systems
  • Heavily customised off-the-shelf products
  • Access or FoxPro applications that are running core processes

Technology

  • Laravel
  • .NET
  • Docker
  • REST APIs
  • PostgreSQL
  • SQL Server
  • AWS
  • Azure
  • Rector

Legacy Modernisation questions

Should we rewrite or modernise gradually?
Gradually in most cases, as it reduces risk and delivers value sooner. A full rewrite can be justified if the system is small or its platform makes incremental change impractical.
Can the business keep running during the work?
That’s the point of an incremental approach. Old and new run alongside each other, and functions move across a little at a time.
What if nobody understands the old code?
That’s common. We work it out from the code, the database and the people who use it, and capture behaviour in tests before changing anything.

Related services

Interested in Legacy Software Modernisation?

Outline what you need, and we will reply by email with questions or next steps.

Start a Project