Legacy Modernization

Bringing an old but working system onto supported PHP and database versions without a rewrite and without losing behaviour people depend on.

There is a particular kind of system that runs a business quietly for a decade: it works, everyone relies on it, and nobody wants to touch it. Then the host announces that the PHP version it needs is being switched off.

The instinct is to rewrite. Rewrites of systems nobody fully understands are how businesses lose functionality they only discover was important once it is gone. Modernising in place is slower to describe and far safer to do.

What you get

  • A working system on a supported PHP and database version
  • A written inventory of what was changed and why
  • Deprecated and removed functions replaced, with the behaviour preserved
  • SQL moved to prepared statements, and output escaped at the point of output
  • The parts nobody understood documented, so the next person is not in the same position

How the work is done

Read it before changing it

Code that looks wrong is often solving a problem nobody wrote down. Finding out what that problem was costs less than rediscovering it in production.

Change one thing at a time

A version upgrade and a redesign in the same change means that when something breaks, there is no way to tell which one broke it.

Keep it shippable throughout

The system stays working at every stage. There is no point where the business is waiting on a big-bang cutover, and the work can pause without leaving anything half-migrated.

Preserve behaviour, including the odd bits

If a report has always rounded a particular way, it keeps rounding that way. Changing it is a business decision, not a technical one, and it gets raised rather than quietly fixed.

What this does not cover

Sometimes the honest answer is that a system should be replaced rather than modernised — usually when the data model no longer matches the business at all. That assessment comes first, and it comes with reasons, not with a preference for whichever option is more work.

Questions

Our developer left years ago and there is no documentation. Is that a problem?

It is normal. Most of this work starts by reading an unfamiliar codebase and writing down what it does. That written record is part of what gets delivered.

Will the system look or behave differently afterwards?

Not unless you ask for it. The point of modernising rather than rewriting is that the people who use it every day should notice nothing except that it stopped being at risk.

Can this be done without downtime?

Usually the work happens on a copy and is cut over in a planned window. How long that window is depends on the system, and it gets established before anything is agreed.

Related

Business and Database Applications

Internal tools, portals, and reporting systems shaped around how a business actually works, instead of bending the business around packaged software.

Security and Hardening

Making a site survive the automated traffic every public site receives, and cleaning up properly when something has already got in.

Have a system that needs building or fixing?

Describe the problem and you will get a direct answer about whether it is worth doing, roughly what it involves, and what it would take.

Start a conversation