Moving a US marketplace from PHP to Node with no downtime

The marketplace was live and was the client's only source of revenue. Advertisers pay to be visible, so they pay for every hour of downtime and get nothing for it. We could not take anything offline, and we could not rewrite the system in place.

The mobile apps shaped the whole rebuild, because we controlled the web but not the phones. A web user gets the new version on their next page load. A mobile user updates whenever they feel like it, and shutting down the old backend breaks an app that is already installed on someone's phone.

Phase 1: stabilize (2 months). We moved the existing PHP application onto AWS without rewriting it. We added a firewall, closed the inherited security holes, moved images to object storage and mail into a queue, and indexed the twenty slowest queries, which made them 90% faster.

Rewriting straight away was tempting, but we stabilized what was earning money first and spent the next two years on the rewrite.

Phase 2: rebuild (2 years). The backend moved from PHP to Node and later to a typed framework, the dashboards to React, the public site to Next.js, the mobile apps to Expo, and the hosting to containers with autoscaling. We deliberately kept MySQL as the one fixed point, the only thing that was not allowed to move. When language, framework, hosting and mobile stack all change at once, you need one thing that stays the same to prove the new version behaves like the old one.

Data moved through a script that remapped the schema, and triggers kept the old and new databases synchronized in both directions for over a year. An ad created in the new system appeared in the old one, and the other way round. We shut the old system down only when analytics showed that its last user had left. Rollback was a change of origin at the CDN: seconds, no deploy.

After the public site moved to Next.js, Lighthouse performance went from 60 to over 90, and SEO from 30 to over 90. The platform lives on organic search, so those scores feed straight into revenue. Amazon measured in 2006 that every 100 ms of added load time cost it 1% of sales, and Walmart found that every second of improvement raised conversion by 2%.

Phase 3: design system. We built over 200 components in a monorepo, shared between the dashboards and the mobile app. Only side effects differ per platform, so web and mobile cannot drift apart.

Phase 4: AI in the process (2026). We wrote the engineering standards as executable rules, checked before every commit and again in CI. Each codebase got its own rule set, because a single set for a backend and a component library would be too loose for one or too strict for the other. Claude Code was in daily use for components, tests and integrations, and design was connected to Figma.

Analytics, across all four phases. This part of the system had to absorb over two million writes a day, keep each advertiser's dashboard live and produce a full year's report in under a second, even for accounts with more than 900 listings. One database rarely manages all three, because a database built for fast writes tends to be slow at complex queries, and a year of raw data at this volume runs to hundreds of millions of rows.

We split the work between two databases. Writes went into a time-series database whose index we kept small on purpose. Once a day, each listing's events were summarized into a row in MySQL, and the dashboard and the invoices read those rows. Raw events stayed for seven days before going to the archive. The annual report never read them at all: it added up 365 daily rows per listing.

• Four phases in four years, zero downtime: no outage was recorded in the logs or reported
• Lighthouse performance 60 → 90+ and SEO 30 → 90+ after the public site moved to Next.js
• Twenty slowest queries 90% faster
• Analytics at 2M+ writes/day with live reads, and an annual report under one second at 900+ listings
• Team throughput up roughly 50% after AI was built into the process, estimated from ticket cycle
• 19 repositories, 506 API routes, 100 data models and 194 migrations, five user types on a single codebase, and four databases, each chosen for its purpose

We let the system spread across nineteen repositories with no shared package. The same queue helper ended up copied into seven of them, so changing a message format means changing it in seven places. A shared internal package should have come before the fifth service rather than after the fifteenth.