A familiar story
The client came to us with a familiar story: a PHP application built in 2013, running on a single server, serving 50,000 daily users. It worked — barely. Page loads averaged 4 seconds. Every deployment was a manual FTP upload followed by a prayer. The codebase had no tests, no documentation, and three developers who understood it had all left the company.
The Strangler Fig pattern
We didn't do a big-bang rewrite. That's how migration projects die. Instead, we used the Strangler Fig pattern: the old PHP app continued serving traffic while we rebuilt it piece by piece. We set up a reverse proxy (Nginx) that routed specific paths to the new Next.js app and everything else to the legacy PHP. Each sprint, we migrated 2–3 routes, verified parity, and switched the proxy config.
The data challenge
The hardest part wasn't the code — it was the data. The legacy MySQL database had 200+ tables, inconsistent naming, no foreign keys, and business logic embedded in stored procedures. We built a data access layer that abstracted the old schema, then gradually migrated to a clean PostgreSQL database using dual-write patterns. For six weeks, both databases stayed in sync while we validated data integrity.
The results speak
Eight months later, the migration was complete. Page loads dropped from 4 seconds to 800ms. Deployments went from manual FTP to automated CI/CD via GitHub Actions. The team went from dreading changes to shipping features weekly. The lesson: you don't need to rewrite everything at once. You need a strategy, a proxy, and the discipline to migrate incrementally. If your legacy app is holding you back, we've been there — and we can help.