Migrating a Legacy PHP Site to a Modern Stack Without a Big-Bang Rewrite
A client came to us with a PHP 5.6 codebase from 2011, still serving real traffic, with database queries built by string concatenation scattered across 200-plus files. A full rewrite was tempting and also the wrong call — the business couldn't stop shipping for six months, and a clean-slate rewrite on a system nobody fully understood anymore was a good way to reintroduce bugs that had been fixed a decade ago.
We used a strangler fig pattern instead. A reverse proxy in front of the legacy app routed requests by path — anything under /account went to a new Laravel service, everything else stayed on the old PHP app. This let us migrate one feature area at a time, verify it against real traffic, and roll back instantly by changing a proxy rule if something broke.
The database was the hard part. We couldn't run two ORMs against one schema safely, so early migrated features wrote to the legacy database directly using raw queries that matched the old app's conventions, and we only introduced Eloquent models once a table's write paths were fully owned by the new service. That took discipline — it would have been faster to just point Eloquent at everything and hope.
Session handling almost sank the project. The legacy app used PHP's native session files, and the new service needed to recognize a logged-in user without forcing a re-login. We ended up writing a shared session bridge that read the legacy session cookie and validated it against the same file store, which is not something we'd recommend for greenfield work but was the only way to keep users logged in during the transition.
Fourteen months in, about 70% of traffic now hits the new stack, and the legacy app has shrunk to a handful of admin tools nobody's gotten around to migrating yet. The lesson we keep repeating to clients: a incremental migration takes longer in total engineering hours than a rewrite would, but it's the only version where the business keeps functioning the entire time.
