Before you rewrite your PHP app, ask for an upgrade plan

Before you approve a proposal to replace your PHP application, ask for the upgrade plan. If nobody has investigated whether the existing application can run safely on a supported version, the comparison is missing a fairly important option.

That question is timely. In a September 1 announcement, Clever Cloud said PHP 8.5 will become its default in the image release following October 1, 2026. PHP and FrankenPHP applications deployed without a specific version, or set to the general version 8, will use 8.5. Applications already pinned to a specific version are unaffected by that default change.

This is a change on one hosting provider, not a deadline for every PHP application. But it is a useful prompt for any business that depends on one: who knows which version you run, what supports it, and what happens when it changes?

Find out which problem you are paying to solve

A hosting default change, an unsupported runtime and an application that no longer fits the business require different responses. Bundling them together makes a proposal difficult to judge.

The PHP project's current support schedule says PHP 8.2 reaches the end of upstream security support on December 31, 2026. PHP 8.4 leaves active support that day but continues receiving critical security fixes through December 31, 2028. Those are very different positions. Your operating-system vendor or hosting provider may also have its own maintenance arrangements; the version number alone does not describe all of them.

For example, Ubuntu's September 10 PHP security notice supplies package updates for affected supported Ubuntu releases. It includes fixes for its PHP 8.1, 8.3 and 8.5 packages. You need the applicable vendor's package and support information to assess a deployment properly.

None of this is permission to ignore security maintenance while debating a redesign. An application that needs patching still needs patching while the bigger decision is being made.

Ask to see what actually fails

My starting point would be a separate test environment and a short list of the things the business cannot afford to lose. Can a customer place an order? Can staff correct it? Does the right amount reach the accounting system? Can an administrator change access without breaking the next login?

Then run those workflows against the proposed PHP version, with the application's libraries and extensions checked as well. PHP's own 8.4-to-8.5 migration guide explicitly calls for testing incompatibilities before switching production. Clever Cloud also advises checking extension availability and validating the application in a review or test environment.

The useful output is a list of observed failures, the work needed to fix them and the things nobody has verified yet. An abandoned library might need replacing. A report might depend on behavior that changed. Or the application may need far less work than a new build would require. You find that out by investigating.

I would want the estimate to include deployment and recovery too. If an upgrade changes stored data, going back may require more than restoring the previous code. That belongs in the plan before somebody chooses a launch date.

The awkward business rules still have to go somewhere

Imagine a distributor with an old ordering application. Most customers pay on checkout, a few have agreed payment terms, and a particular export keeps an external warehouse supplied with orders. This is an example, not a client story.

A replacement can have a much nicer interface and still mishandle those exceptions. The new team has to discover which rules matter, decide what to retain and prove the replacement behaves correctly. The existing application may be the only complete record of some of those decisions.

Understanding those rules is part of the replacement cost. Put it in the estimate, and test the new implementation against them. An upgrade needs those checks too: changing the runtime can expose assumptions in existing code.

A rewrite can earn its place

Sometimes the assessment makes the case for replacement stronger. The application may depend on components nobody can support. Its structure may make a required permission model impractical. The business may have changed enough that repairing the old workflow would preserve the wrong thing.

Those are reasons worth discussing. So are the costs of continuing to maintain a system, the availability of people who can work on it and the risk of repeated failures. A rewrite should be compared with a credible maintenance plan, including what each option lets the business do and what each option leaves unresolved.

There may also be a smaller replacement worth making first: move one troublesome integration or workflow, check the result, and decide what comes next. That approach has its own costs, especially while two systems coexist. It deserves an estimate rather than an automatic recommendation.

Make the next decision smaller

If you are facing an upgrade notice, ask for an assessment with a concrete deliverable: the support position, the workflows checked, the failures found, a costed upgrade option and a reasoned recommendation. Any remaining unknowns should be visible.

That is the sort of technical assessment Rosecraft offers, alongside integration and modernization work. The aim is to give you enough evidence to choose the work that is worth paying for.

I enjoy building new applications. Enjoying the build is not a good enough reason to ask a business to replace one. Show what the upgrade would involve first, then make the case for doing more.