PHP and Symfony migration
Your PHP and your Symfony get security patches again.
Your PHP application gets security patches again without your business stopping for a single day. We work with systems that have been in production for years and that nobody dares to touch: the ones that need it most and can least afford to stop.
Which PHP branches are supported today
An unsupported branch stops receiving security patches. It does not stop working on the EOL date: it keeps working, and that is exactly why the move gets postponed. The risk shows up with the first flaw nobody fixes any more. Data from php.net, current as of .
| Branch | Active support until | Security patches until | Status today |
|---|---|---|---|
| PHP 8.5 | 31 December 2027 | 31 December 2029 | Full support |
| PHP 8.4 | 31 December 2026 | 31 December 2028 | Full support |
| PHP 8.3 | Ended | 31 December 2027 | Security only |
| PHP 8.2 | Ended | 31 December 2026 | Security only, months left |
| PHP 8.1 and earlier | Ended | Ended | No security patches |
Which Symfony branches are supported today
The two calendars constrain each other, and that is what makes this table worth reading next to the one above: every Symfony branch requires a minimum PHP version, so moving one can force the other. Data from symfony.com, current as of .
| Branch | Bug fixes until | Security patches until | Requires PHP |
|---|---|---|---|
| Symfony 8.1 | January 2027 | January 2027 | 8.4 or newer |
| Symfony 7.4 (LTS) | November 2028 | November 2029 | 8.2 or newer |
| Symfony 6.4 (LTS) | November 2026 | November 2027 | 8.1 or newer |
| Symfony 5.4 (LTS) | Ended | February 2029 | 7.2.5 or newer |
| Symfony 8.0, 7.3 and earlier non-LTS | Ended | Ended | — |
What actually happens when a branch expires
- Vulnerabilities stop being fixed
- Your code does not break by itself. What changes is that a vulnerability found in January no longer has a patch, and neither will the one published next year.
- Compliance starts to fail
- An unsupported component is a finding in any security audit, and it blocks certifications such as Spain's ENS or ISO 27001. It also shows up in the supplier reviews run by your clients subject to the NIS2 directive.
- Dependencies freeze before the language does
- Libraries stop shipping compatible versions long before the branch expires. There comes a point where updating a single dependency forces a PHP version jump, and by then the migration cannot be planned: it is done in a hurry.
- The people who know it get harder to find
- Every year that passes there are fewer people with experience on an unsupported branch, and finding someone who knows it takes longer.
How we do it
The goal is to reach the newest version. The path there goes through a supported branch first, and from there your software keeps evolving without each jump becoming a project again.
Inventory of what blocks the jump
Which version runs, which dependencies declare compatibility with the target branch, which are abandoned and which have no successor. It comes out of
composer.jsonandcomposer.lock, without touching production.A safety net before anything moves
If your system has no tests covering its behaviour, they get written before migrating. Migrating without a net is what turns a migration into a crisis.
Stepwise jump, in production
The branch goes up in increments that are deployed and used. There is never a parallel version waiting to be integrated at the end, which is where these projects get stuck.
Dependencies current and sustainable
Abandoned libraries are replaced with maintained alternatives, favouring free-licensed ones so the next update does not depend on a third party's terms.
So the next one is not a project
Your system is left with the tests, continuous integration and documentation needed for a branch upgrade to be maintenance work again.
The evidence
The method is proven where it costs most: a SmartCities platform we have been evolving for five straight years, from PHP 5 to today's supported branches and from Symfony 1.4 to the current versions of the framework. Without rewriting the system from scratch and without ever stopping the service.
Frequently asked questions
- Does the service have to stop during the migration?
- No. The branch goes up in increments that are deployed and used, so at no point is there a parallel version waiting to be integrated. Your service stays in production throughout.
- What if the code has no tests?
- That is the usual case in systems that have been running for years. Tests are written before anything moves, starting with what your business cannot afford to have fail. That work is not lost when the migration ends: it is what makes the next one routine.
- Which version is worth moving to?
- One with active support, not necessarily the newest. Jumping to the latest branch the day it ships usually means waiting for the dependencies to catch up; moving to the previous stable one gives years of runway with the libraries already there.
- How much does it cost and how long does it take?
- It depends on how many dependencies block the jump and what test coverage you have, which is exactly what the first step measures. Until we have it, any number would be made up; with it on the table, we talk about scope and timing with real data.
- Can you migrate from PHP 5.6 or PHP 7?
- Yes, and they are the jumps we know best: the SmartCities platform we have been evolving for five years started on PHP 5, and that route — every intermediate branch, every dependency left behind — is where the stepwise method comes from. They are the longest jumps and the ones that benefit most from being done in parts, because attempting them in one go is what makes them get abandoned halfway.
Where do we start?
Two ways to begin, depending on what you have in front of you today. Answered within one working day.