Modernise the system you have

Most legacy systems aren’t replaced because the rewrite is too risky. Here’s how we modernise them without one.

The system nobody wants to touch

Every established organisation has one: the system that runs something important, was written years ago, and has quietly become risky and expensive to change. The people who built it have moved on. Small changes take weeks. Upgrades get deferred. The instinct is to start again — a clean rewrite on a modern stack.

Why the big-bang rewrite usually fails

A from-scratch rewrite has to reproduce years of accumulated behaviour — including the edge cases and quiet business rules nobody wrote down — before it can replace anything. Meanwhile the existing system keeps changing, so you’re chasing a moving target. You ship no value until the very end, and cut-over day is the day you find out whether it all works. It is the highest-risk way to spend a large budget.

Modernise in place, one slice at a time

There’s a lower-risk path: leave the system running and replace it from the inside out. Put a seam — a facade or gateway — in front of it. Route one slice of functionality to a new component. Once that slice is proven in production, route the next. The old system shrinks until what’s left is small enough to retire, replace, or safely leave alone.

This is the strangler fig pattern, named by Martin Fowler after the vine that grows around a tree and gradually takes its place. The advantage is simple: you ship value the whole way through, every step is small and reversible, and you’re never one big switchover away from disaster.

A facade routes each slice to a new component; the legacy system shrinks until what’s left can be retired.

You can’t safely change what you can’t see

Before we move anything, we make the system observable and pin down what it actually does — not what the documentation claims. That means real visibility into how it behaves in production, and characterisation tests that capture current behaviour so we can change the inside without changing the outside. It’s unglamorous, and it’s the difference between confident change and crossed fingers.

The same instinct

It’s why we build the tools we operate with — like ebman, our terminal UI for AWS Elastic Beanstalk. You move faster, and more safely, when you can actually see what the system is doing.

The point: software that can change again

A legacy system isn’t a problem because it’s old — it’s a problem because it’s become rigid: every change is slow and risky. Modernising it well is about restoring its ability to adapt. Software that keeps changing as the business changes is exactly what we mean when we call ourselves polymorphic.

Got a system you’re afraid to touch? That’s the kind of problem we like — let’s talk.