Turn the next Symfony major into a two-week exercise instead of a quarter-long project, with deprecation discipline, Rector-driven mechanics, and a phased plan that ships in parallel with features.
Every quarter the upgrade slips. Deprecation warnings drown real errors in the logs. A bundle you depend on dropped support for your Symfony version six months ago, and the security patch you need lives on a major you cannot reach.
We measure deprecation debt, bundle health, container drift, and Rector dry-run output against the target Symfony version. You get the real scope before anyone commits to a delivery date.
Before the upgrade branch even exists, we install the practices that keep the upgrade from becoming a project. Deprecation-as-error in CI, Rector on every PR, and a sprint budget for bundle hygiene that pays compounding returns.
The actual version bump in a single branch, in the right order. PHP minor first, ship it, stabilise, then Symfony. Rector handles the mechanical migration, we pair with your engineers through cutover and the first week in production.
Every deprecation classified by source, by the Symfony version that introduced it, and by rough count. Every bundle inventoried with its maintenance status, latest version, and compatibility with the version you want to reach.
AuditA phased plan with weekly milestones, dependency ordering, risk-rated steps, and an estimate the board can fund. Includes the PHP minor bump and any asset-pipeline migration as sibling subprojects, not hidden line items.
RoadmapA production-ready rector.php targeting your current and next Symfony major, wired into CI, with import-name policy and php-cs-fixer integration aligned with your existing code style.
ConfigThe deprecation-as-error CI configuration, the per-sprint bundle hygiene allocation, the framework.yaml drift procedure, and the container diff workflow, captured as the reference your team uses on the next major.
PlaybookThe mechanical version bump is one to three days. What takes longer is deprecation cleanup, bundle hygiene, and container drift. A team that did continuous work pays one to two weeks per major. A team that deferred for three years pays three months.
No. The pilot installs deprecation-as-error and Rector before the upgrade branch exists, so cleanup runs in parallel with features. The actual cutover is a deploy window, not a feature freeze, and is usually a single off-hours release.
You walk the majors back-to-back, not in one heroic jump. 5.4 to 6.4 ships and stabilises, then 6.4 to 7.x ships and stabilises, then 7.x to 8.0. Six to nine months total elapsed, each leg a short focused project.
No. PHP minor bumps have their own failure modes (readonly semantics, string/int edge cases, new deprecations) and entangling them with Symfony changes doubles the debug surface. We always ship PHP first, bed it in for a week, then Symfony.
Yes. The deprecation and bundle audit ships as a standalone two-week engagement with a fixed price and a fixed scope. You get the report, the costed roadmap, and the Rector configuration, with no obligation to continue the engagement.