Modernizing legacy PHP onto Symfony, without a rewrite

Every long-lived PHP application eventually gets the same proposal: rewrite it. It is popular because it is easy to estimate, and it is wrong for almost the same reason — the estimate cannot include the decade of behaviour nobody wrote down.

The alternative is less satisfying and it actually finishes. You keep shipping features, and the modernization happens underneath.

The order that works

• A real DI container first. Until there is one, nothing can be tested in isolation and every improvement stays local. Bootstrapping Symfony's container alongside the legacy entry point means new code is written properly from day one while the old code keeps running untouched.
• Then routing, one controller at a time. Attribute-routed controllers live beside legacy scripts if the framework sits in front and falls through for what it does not recognise. Each page moved is a small, shippable, reversible change.
• Data access last, and in phases. This is the slow part, and rarely because of the ORM: years of inserts leave data the schema never actually guaranteed. Adding a foreign key to a table that violates it is not a migration, it is an outage. Measure the violations, fix or quarantine, then constrain.

Putting a floor under it

Static analysis at a level that passes, wired into CI and raised one step at a time — a permanently red check teaches a team to ignore checks. Error tracing across backend and frontend, because you cannot prioritise the next piece of modernization without knowing what actually breaks.

What it buys

Not elegance. A codebase where the next feature is cheaper than the last, and where each step is small enough that nobody has to ask the business for a six-month freeze.