Engineers reviewing the architecture of a long-running software platform

Case study

Case study

Modernising a fifteen-year-old platform, without stopping it

An established software platform business · Software & platforms

A platform built up over fifteen years by a series of outsourced developers needed modernising, but the business could not afford a rewrite or a feature freeze. A strangler-fig migration is doing both jobs at once: features that took six-plus months now ship in under three.

The situation

The platform had evolved over fifteen years through a series of different outsourced developers, with little standardisation and a lot of technical debt. Every new feature took longer than the last, and changes in one place broke things in another.

The conventional answers were both unacceptable. A big-bang rewrite would cost too much and carry too much risk, and a feature freeze would stall the product while competitors kept moving. The business needed the platform modernised and the roadmap delivered, at the same time.

What we did

01

Choose an approach that keeps the business running

We adopted the strangler-fig pattern: incrementally moving functionality away from the legacy platform rather than replacing it in one go. The product stays live and earning throughout.

02

Modernise the architecture

The legacy vanilla-PHP MVC install is migrating to a modern Laravel and Nuxt architecture. The two run in parallel, with functionality moving across piece by piece.

03

Keep shipping features

New features are built on the modern stack as the migration progresses, so investment in the roadmap and investment in the platform are the same work, not competing priorities.

The approach

A look at the architecture

How the migration is structured: one front door, two platforms running in parallel, and functionality moving across piece by piece. Module names shown are illustrative.

Diagram of a strangler-fig migration: a single front door routing users to a shrinking legacy platform and a growing modern platform in parallel
How the migration works: one front door routes each request to the platform that owns it. Functionality moves across piece by piece, new features are built on the modern stack, and the product stays live throughout. Modules shown are illustrative.

Outcomes

The results

  • Typical feature delivery down from six-plus months to under three
  • No feature freeze at any point in the migration
  • A standardised, modern architecture replacing fifteen years of accumulated debt
  • Migration progressing steadily, with the platform live and earning throughout

Project in mind? Questions to ask?

Get in touch
Contact Digital Divisor