Symfony maintenance since 2012
Develop your application without weakening its business
PartITech has been developing and maintaining Symfony applications since 2012. An upgrade is not just about changing a Composer constraint: it must preserve business journeys, data, integrations, performance and the ability of teams to continue delivering.
We work on the applications that we have built as on existing platforms. Our goal is to put each project back on a maintainable trajectory, with a version of Symfony, PHP and dependencies that still benefit from security patches.
- Since 2012
- Symfony development and maintenance
- Code, dependencies, infrastructure
- A migration treated as a whole
- Tests before switching
- Changes verified outside of production
Security, performance, continuity
Why keep Symfony up to date?
The framework, PHP, Symfony components and Composer libraries form the same base. Its security depends on maintaining this entire technical chain.
Fix vulnerabilities
Maintained branches receive framework security fixes. Direct and transitive dependencies should be monitored with equal rigor.
Preserve stability
Patched releases resolve anomalies and reduce unpredictable behavior in business processing, APIs, and asynchronous tasks.
Improve performance
Developments to the framework, PHP and its components can improve response times, memory consumption and worker efficiency.
Stay compatible
Symfony evolves with PHP, Doctrine, Twig, PHPUnit and the Composer ecosystem. An old version ends up blocking the upgrade of the entire environment.
Limit technical debt
Processing deprecations regularly avoids accumulating several major breaks, abandoned bundles and a rewrite that is difficult to estimate.
Control the budget
Frequent and measured migrations are more predictable than an urgent modernization carried out when the framework or PHP are already no longer supported.
2026 Calendar
Which version of Symfony should you prefer?
Symfony 8.1 is the current stable version. For applications that favor a long support window, Symfony 7.4 is the reference LTS version.
Current stable version
Symfony 8.1
Released in May 2026, Symfony 8.1 requires PHP 8.4 or higher and has support until January 2027. It is suitable for teams keeping pace with standard releases.
Consult the Symfony 8.1 calendar- Applications using the service container without depending on the HTTP cycle.
- Console commands groupable by methods with less repetitive code.
- More complete mapping of requests and files to typed objects.
- Messenger improvements for batches, priorities, resumes and resets.
- Developments to dependency injection, JSON and translations.
Symfony 8.1
Stable version
PHP 8.4 minimum. Support until January 2027: its adoption requires following the standard version cycle.
Symfony 7.4 LTS
Long-term stability
PHP 8.2 minimum. Bug fixes until November 2028 and security fixes until November 2029.
Symfony 6.4 LTS
Still maintained
PHP 8.1 minimum. Bug fixes until November 2026 and security fixes until November 2027.
Symfony 5.4 LTS
Security only
The branch is still receiving security patches until February 2029, but no more bug fixes. Its old PHP base requires studying the complete environment.
Symfony 8.0, 7.0–7.3, 6.0–6.3
Versions not maintained
These standard branches have reached their end of support. They must join a currently maintained branch.
Symfony 5.3 and earlier
Modernization required
The framework, PHP and many dependencies are generally outdated. Migration becomes a structured modernization project.
Standard or LTS version?
A standard version gives earlier access to new features, but requires an upgrade approximately every six months. An LTS offers a longer maintenance window. The right choice depends on the pace of delivery, business constraints and the team's ability to regularly maintain the application.
Beyond version number
What recent versions change for maintenance
The version upgrade is also an opportunity to simplify the code, improve its observability and bring development practices back to the framework level.
Modern PHP and typing
Recent versions of Symfony take advantage of the attributes, types, and performance of modern versions of PHP.
Dependency injection
Autowiring, attributes, and more explicit configuration reduce repetitive code and make services easier to test.
Messenger and long processing times
Message queues, restarts, priorities and workers must be controlled during a migration to preserve processing reliability.
API and typed data
Request mapping, Serializer and validation allow more explicit interfaces, provided that historical behavior is adapted.
Console and automation
Commands become more expressive and facilitate operation, data migrations and recurring operations.
Depreciation controlled
The deprecation mechanism provides a gradual trajectory between major versions when warnings are addressed before the cutover.
Framework and runtime
Technical compatibility is not enough
The target must have a maintained version of Symfony and PHP
Symfony 8.1 requires PHP 8.4 minimum, Symfony 7.4 PHP 8.2 minimum and Symfony 6.4 PHP 8.1 minimum. A version of PHP accepted by the framework may nevertheless have reached its own end of life.
We therefore separately control the schedules of Symfony and PHP, as well as the compatibility of the database, web server, PHP extensions, workers, cache and deployment tools.
- Official PHP version and support
- PHP extensions actually available
- Doctrine and database compatibility
- Workers, Messenger, cron and long processes
- Web server, cache and observability
- CI/CD and deployment images
Calendars change regularly. Consult the official Symfony calendar and the officially supported PHP versions before setting a target.
A strategy based on what already exists
What to do according to your current version?
The greater the gap with a maintained branch, the more it is necessary to split the project and secure each intermediate step.
You are on Symfony 8.1
Your application is using the current stable version. Patches must be applied and the next standard version planned before January 2027.
Objective: maintain a regular cadence.
You are on Symfony 7.4 LTS
You have the reference branch for long maintenance. Patch releases, dependencies and security alerts remain to be monitored.
Objective: Maintain and process depreciation.
You are on Symfony 6.4 LTS
The branch remains maintained, but bug fixes stop in November 2026. Preparing Symfony 7.4 allows you to avoid a forced migration.
Objective: Schedule the next LTS.
You are on Symfony 5.4 LTS
Security fixes still exist, but historical PHP versions and project dependencies may no longer be maintained.
Objective: audit the entire base and modernize.
You are on an older version
Abandoned bundles, Composer breaks, obsolete PHP versions and architectural changes can require multiple tiers and targeted rewrites.
Objective: build a trajectory in stages.
A verifiable migration
The essential steps of a Symfony version upgrade
Reliable migration makes dependencies, deprecations, decisions, tests, and rollback conditions visible.
Audit of the existing
Symfony and PHP versions, bundles, business code, Composer dependencies, database, interfaces, workers and infrastructure.
Test base
Identification of critical paths and consolidation of tests necessary to detect regressions during migration.
Target definition
Choice between standard version and LTS, PHP runtime, server environment and compatible intermediate levels.
Ascent to the last minor
Updated the current branch to have all deprecation warnings before the major change.
Treatment of depreciation
Adaptation of specific code, configurations and uses removed in the target version.
Updating dependencies
Composer, bundles, Doctrine, Twig, quality tools, front-end libraries and replacement of abandoned packages.
Testing and acceptance
Business journey, API, rights, forms, orders, messages, scheduled tasks, performance, security and external interfaces.
Deployment and monitoring
Backups, failover repeat, rollback, post-production checks, logs, metrics and anomaly tracking.
Proof, not just a version
What the migration should produce
- Inventory of bundles, dependencies and specific developments
- Compatibility report and decision register
- Reproducible Composer files and updated dependencies
- Processing plan for depreciation and incompatibilities
- Test plan and acceptance report
- Restoreable backups and rollback procedure
- Production plan and post-deployment controls
- Operational documentation and maintenance schedule
PartITech Experience
From regular migrations to complex modernizations
Since 2012, we have updated dozens of Symfony applications, notably for Hyundai, the CAUE d'Île-de-France and the CFC. We can also upgrade the servers when their outsourcing is entrusted to us.
We also use applications that we have not developed. This experience allows us to intervene both between two recent versions and on the progressive modernization of an old platform.