Legacy system modernization

The short version

Somewhere in most established businesses there is a system everyone depends on and nobody wants to touch. It was written years ago by a developer who has moved on, it runs on a version of something that stopped getting security updates a while back, and the person who knew why it does that odd thing in March has retired.

• A system is legacy when nobody can safely change it, not when it is old. Old and working is fine.

• The first deliverable is not code. It is a written account of what the system actually does today.

• Rebuild in stages, with the old system still running, rather than betting the business on a switchover weekend.

• The odd behavior is usually a real rule somebody depended on. Find out before you delete it.

• The discovery and documentation phase is a project on its own, and worth buying even if you then do nothing.

A system is legacy when nobody can change it safely

Not its age. Plenty of ten-year-old software is stable, understood and perfectly fine, and replacing it would be vanity. A system becomes legacy on the day it can no longer be changed safely.

The signals that you have crossed that line:

• Nobody currently employed or contracted can explain how a given feature works.

• There is no test suite, no staging environment, and changes are made straight on the live system.

• It runs on a version of PHP, .NET, a database or an operating system that no longer receives security updates.

• The original developer is unreachable, and the source may or may not be complete.

• Everyone routes around it — exports to spreadsheets, side systems, manual steps that exist because the software cannot.

• Small changes are quoted in weeks, and half of them break something else.

The security point is the one that turns this from an annoyance into a risk. Unsupported software does not fail gradually; it is fine until a published vulnerability makes it very much not fine, and by then you are patching under pressure.

The first deliverable is not code

We read it. Before any proposal about rebuilding, we go through the code, the database and the actual usage, and produce a written account of what the system really does — which is reliably different from what everyone believes it does.

That discovery produces:

• A map of the features, and which ones are genuinely used — the logs usually reveal that a third are not.

• The business rules recovered from the code, written in English, with the surprising ones flagged for you to confirm.

• The data model as it actually is, including the columns whose names stopped matching their contents years ago.

• Every external connection: what talks to it, what it talks to, what would break on the day it stopped.

• A risk list, ordered by what would hurt most and how likely it is.

This is deliverable work in its own right, typically $5,000 to $15,000, and it is worth buying even if you decide to do nothing else. A business that has this document can get a straight answer from any developer. A business without it gets a guess dressed up as a quote.

Staged replacement, not a big-bang rewrite

Nearly always. The all-at-once rewrite is the most reliably disastrous project shape in this industry: months with nothing to show, a scope that grows as forgotten features surface, and a switchover weekend that decides whether your business trades on Monday.

What we do instead is put the new system in front of the old one and move functionality across a piece at a time. Both run together, the old one keeps working, and each stage is small enough that going back is a real option rather than a slogan.

The order is chosen by pain and risk, not by architecture. Usually the first thing to move is whatever is both most dangerous and most self-contained — the piece where a failure would be most expensive and the dependencies are fewest.

What modernization costs

It is quoted in stages, which is the main thing that makes it affordable for a small business. You are never asked to sign off the whole thing at the start, because at the start nobody honestly knows the whole thing.

A full modernization of a system that runs a whole business is measured in months, not weeks, and a number that cannot survive contact with the code is not worth quoting. What we can promise is that you decide at every stage boundary whether to carry on.

The three things that usually go wrong

The same three things, and knowing them in advance is most of the defense.

• Undocumented behavior turns out to be load-bearing. The strange rounding rule exists because a large customer's contract requires it. Deleting it as a bug is how you get an angry phone call.

• The data is worse than anyone admits, and cleaning it is a real line in the budget. Fifteen years of accumulated exceptions do not migrate cleanly, and cleanup is a real line in the budget rather than a rounding error.

• The old system keeps needing changes while you rebuild. The business does not pause, so both systems have to be maintained for a while, and that has to be planned for rather than discovered.

Our habit with the first one is simple: when we find behavior nobody can explain, we write it down and ask you before changing it. Sometimes the answer is "that was always a bug". Often it is not, and finding out costs an email rather than a customer.

Sometimes keeping it alive is the right answer

Sometimes that is the right answer, and it is a fraction of the cost. If the system does what the business needs and the only real problem is that it is running on unsupported infrastructure, the sensible project is not a rebuild.

What that smaller job usually looks like: move it onto supported, monitored hosting, get it behind proper backups, upgrade the runtime as far as it will go, close off whatever is exposed, and write the documentation that does not exist. A few weeks rather than several months, and it buys you the time to decide about a rebuild without deciding under pressure.

We would rather propose that when it fits. A modernization you were talked into is a bad project even when it is executed well.

What you have at the end

A system on a supported stack — currently Laravel and PHP, with MySQL or PostgreSQL — that any competent developer can pick up, in a repository you own, with the documentation that was missing for the last decade.

And a different position: security updates are routine rather than a project, changes are quoted in days rather than weeks, and the business is no longer one retirement away from a system nobody understands. That last part is the real deliverable, even though it never appears on an invoice.

You do not need to know what the old system is written in to start the conversation. Roughly how old it is, what it runs on, who built it, and what happens today when you need something changed — that is enough to say whether discovery is the sensible first step.