PHP Migration Cost — Ranges, Stages and the Cost of Doing Nothing [2026]

A PHP migration costs from 1,500 PLN net for a simple upgrade of a small application to tens of thousands of zlotys for a large legacy system billed in stages. The price depends on three variables: the number of compatibility blockers, the quality of the tests and the number of abandoned libraries. This article breaks the cost down into its components — with ranges, sample quotes and a comparison against the cost of doing nothing.

Key takeaway: A PHP migration is one of the cheapest and most profitable improvements in an old system — usually 3,000–40,000 PLN net depending on project size. The biggest variable cost is replacing abandoned libraries, and the second is writing tests if the project has none. It is an investment that pays back in security, performance and unblocked upgrades.

PHP migration cost ranges — three project types

• The starting point: every PHP migration has the same set of stages (compatibility audit, code fixes, tests, staging, deployment). Only their depth differs — and therefore the cost.

These ranges cover migrations of "one or two generations" (e.g. 7.4 → 8.4 or 8.2 → 8.4). A jump from PHP 5.6 across three generations sits closer to the upper end of the range for a given project size — not because the jump itself is harder, but because systems on 5.6 are usually older "globally": more abandoned libraries and fewer tests.

What exactly makes up the cost

The cost of a migration is the sum of several items, only the first of which is obvious.

Compatibility audit — 1,500–5,000 PLN. A PHPCompatibility and PHPStan scan plus a dependency inventory. Output: a blocker list and a migration plan. In small projects it fits in 1–2 days; in large ones (dozens of modules, custom extensions) it grows to a week. It is the cheapest stage — and the most important, because skipping it means migrating "by feel".

Code fixes — 2,000–20,000 PLN. Automated refactoring with Rector (days of work), then manual fixes where the machines could not go: logic depending on changed language behavior, unusual type casting, generated code. In untested projects add time for manual verification.

Safety-net tests — 0–20,000 PLN. The biggest variable. A tested project: zero cost (you run what exists). An untested project: 15–20 end-to-end tests on critical paths is 5–15 days of work, often half of the whole migration budget. Paradoxically, migrating without tests is cheaper on paper and more expensive in practice — every regression surfaces in production.

Replacing abandoned libraries — 0–15,000 PLN. A dependency with no release for the target PHP must be replaced: with an actively maintained equivalent, a custom implementation, or by cutting the feature. One library can swallow a week. This is the most unpredictable item — which is why the audit inventories dependencies at the start, not halfway through.

Staging, deployment, monitoring — 1,000–5,000 PLN. A test environment on the target version (if missing), the production rollout outside peak hours, a rollback plan and post-deployment monitoring. In mature CI/CD projects this is a routine change — in "deploy by FTP" projects the cost of setting up the process is added.

Framework and dependency upgrades — a separate item. A PHP migration unblocks framework (Laravel, Symfony) and library upgrades. That is a second project worth quoting separately — for a Laravel application typically 1–4 weeks of work depending on how many versions are being caught up on.

Sample quotes

Three real-world scenarios, broken down by item.

• Scenario 1: a company website on a custom CMS, PHP 7.4, ~15k lines.

• Scenario 2: a Laravel 8 + PHP 7.4 application with integrations, ~60k lines, partial tests.

• Scenario 3: a PHP 5.6 legacy system, ~150k lines, no tests, custom extensions.

Staged work over 3–5 months, 50,000–80,000 PLN net in total. Stages: audit and dependency map (1 week), characterization tests on critical paths (3–4 weeks), migration 5.6 → 7.4 → 8.4 with Rector (4–6 weeks), library replacements (variable), stabilization and monitoring (2 weeks). Such projects are quoted in stages, and every stage ends with a working system — not a "big bang" at the end.

The cost of doing nothing — what an old PHP version costs

A migration has an alternative that must be priced honestly: staying on the old version.

• Commercial extended support — for versions past EOL, third parties sell security patches: several to a dozen thousand PLN per year. That is a buffer for large systems, not a target solution.
• The cost of a security incident — an unpatched system where a vulnerability is exploited means cleanup, downtime, credential rotation and possible GDPR consequences. For a store with payments it also means lost trust and traffic.
• The cost of rising rates — developers for old PHP versions are increasingly rare. Every "fix it on 5.6" job costs more than a comparable one on 8.x, and the pool of contractors is shrinking.
• The cost of frozen development — without a PHP upgrade you cannot upgrade the framework or libraries, so every new feature (payments, integrations, partner APIs) is more expensive or impossible.
• The cost of a deferred migration — in a year or two there will be more versions to catch up on, and libraries will have raised their requirements. The cost does not stand still; it grows.

In practice the question is not "whether to migrate" but "when" — and the cheapest moment is always before EOL, when the migration is planned rather than forced by an incident.

How to lower the migration cost without losing quality

Proven ways to bring the cost down — in order of the biggest return.

1. Migrate early and in steps. The 8.2 → 8.4 transition is days of work; the 5.6 → 8.4 jump is weeks. Regular small upgrades are cheaper than rare large ones.
2. Keep tests on critical paths. 15–20 end-to-end tests turn "a migration with manual verification" into "a migration with a green light" — saving days on every subsequent change.
3. Use Rector and CI. Automating the mechanical part is the biggest lever — manual refactoring of the same scope costs several times more.
4. Remove dead dependencies before the audit. A library nobody uses costs as much as a needed one — cutting it before the migration is pure gain.
5. Bill in stages. For large systems, staged billing (audit → tests → migration → stabilization) spreads the budget and the risk, and every stage delivers a working system.
6. Do not combine the PHP migration with a rewrite onto new technologies. A version change and an architecture change in one project doubles the risk. Plan the architecture modernization as a separate stage — after a stable migration.

Where to start — the first step costs 2,000 PLN

The standard starting point is a technical audit: a compatibility analysis, a dependency inventory and a report with a migration plan and quote. The audit costs 2,000 PLN net and answers the question "how much exactly will the migration cost in this project" — instead of ranges from an article you get numbers for your code.

The audit scope is described in the article on the legacy code audit, and the service runs under code maintenance and modernization. The full migration process step by step — from audit to monitored deployment — is in the PHP migration guide. If you are looking at a specific deadline, start with the PHP 8.2 end of life or PHP versions and support dates article.

Frequently asked questions

How much does a PHP migration from 7.4 to 8.x cost?

• For a small project: 3,000–10,000 PLN net (3–10 days of work). For a medium application with a framework and integrations: 10,000–40,000 PLN (2–8 weeks). Large legacy systems billed in stages: from 40,000 PLN. The biggest variables are the state of the tests and the number of abandoned libraries.

Why does a PHP migration cost more when the project has no tests?

Without tests you cannot verify changes at scale — Rector rewrites thousands of lines and every change must be checked by hand or risked in production. Writing 15–20 critical-path tests takes 5–15 days of work, which is often half of the migration budget. But the tests stay in the project permanently — an investment, not a one-off cost.

Can a PHP migration cost less than 3,000 PLN?

Yes — for very small projects (a few thousand lines, no abandoned libraries) migrating from 8.2/8.3 to 8.4 is sometimes 1–2 days of work, i.e. 1,500–3,000 PLN net. The smaller the jump between versions and the better the project's state, the lower the price. Regular small upgrades are the cheapest strategy.

Can the migration cost be spread over stages?

Yes, and for large systems that is the recommended model: audit → safety-net tests → module-by-module migration → stabilization. Every stage ends with a working system and a separate payment, and the budget spreads over weeks or months. Staged billing also reduces risk — you see progress before paying for the whole thing.

What does maintaining the system cost after the migration?

The migration itself does not change the maintenance cost — it lowers it: newer PHP is faster (lower server costs), newer libraries are safer (fewer emergency fixes), and upgrades become possible (less work per change). Care packages start from 300 PLN net per month for a site and 400 PLN for a store.

Is the PHP migration a one-off cost?

The migration of a specific version — yes. But PHP ships a new version every year and support lasts four years, so over a system's lifetime migrations return every 2–3 years. The cheapest model is upgrading "one version" at a rhythm that never lets you reach EOL — the cost then spreads into small, predictable steps.

Sources

• PHP.net — supported versions and schedule
• endoflife.date — PHP support dates
• Rector — automated refactoring and upgrades
• PHPCompatibility — version compatibility scan