Legacy PHP modernisation

Move a business system off old PHP, with its data and rules intact

Your ordering, billing or dealer system runs on PHP 5.6 or 7.x and an old MySQL. Nobody wants to touch it, and everything else depends on it. We read it, tell you which route makes sense, and move it.

When this is the right service

  • The system runs on a PHP version with no fixes. PHP 5.6 ended on 31 December 2018, PHP 7.4 on 28 November 2022 and PHP 8.1 on 31 December 2025.
  • It uses the old mysql extension, mcrypt or ereg, so it can’t run on anything current without code changes.
  • It is custom PHP, or sits on a framework that has ended, with no easy upgrade route.
  • You can’t find developers who will work on it.
  • A host, auditor or partner has started asking about the version.

If the application is already on Laravel, even an old version, the Laravel upgrade service is a better fit. If you have lost your developer and need things stabilised first, start with Laravel rescue. For new PHP work, see PHP development.

The routes we choose between

The route comes out of the assessment. We don’t arrive with one in mind.

Modernisation routes, what they involve and a project of ours for each
RouteWhat happensA project of ours
In-place upgradeThe code stays. We fix what breaks at each PHP version and bring dependencies up to date.Live WooCommerce store, PHP 7.4 to current
Re-platformWe rebuild on a framework, migrate the data, and keep the rules and outcomes the same.Loyalty-card system, PHP 5.6 to Laravel, two months
Re-platform with a new front endAs above, and the screens people use every day are replaced too.Cabinet manufacturer, PHP 5.6 and MySQL 5.0 to Laravel 13, PHP 8.5, MySQL 8 and Next.js, about eight months

We wrote up how we decide in rewrite or upgrade.

How the work runs

1. Read the code and the schema

We need read-only access to the code and a copy of the schema. We record versions and extensions, and look for the items that decide scope: the database layer, encrypted data, encoding, and connections to other systems. You get a written recommendation, and a fixed price if you want one.

2. Agree what must not change

Together with the people who use the system, we list the workflows and totals that have to come out the same. This list decides how the new system will be judged, so it comes before any new code.

3. Move the database as its own piece of work

Old MySQL has a route of its own, and data is validated at each step. Our MySQL 5 to 8 checklist shows what we look at.

4. Build or upgrade, then compare

We run the agreed workflows on old and new and compare the results. Differences get investigated rather than assumed to be improvements, since the old behaviour is sometimes a rule nobody remembers making.

5. Rehearse, cut over and stay close

We recommend rehearsing the cutover on a copy, so the window is measured rather than estimated. It can be set up as a zero-downtime deployment where the system allows it, and we agree a way back with you first. After that, the system can move to our maintenance plan or to your own team.

What our two projects needed

On the cabinet manufacturer’s system, the requirement was that the engineering team’s workflows keep working, so the eight months included auditing the old code and schema, validating the data at every step, and comparing each workflow against the old system running in parallel. It is why we suggest setting the comparison up first.

The loyalty system shows the opposite end. It was our own earlier build, so we knew it already. Every card, balance and rule had to come through, and two months from start to live was realistic for that reason. If we hadn’t written it, we would have planned for longer. Most of our work is delivered under NDA, so many projects cannot be named.

Prices

Published upgrade prices by application size
ApplicationPrice (USD)
Small applicationfrom $799
Mid-sized applicationfrom $1,200
Large application (thousands of files, full audit)from $2,999

Legacy PHP modernisation uses this ladder. After a free assessment; fixed price quoted after assessment. Prices are invoiced in USD, GBP, EUR or INR. The cost guide explains what moves a quote on an old system.

Questions

Do we have to move to Laravel?

No. Both of our PHP 5.6 re-platforms landed on Laravel, but that isn't a rule. If your code can move in place to a current PHP version, or your team works in another framework, we will say so.

Our system has no tests and no documentation. Can it still be moved?

Yes, that is the usual state of these systems. The code and the database are the record of what it does. We read both, ask the people who use it, and agree which workflows will be compared against the old system.

Can the system stay live during the work?

Normally yes. The old system keeps running while the new one is built and compared. The final cutover is planned and rehearsed, and the length of any maintenance window depends on your data, so we give you that figure once we have rehearsed it.

What does it cost?

Our published upgrade prices are small application from $799, mid-sized application from $1,200, large application (thousands of files, full audit) from $2,999, in USD. After a free assessment; fixed price quoted after assessment. Older and larger systems can go beyond the top tier.

We are on an old Laravel version, not custom PHP. Is this the right page?

Probably not. See our Laravel upgrade service or Laravel rescue, which are built around that situation.

Systems we have moved off PHP 5.6

Guides on legacy PHP

Tell us what the old system does

You don’t need to know the version numbers. Describe the system and what is worrying you, and we will take it from there.

We reply within one business day (IST). We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment.