PHP Monolith to Microservices — Zero Downtime

A UK professional services SaaS firm was running its entire business on a PHP 5.6 monolith built in 2012. It processed £2M/month in client billing. Two senior engineers had quit within three months, both citing the codebase as the primary reason. The engineering team had effectively stopped shipping new features; every sprint was consumed by firefighting production incidents caused by changes to a system nobody fully understood anymore. The penetration test result was the precipice moment. A third-party security audit had found three SQL injection vulnerabilities in the billing module — the module that touched £2M/month in transactions. The board was given a stark choice: invest in modernisation now, or accept unquantifiable security liability indefinitely. The catch: a full rewrite was completely off the table. The business couldn't sustain 12 months of parallel development while revenue ran through the old system, and nobody trusted a new system until it had survived a full billing cycle in production. The solution had to be incremental — safely eating the monolith from the outside in while it continued to process revenue throughout.

• Average response time of 4.2 seconds, spiking to 15+ seconds during peak billing periods — clients were complaining publicly on review sites
• SSH deployments with manual SQL scripts — average one production outage per deployment, with no rollback mechanism beyond restoring a database backup
• Zero test coverage — every code change was a production gamble; the team had institutionalised fear of touching anything
• Penetration test found three SQL injection vulnerabilities in the billing module processing £2M/month — a security liability growing with every day of inaction
• A full rewrite was financially and operationally impossible — the business needed the old system earning revenue while the new one was built

We executed an incremental modernisation using the Strangler Fig pattern — deploying an API gateway in front of the monolith on day one, then systematically replacing it piece by piece while the business ran uninterrupted. Four months later, the legacy server was switched off without a single day of downtime.

• Phase 1 — Stabilise (Weeks 1–3): Sentry error tracking, Datadog APM, structured logging, and characterisation tests documenting the actual behaviour of 20 critical flows — no changes to business logic, just visibility
• Phase 2 — Extract (Weeks 4–7): Rebuilt authentication as a standalone Node.js/JWT service behind the API gateway, eliminating the session-related outages entirely; patched all three SQL injection vulnerabilities
• Phase 3 — Migrate (Weeks 8–12): MySQL 5.5 → PostgreSQL 15 migration with zero data loss; rewrote the 15 worst-performing database queries; response times dropped from 4.2s to 380ms overnight
• Phase 4 — Frontend (Weeks 10–15): Replaced server-rendered PHP views with a React SPA, module by module, controlled by feature flags — users saw the new UI progressively, never a full cutover
• Phase 5 — Decommission (Week 16): Legacy server retired after 4 months of parallel operation; first clean penetration test result in the company's history