Paul Schell
DEEN

Symfony upgrade without a big-bang rewrite

Is your project still running on Symfony 2, 3, 4 or 5? I move it to a current LTS version in small steps that can each be released on their own, without stopping live operation.

How to tell that an upgrade is due

  • The Symfony or PHP version in use no longer receives security updates.
  • Composer dependencies can no longer be updated because they require newer versions.
  • New PHP versions or libraries cannot be used.
  • Third-party bundles are no longer maintained.
  • New developers struggle to find their way around the old structure.

The official overview at symfony.com/releases shows which Symfony versions are still supported.

How I work

  1. Assessment: Symfony and PHP version, dependencies, existing tests and deprecations. You get a short, prioritised overview.
  2. Securing: tests around critical paths, static analysis and a reproducible environment before I change anything.
  3. Working through deprecations: outdated calls are fixed within the current version. Every deprecation resolved makes the next step smaller.
  4. From LTS to LTS: I move through the versions one after another, for example 3.4, 4.4, 5.4, 6.4 and 7.4. Each stage can be released and rolled back if needed.
  5. Tidying up: bring types, attributes instead of annotations, services and configuration up to today's standard.

Jumping across several major versions at once rarely makes sense, because errors then become hard to narrow down.

Typical stumbling blocks

  • Services fetched from the container via $this->get()
  • Old bundle structure and directory layout (app/ instead of src/ and config/)
  • Reworking the security system to authenticators
  • Annotations that are replaced by PHP attributes
  • Third-party bundles that are no longer maintained
  • A PHP version that is too old for the next Symfony stage

What you have at the end

  • An application on a supported LTS version that keeps receiving updates
  • Traceable changes in small commits or branches
  • Short documentation of what changed and what to watch out for

Frequently asked questions

How long does a Symfony upgrade take?

That depends on size, test coverage and the state of the dependencies. After the assessment I give you a well-founded estimate instead of a flat guess.

Does the application have to go offline during the upgrade?

No. The goal is small steps that can go live at any time. The application stays in operation.

Is an upgrade worth it, or is a rebuild better?

I do not decide that in general. In the assessment I check whether the upgrade pays off or whether individual parts should be replaced. A complete rebuild is the last option.

Which versions do you support?

I work with Symfony 2 to 7.

From the blog

More services