From old PHP to PHP 8. While the system keeps running, with a way back at every step.

The assessment costs from 1,250 euros excluding VAT and tells you what the implementation costs. Without an analysis every number is a guess: two applications with the same line count can be a factor of ten apart, depending on whether the dependencies are maintained and whether tests exist. The implementation is quoted at a fixed price after the assessment, before it begins.

As of August 2026: PHP 8.2 until 31 December 2026, PHP 8.3 until the end of 2027, PHP 8.4 until the end of 2028 and PHP 8.5 until the end of 2029. Everything up to and including 8.1 is unsupported, PHP 7.4 since the end of 2022. As a target I usually recommend 8.4: a version that has been out long enough for the libraries to have caught up, and that still has more than two years of support.

No, that is a regular case. It is a different project from a jump off 7.4 though: the harder breaks sit between 5 and 7, the old database functions were removed outright, errors became exceptions. The route therefore runs over an intermediate version in two stages, each one live on its own and reversible on its own. I am a Zend Certified Engineer for PHP 5.3, so I know the starting world from more than the migration notes. What your case means is settled after the assessment, not before it.

Yes, and that is the normal case. Before the first change a net of characterization tests goes in, recording what the system does today. It does not have to be complete: it covers the places that get touched and the paths that money hangs on. That net stays with you afterwards.

No. The upgrade runs as a sequence of small changes, each one deployable on its own and reversible on its own. On the publishing platform from my case studies the modernization ran without a single day of downtime, even though language, search and platform all changed. What matters is keeping as little as possible in motion at once: there, the language switch, the new search and the platform move were three separate projects, each with its own way back.

That is the most common hard case, and it has three answers: a maintained alternative doing the same job, a narrow in-house implementation of exactly what you actually use, or cutting the area off behind an interface of its own. Which answer holds goes into the assessment along with the effort, instead of surfacing in the middle of the implementation.

That is the starting point in most of these projects. There is no documentation, no tests and nobody left to ask. The first step is then not a rebuild but understanding what the system really does today, including the quirks nobody planned and somebody still relies on. That inventory is part of the assessment anyway.

Yes, but as a project of its own, not on the side. A jump across several Symfony or Laravel major versions is regularly bigger than the language change itself and needs an order of its own. Doing both at once is the most reliable way to end up not knowing what a fault was caused by.

Measurably faster, but the order of magnitude depends on your application, not on the language. I will not quote a percentage from a brochure. What I do instead: measure the same paths before and after and put the number in the closing report.