A PDP Migration With No Room for Error

Context

The Sleep Company is one of India’s fastest-growing D2C brands, and its product detail page is the highest-traffic template on the site by a wide margin. I own Shopify platform strategy and delivery there, leading a cross-functional engineering team end to end.

By the time I got involved, the PDP had been extended for years: badges here, a quiz widget there, a discount banner bolted on for a campaign that never got cleaned up. It worked. It also could not absorb what the business needed next — a new merchandising layout, a faster A/B testing cadence, and a marketing team that wanted to stop filing tickets to change a badge.

The problem

The existing template was a single, tightly coupled Liquid build. Every experiment touched the same file. Every campaign change went through a developer. Testing a new layout meant testing it in production, on the page that converts more revenue than any other page on the site, with no safe way to roll part of it back.

The constraint

This is the part that shaped every decision: the page could not go down, and the error rate could not move, at any point in the rollout. Not for an hour, not for a beta segment. The business does real volume through this page every day, and a “we’ll fix it in the next deploy” approach wasn’t on the table. On top of that, the rest of the team had to keep shipping other sprint work in parallel — this couldn’t be the one project that consumed the whole roadmap.

The approach

I ruled out a big-bang rewrite early. Replacing the whole template in one release is the fastest way to turn a planned migration into an incident, and there’s no rollback that doesn’t hurt when the blast radius is the entire PDP.

Instead:

• Phased, A/B-tested rollout. The new template shipped behind traffic splits, one segment at a time, with the old template staying live as the control the whole way through. Each phase had to hold error rate and conversion before the next segment got the new version.
• Headless PDP layer with server-side streaming, built in React and Next.js, sitting in front of the Shopify backend. This decoupled the experimentation surface from core theme releases — a new PDP test no longer meant a new theme deploy, and TTFB improved because the page could start streaming before every dependency resolved.
• A self-serve CMS layer for the content that used to be the source of most tickets: banners, badges, specs, offers. Marketing could change these without touching a developer’s queue, which also meant fewer emergency deploys during the migration itself.

The alternative I rejected was going fully headless for the whole storefront — cart and checkout included. It wasn’t needed. The problem was specifically the PDP template’s rigidity, not Shopify’s checkout, and replatforming more than the problem required would have added risk with no corresponding benefit.

The result

Zero downtime across the migration. Error rate stayed below 0.1% throughout every phase. Core Web Vitals improved site-wide as a side effect of the streaming architecture, validated via GTMetrix after each deployment. The team kept its sprint completion rate at 90-95% during the work, and live escalations dropped 50% year over year afterward, in large part because config-driven content replaced hardcoded logic that used to break in unpredictable ways.

What I’d do differently

I’d build the self-serve CMS layer first, before touching the migration itself. It ended up being one of the lower-risk, highest-leverage pieces of the whole project, and shipping it early would have taken pressure off the ticket queue during the riskiest part of the rollout, instead of after it.