Legacy System Modernization: 6 Signs It's Time, and 4 Ways to Migrate

Every legacy system was once someone's modernization project. The system running your business today — the one nobody wants to touch — probably works, mostly, and that's exactly what makes the decision hard. Working software that's expensive to change doesn't announce itself as a problem; it just quietly taxes everything you do. Here's how we tell when it's time, and how to migrate without betting the company on a rewrite.

Six signs it's time

1. You can't hire for it. When the job posting says COBOL, classic ASP, or that framework version from 2012, your candidate pool is small, expensive, and shrinking. Worse, your existing experts become single points of failure with excellent leverage.

2. Releases are feared, not routine. If deploying requires a weekend, a war room, and a rollback plan everyone expects to use, the system is telling you its architecture no longer supports change. Healthy teams ship weekly without ceremony.

3. Security debt is accumulating. Unsupported OS versions, frameworks past end-of-life, dependencies that can't be patched without breaking things. Every month this compounds — and your cyber-insurance questionnaire is getting harder to answer honestly.

4. Licence and vendor traps are tightening. The database licence renews at a price that assumes you can't leave. The vendor of a critical component was acquired, and the roadmap died. When switching costs are your supplier's pricing strategy, the bill only goes one direction.

5. Integration is a project, not a feature. Modern tools expect APIs. If connecting a new payment provider or reporting tool means weeks of custom glue against a system with no clean interfaces, you're paying an integration tax on every future initiative.

6. The business routes around it. Spreadsheets tracking what the system should track, manual workarounds everyone knows, "just email Sarah, she does it by hand." When your team builds shadow processes to avoid the system, the system has already failed — you just haven't invoiced it yet.

Two or three of these, and modernization is worth pricing. All six, and you're paying for it whether you act or not.

The four migration strategies

Rehost ("lift and shift"). Move the system as-is from your server room to the cloud. Lowest cost and risk, fastest to execute — and the least transformative. You keep every architectural problem you have, just on rented hardware. Still, it's often the right first step: it eliminates hardware risk and sets up later stages. Just watch the bill; a lifted-and-shifted system is usually oversized for the cloud, which is why we pair rehosting with the practices in our cloud cost optimization guide.

Replatform. Move to the cloud with targeted upgrades along the way — a managed database instead of a self-run one, containers instead of hand-configured servers. Moderate cost, moderate payoff. This is the pragmatic middle for most SMEs.

Refactor. Keep the system's behavior, restructure its internals incrementally: carve out modules, add tests, introduce APIs. Higher effort, but it converts an unmaintainable system into a maintainable one without a risky cutover.

Rebuild. Replace it outright. Highest cost and highest risk — big-bang rewrites fail often enough that we treat them as the last resort — but sometimes the honest answer, especially when the old system's data model no longer matches the business.

As a rough guide: rehost is weeks, replatform is months, refactor and rebuild are quarters. Risk rises in the same order, but so does how much the system improves.

The strangler-fig pattern, in plain language

The best rebuilds don't look like rebuilds. Named after a fig that grows around a host tree until it stands on its own, the strangler-fig approach puts a routing layer in front of the legacy system, then replaces it one capability at a time. New invoicing module goes live; invoicing traffic routes to it; everything else still hits the old system. Repeat until the legacy core handles nothing, then switch it off.

The advantages are decisive: value ships in months rather than years, each step is small enough to reverse, and there is no single terrifying cutover weekend. The pattern we see repeatedly: a company convinced it needs a two-year rewrite discovers that strangling the two or three most painful modules — often reporting and customer-facing workflows — resolves 80% of the pain within the first six months, and the rest of the plan gets re-scoped around what's actually left.

Where to start

Not with technology — with an inventory. Which capabilities does the old system provide, which ones does the business still need, and which are load-bearing? That assessment typically takes two to four weeks and determines everything else: strategy, sequence, and budget. It's the core of how we approach software development engagements on legacy estates, with cloud architecture decided by the workload rather than by fashion.

If your system is showing more of the six signs than you'd like, get in touch — a short assessment will tell you which of the four paths fits, and what the first six months should look like.