Strangler Fig in practice: what running two frameworks in one app taught me
On a whiteboard the pattern is simple: route by route, old and new side by side. The hard parts are the session, the database and the people. Notes from a migration that stayed in daily use.
A rewrite is the most expensive way to replace software, because for months you pay for two systems and only one of them earns money. The Strangler Fig pattern avoids that: the new code takes over one route at a time, the old code keeps serving the rest, and the business never notices a cutover. I spent a year doing exactly this, moving a platform from an old framework on an unsupported PHP to Laravel on PHP 8.4. These are the parts the diagrams leave out.
One session for both
The bridge is a middleware: it looks at the path, and either hands the request to the old framework or lets the new one handle it. The catch is the session. If the two frameworks keep separate sessions, a user logs in on a migrated page and is logged out on the next. The fix was one session store, read by both, with the same cookie, so the login was simply shared.
One database, no second truth
- The new module reads and writes the same tables as the old one. No sync job, no replica, no "we will merge the data later".
- Schema changes are expand first, contract later: add the column, backfill, switch the writers, drop the old column in a later release. Never in one step.
- Tests around the old behaviour before it changes. Characterization tests, not unit tests: what does this endpoint return today, exactly.
A flag per module
Every migrated module got a flag that routes it back to the old code. Not a feature flag framework, a line in a config file. It was used twice. Both times the business did not notice, and both times the fix shipped the same day. That is the whole argument for small releases.
The runtime on the way
The PHP upgrade from 7.4 to 8.4 happened during the migration, not after it. Waiting would have meant another year on a runtime without security fixes. Each minor version was its own release with its own test run; the deprecation list was the roadmap.
The people part
The developers who knew the old framework were the ones who had to learn the new one, on a system that kept running. That worked because every release was small enough to review in an afternoon and every rollback was one line. Confidence came from the flags, not from a plan.
If you are looking at a system like this, the first step is not the bridge. It is the tests around what you have, and a tested restore of last night's backup.
More notes: What I am busy with: rebuilding this site with one stylesheet, one script and a live terminal · all posts