Symfony upgrade
Regular bug fixes for Symfony 6.4 end in November 2026, and some older versions are already unsupported. I bring your application step by step to Symfony 7.4 LTS or 8 and take care of deprecations, bundles and the matching PHP version.
Discuss a Symfony upgradeStefan Pilz · PHP and Symfony development · 100% remote
SERVICE OVERVIEW
A Symfony upgrade brings your application to a Symfony version that still receives bug fixes and security updates. I resolve the deprecations of your current version, update Symfony, bundles and configuration and test the application after every step.
Symfony is designed to make upgrades predictable: whatever disappears in the next major version is marked as deprecated beforehand. If those notices are ignored for years, the backlog grows. Composer then blocks the upgrade, bundles are no longer compatible and nobody dares to touch the application any more.
Then there is the PHP version: Symfony 7 requires PHP 8.2, Symfony 8 requires PHP 8.4. A Symfony upgrade is therefore often a PHP upgrade as well.
SERVICE SCOPE
I make visible which places in your code and dependencies use deprecated features. Tools such as Rector handle many mechanical changes; I work through the rest by hand. Only when the current version reports no more deprecations do we move to the next major version.
The safe route leads through the long-term support versions: 4.4, 5.4, 6.4 and 7.4. Each step is tested individually and can go live on its own. Whether Symfony 7.4 LTS or the current version 8 is the right target depends on your dependencies and on how often you want to upgrade in future.
I bring the bundles in use to compatible versions or replace them if they are no longer maintained. Doctrine, the configuration and the Symfony recipes are updated as well. The application then matches what developers expect today, and new team members find their way around faster.
POSSIBLE STARTING POINTS
The following examples describe possible assignments, not documented client projects.
The application runs reliably, but Composer no longer accepts new packages and the hosting provider announces a new PHP version. The route leads through several LTS versions, one step at a time.
A bundle that a central part of the application depends on does not support any current Symfony version. We check whether a maintained alternative exists or whether the feature is better implemented directly in the application.
Nobody knows for sure whether everything still works after the upgrade. Before raising versions, I cover the key workflows with tests so that errors surface before they reach your users.
RELEVANT EXPERIENCE
Shopware 6, which I have worked with for years, is built on Symfony. Every major Shopware update brings new Symfony versions, and with them exactly the work described here: resolving deprecations, raising dependencies and adapting custom extensions.
Experience
From custom applications and integrations to extensions for Shopware and other systems.
Approach
Each stage has a clear scope, is tested and can be deployed on its own. You always know where the project stands.
DELIVERABLES & SCOPE
We agree the deliverables before starting. Depending on the scope, these may include:
How much work an upgrade takes depends mainly on how many versions have to be crossed and which bundles are in use. Third-party extensions without a maintained version can add effort. The assessment makes this visible.
For an initial assessment, your composer.json or a list of the Symfony and PHP versions in use helps. We agree the scope of the assessment and of the individual stages beforehand.
WORKING TOGETHER
I analyse versions, dependencies and deprecations and show you the upgrade path with its individual stages.
If tests are missing, I first add them for the key workflows. They are the basis for every further step.
Resolve deprecations, raise the version, test. Each stage can go live on its own.
You receive documentation of the changes. If you wish, I also take care of future upgrades so that no new backlog builds up.
RELATED SERVICES
Adapt your code to PHP 8.4 or 8.5 before your current version stops receiving security fixes.
Find out which code is still needed and remove the rest safely.
Assess an established PHP application as a whole and develop it step by step.
QUESTIONS & ANSWERS
Jumping straight from Symfony 4 to 7 is rarely a good idea, because all changes then hit at once. The route via the LTS versions is more predictable. Individual intermediate steps can often be completed quickly once the deprecations have been resolved.
Symfony 7.4 receives security fixes until November 2029 and suits applications that are upgraded infrequently. Symfony 8 brings the newest features, requires PHP 8.4 and calls for more regular upgrades. I recommend the target after the assessment.
Yes. Before the upgrade I add tests for the key workflows. That takes some time at the start but makes this and every future upgrade safer.
Yes. I document the changes and, if you wish, explain to your team how to handle future upgrades without building up a large backlog.
Often yes, but the effort is greater. I check which parts of the code can be carried over and whether a step-by-step upgrade or a rebuild that keeps the business logic is more economical.
NEXT STEP
Tell me the current Symfony and PHP versions and briefly describe what the application does. I will get back to you with an initial assessment of the upgrade path.
Your enquiry goes directly to me, Stefan Pilz. We agree the scope and costs before you commission any work.
I read your enquiry and get back to you. Together, we clarify your goals, constraints and open questions.
Depending on the project, we start with a specific implementation or an analysis agreed in advance.
You know which services and deliverables are included. We agree on scope, effort and costs before you commission the work.