How Much Does It Cost to Upgrade PHP?

Upgrading your PHP application can feel like opening Pandora’s box — you never quite know what you’ll find inside. But at some point, it has to be done. Old PHP versions stop receiving security patches, frameworks move forward, and compatibility starts to fade. The question every CTO or product owner asks is simple: how much will the PHP app upgrade actually cost?

In short, for a typical web application, upgrading by one PHP or framework version (for example, from PHP 7.4 to 8.2, or Symfony 5.4 to 6.4) usually costs:

• ~6 000 EUR (≈ 100 hours) for a smaller web app, like an internal CRM
• ~24 000 EUR (≈ 400 hours) for a larger SaaS product

So what, can we wrap up this article? Not exactly — treat those numbers only as a benchmark. Websites and simpler systems will usually fall below these numbers. Enterprise apps, on the other hand, may be way above those estimations. Yet your case might be different.

Each upgrade is unique, and the cost depends on a long list of factors. Let’s walk through the most important ones, so you can draw the parallel to your project.

Test Coverage - Automated Tests vs. Upgrade Cost

Testing is the most important part of upgrading your PHP application.

The biggest cost driver of any upgrade is not the code change itself, but testing what breaks after it. It takes a lot of time and effort, yet doing it badly will skyrocket your costs in future as it will lose you customers or force you to make a rollback.

Without automated tests, every feature has to be tested manually — repeatedly — after every fix. That’s slow, expensive, and prone to human error. In larger systems, it’s often not even possible to manually test every use case, which leads to “post-upgrade surprises” in production.

In one of our projects, a healthcare app with around 80 features in several variants resulted in about 400 use cases. Testing each manually would take a week of QA work. Instead, the team wrote 1 500 automated tests — 80 % of which could now be generated or assisted by AI. Writing them once took two to three weeks, but they’ve already been run more than 50 times across future upgrades; in this scenario, conducting manual tests after each upgrade would have taken us ages.

The math is simple: automated tests are an upfront investment that pays off quickly. Without them, upgrade costs can easily spiral, especially if you end up fixing post-release bugs or — in the worst case — rolling back.

Automated Error Monitoring

Another underestimated factor is error visibility.

Tools like Sentry track background exceptions that users never report but still matter.

During upgrades, this data is priceless. You can see exactly which errors existed before and which ones appeared after. In our last two upgrade projects, 80% of logged errors were unrelated to the upgrade itself, thus only 20% needed our attention. Knowing that saved weeks of unnecessary debugging. Without proper monitoring, the team would have wasted time fixing old issues that had nothing to do with PHP 8.

Bottom line: you need to know what’s broken before you start upgrading — not after.

From Which Version to Which?

A jump from PHP 7.2 → 7.4 is much simpler than 7.2 → 8.2.

The same logic applies to frameworks — upgrading Symfony 5.4 → 6.4 is much easier than jumping from 3.4.

Roughly speaking, every new version makes future upgrades about 30–40 % easier, assuming modern features are used responsibly.

Technically, you can skip intermediate versions (e.g., 4.4 → 6.4), but only in rare situations. You might save ~20 % of developer time, but you’ll likely double your overall project time and have an extremely painful merge experience. For an active product, that means double the time without new features, so it’s safer to upgrade step by step.

Are You Upgrading Only PHP, or Also a Framework?

Some say that a programming language is only as good a the frameworks available for it. Nowadays, developers rarely write anything literally from scratch, without using any frameworks or libraries. Modern development is more like composing and coding only the crucial business logic differences. Probably it is why the most popular tool for managing dependencies in PHP is called Composer ;)

Usually, these go hand in hand. Frameworks evolve along with PHP, and new framework versions require newer PHP versions anyway.

Upgrading PHP alone brings performance and language improvements.

Upgrading the framework unlocks new features, APIs, and tooling.

If your app uses no framework at all, the upgrade can be simpler — but only on paper. Without a framework, all business logic is custom-written, and every line must be checked manually. Framework-based apps, by contrast, “auto-upgrade” part of their logic when you pull a new version.

How Deeply You Use Framework Features

We’ve seen “Symfony apps” that barely used Symfony — no forms, ORM, or event system. Upgrading such a codebase is cheap, but also barely meaningful.

In general, the more of the framework you use, the more might break after an upgrade. Deprecations, new APIs, and removed or refined features all take time to address.

Some upgrades also offer an opportunity to adopt new tools — like Symfony Messenger in version 4.1. You can either keep your old implementation or modernize it during the upgrade. Optional features can extend the timeline, but also deliver long-term value.

Deprecations

Deprecations are features of a programming language (or a framework) that will no longer be supported in newer versions (so will fail after the upgrade).

Tools like Rector can scan your code and even auto-fix many of them, but business logic decisions still require human input.

For example, if PHP 8 forbids passing null to a certain function, the team must decide — should the app block the user, or assume a default value? Each such decision takes time. The more deprecations, the longer the upgrade.

Third-Party Dependencies

Modern PHP apps rely on hundreds of external packages.

If your app uses well-maintained libraries, Composer will handle most of it almost automatically.

But if you depend on niche or abandoned packages, you might have to replace them entirely — often rewriting whole sections of your app.

This can easily add days or weeks to an upgrade timeline.

Code Consistency and Team History

Was your app built by one disciplined team, or by five teams over ten years?

Consistency matters. The same logic implemented five different ways means five different fixes to make.

Even something as simple as checking if an array is empty can vary:

empty($array) vs. count($array) === 0.

If PHP changes how one of these behaves, you now have an inconsistent upgrade effort scattered through the code.

Infrastructure Readiness

Before the PHP upgrade — your servers, CI/CD pipelines, and hosting must support the target version. Otherwise, you can end up waiting weeks for infrastructure updates before you can deploy. Always confirm compatibility before starting the upgrade.

The Size and Nature of the Software

This one seems obvious, but deserves a note.

“Size” isn’t just about lines of code. It’s also about the number of features, their complexity, and how critical they are.

An internal CRM and an enterprise ERP might both have “hundreds of screens,” but their upgrade complexity is worlds apart. That’s why pricing should always be scoped feature-by-feature, not per-file or per-user.

So, Can You Get a Precise Quote?

Precise? No. Quote? Yes.

Upgrade projects are part detective work, part craftsmanship. Every case has surprises — hidden dependencies, business-specific logic, or infrastructure quirks. Still, based on hundreds of PHP and Symfony upgrades we’ve completed, we can assume roughly:

So 6000 EUR on the low and 24000 EUR on the high end.

If your app has automated tests, error monitoring, and proper infrastructure, these numbers are realistic.

And to give you a broader sense:

Those are approximate prices for Accesto services. Besides, all those numbers are calculated for 1 PHP version update, not a jump in a couple PHP versions. You could probably find cheaper hourly rates somewhere, but upgrading legacy code safely is not a junior’s or “promising mid developers” task. It takes senior developers who understand both PHP internals and real-world architecture — the kind of experience that saves you money by not breaking production.

Final Takeaway

Upgrading PHP or a framework isn’t just a technical exercise. It’s a test of how maintainable your system really is.

Automated tests, monitoring, and consistency all translate directly into money saved.

Skipping them might look cheaper — until your customers hit a bug that your team didn’t catch.

In short: if you want a cheaper upgrade, invest in quality early.