Why most Hydrogen migrations take 6 months instead of 90 days

The figure comes up in almost every scoping conversation I have with brands considering a move away from a Liquid theme: the migration was meant to take a quarter, it took two, sometimes three. The conclusion drawn is usually wrong. Hydrogen gets blamed for being immature, React for being verbose, the agency for underestimating. In practice, building the storefront is the most predictable part of the operation, and it is rarely what slips. What blows up the schedule happens elsewhere, in areas the initial quote never examined because they did not look technical.

Let me state the thesis up front, because everything else follows from it: 90 days is achievable if, and only if, the project is a port. Rebuilding in Hydrogen a store whose identity, architecture and data model stay unchanged is bounded, estimable work, and I have seen it hold. The same deadline becomes fiction the moment you add any one of the three projects organisations habitually couple to a migration. The rest of this essay describes the six places where time disappears, in decreasing order of damage.

The app ecosystem is the first sinkhole

A mature Shopify Plus store rarely runs on fewer than twenty installed apps. Reviews, subscriptions, loyalty, cart upsell, search, promotional banners, email capture popups, delivery tracking, returns management. Each was added at a moment when it solved a real problem, and the accumulation has never been audited.

The point almost nobody anticipates is this: a significant share of these apps work by injecting script into the Liquid theme. They install by modifying the output Shopify produces. But in Hydrogen, Shopify no longer renders the storefront. The injection mechanism simply does not exist. Each affected app then falls into one of three categories: it exposes a proper API and can be cleanly reintegrated; it does not, and must be reimplemented by hand; or it gets dropped, which requires a business decision the developer has no authority to make.

On a store with 25 apps, it is not unusual for 8 to survive untouched, 10 to demand significant integration work, and 7 to raise a question that must go back to marketing. Those 7 questions are the real critical path. They are not resolved by writing code; they are resolved by extracting a decision from a busy person.

Inventorying this ecosystem takes 3 days. Producing it before quoting changes the quote. Discovering it in week six costs a month.

The redesign grafted on along the way

The second sinkhole is organisational, and it is almost always agreed to in good faith. Leadership reasons as follows: since we are rebuilding the storefront anyway, we may as well modernise the design. The argument looks unanswerable. It nevertheless doubles the duration of the project, for reasons that have less to do with the volume of work than with the nature of the uncertainty.

A port is a project with a known target. You know what the result must look like: like what exists. Validation is binary and fast — does the collection page behave as it did, yes or no. A redesign is a project with a negotiated target. Every screen becomes a subject of discussion, iterations multiply, and the schedule no longer depends on the team’s velocity but on the pace of internal approvals.

Coupling the two makes a technical delivery date depend on an aesthetic decision process. I systematically recommend sequencing them: port first at identical design, measure, then redesign on sound foundations. The brand that accepts this sequence ships in 3 months and iterates; the one that couples them ships in 7.

A headless migration is not a development project. It is a project of decoupling from an ecosystem nobody has mapped in five years. The code is the easy part.

The content model, discovered too late

The third item is the most insidious, because it is invisible from the outside. In a Liquid theme, a considerable amount of information lives in places that are not structured: rich-text blocks pasted into a product description, homepage sections configured in the theme editor, metafields created ad hoc with no naming convention, sometimes HTML tables written by hand by someone who left long ago.

Rebuilding the storefront requires making that information addressable by an API. Which is to say, modelling it. And modelling existing content means discovering that the same notion is represented four different ways depending on when the record was created. The work is not difficult; it is long, it demands product decisions, and it cannot be parallelised beyond a point.

A content model audit before quoting costs two to three days and moves that risk from the middle of the project to its start. It is, alongside the app inventory, the best investment of the scoping phase.

The cost of each item, by when you find it

Item	Cost if audited at scoping	Cost if found mid-project
App ecosystem	3 days of inventory	3 to 5 weeks
Coupled redesign	0 days — a sequencing decision	+3 to 4 months
Content model	2 to 3 days of audit	2 to 4 weeks
Third-party integrations	1 day of mapping	1 to 2 weeks
SEO parity	spread cost, a design constraint	3 to 6 weeks of catch-up
Decision latency	1 named counterpart, agreed turnaround	15 to 20 working days lost

These orders of magnitude are what I observe on mid-market catalogues; they vary, but the ratio between the two columns is stable. None of these items is difficult. All become expensive at the same moment: when you discover them after announcing a date.

Third-party integrations on no diagram

Next comes the layer of systems that talk to Shopify without anyone thinking about them: the ERP syncing stock, the PIM pushing records, the shipping tool reading orders, the returns service, the accounting connector. Most of these flows go through webhooks or the Admin API, and as such they survive a storefront migration — good news worth stating plainly.

The problem comes from the exceptions. There is almost always one or two flows that, for historical reasons, depend on how the theme renders: a script reading a value from the DOM, a custom pixel placed on a confirmation page, a connector scraping a URL in a precise format. These cases are rare, but detecting them is hard and fixing them is unpredictable. They alone justify keeping slack in the schedule.

SEO parity treated as phase two

The fifth item is the one whose cost is deferred, and therefore systematically underestimated. A migration changes templates, often URLs, sometimes the structure of the information architecture. Without an exhaustive redirect plan, without a faithful transposition of structured data, without verifying canonical tags and server-side rendering, organic traffic degrades — and it degrades with a lag that prevents anyone from making the connection immediately.

Treating it as an end-of-project task is a choice that backfires. I treat it as a design constraint, on the same footing as performance: you do not migrate a page until its redirect and its markup are defined. Folded in from the start, it costs a few spread-out days. Deferred to the end, it produces a three-to-six-week catch-up phase, under the unpleasant pressure of a traffic curve heading down.

Decision latency, which no quote prices

That leaves the factor nobody discusses because it is awkward: how long the client organisation takes to decide. The 7 questions from the app audit, the content model arbitrations, the redirect validation, the choice to keep or drop a marginal feature — each of these decisions is quick to make and slow to obtain.

On a 90-day project, I regularly observe that 15 to 20 working days are consumed waiting on decisions, not producing work. This is not a criticism of the client; it is a property of organisations. But it is a line item that must appear in the schedule, with a single named counterpart and an agreed decision cadence. A project that has not designated that person has already started slipping.

What actually fits in 90 days

Subtract the redesign, inventory the apps and the content model before quoting, treat SEO parity as a design constraint rather than a final phase, and mandate one person to decide within 48 hours — and what remains is bounded work that fits in a quarter: rebuilding templates, wiring the Storefront API, plumbing the cart, holding a performance budget.

The question to ask before committing to a date is therefore never « how long to migrate ». It is: how many undecided questions remain inside this scope. The number of days follows. And it is also why I refuse to quote a migration without producing the inventory first: without it, the number is an assumption dressed up as a commitment, and the gap between the two always gets paid by one side of the table or the other.