Zero-Downtime Ecommerce Migration

Zero-downtime cutover is achievable through careful sequencing, not luck — an hour-by-hour runbook, named go/no-go checkpoints, spike-load testing before the actual cutover, and a documented rollback trigger. Nuts.com moved catalog, customers, orders and live subscriptions off a homegrown platform onto Shopify Plus using exactly this discipline.

Last verified: September 6, 2026.

Zero downtime is a planning outcome, not a platform feature

No platform gives you a zero-downtime cutover automatically. It's the result of planning the cutover as a defined sequence of steps with contingencies at each one — the same discipline whether the destination is Shopify or anything else. Teams that treat it as a property of the destination platform tend to discover on cutover night that the sequencing decisions were still theirs to make, and are now being made under time pressure.

That framing also sets the expectation correctly with stakeholders. Zero downtime doesn't mean nothing can go wrong; it means the plan has a defined response for the things that can, and none of those responses require taking the store offline.

What a real runbook specifies

A cutover runbook is hour-by-hour, not day-by-day, and it names people rather than teams:

• The exact freeze window for the old system — when it stops accepting new orders, and how that's communicated to customers if at all
• The data-sync sequence — which system is the source of truth during the transition window, and in what order orders, inventory, and customer data sync
• Named go/no-go checkpoints with one accountable decision-maker at each, not a committee
• A rollback trigger defined in advance — "if X fails, we roll back" — rather than a judgment call made under pressure at 3am
• A customer-communication plan for the case where the cutover window runs long

The rollback trigger is the item most often left implicit, and the one that matters most. A trigger nobody wrote down becomes a debate at exactly the moment there's no time for one, and the default outcome of that debate is always to push forward — which is the wrong default when something has already failed.

DNS, caching, and the tail of a cutover

The mechanical detail that most often produces unplanned downtime is propagation. DNS TTLs need lowering well before the cutover window — hours or days ahead, depending on the current value — so that the switch actually takes effect on the schedule the runbook assumes. CDN and edge caches need an explicit purge step in the sequence rather than being left to expire naturally.

Plan for a period where some traffic is still reaching the old system after the switch. That's not a failure state, it's the normal tail of a cutover, and the runbook should say what the old system does with an order that arrives during it.

Load testing against realistic peak traffic, not average

A cutover plan tested only against average daily traffic isn't tested against the pattern most likely to expose a problem. Spike testing against realistic peak load — the highest hour you actually saw in the last year, not the daily mean — catches capacity issues a quieter test window misses entirely.

This is doubly true if the cutover is anywhere near a seasonal peak. Replatforming during peak season covers how the risk calculus changes when it is.

Parallel run vs. big bang

Two cutover strategies exist, and they distribute risk differently rather than one being safer in the abstract. A parallel run keeps both systems live during a transition window; a big bang cuts over in a single event. Most enterprise replatforms are better served by a carefully sequenced big bang with a genuinely tested rollback plan — see the full comparison for which fits which risk profile.

Rehearsing the cutover

The runbook should be executed at least once against a staging environment before the real thing, timed. A rehearsal does two things a written plan can't: it surfaces the steps that take four times longer than estimated, and it tells you whether the people named in the runbook can actually perform the step assigned to them. Both of those are much cheaper to learn in a rehearsal than on the night.

It also produces the one number stakeholders actually want, which is how long the window really is — measured, rather than estimated by the person who wrote the plan.

Nuts.com's six-month migration is the reference point worth studying here: catalog, customers, orders, subscriptions and five custom product builders moved off a homegrown platform through discovery, design, implementation and launch, with trading uninterrupted throughout.

What "zero downtime" means to different people

Worth settling before the plan is written, because the phrase means at least three different things to the people in the room. To an engineer it usually means the storefront never returns an error. To a merchandiser it means orders never stop being accepted. To a finance lead it means no revenue gap in the reporting.

Those aren't the same commitment. A cutover can keep the storefront up while briefly queueing orders rather than confirming them, which satisfies the first definition and not the second. Write down which one the plan is actually delivering, and get agreement on it, rather than letting three people hear three different promises from the same phrase.

The 30 days after cutover

A zero-downtime cutover is a start, not a finish. The first month is when real traffic finds the edge cases that a rehearsal cannot, and the plan should say who is watching what.

• Order flow, end to end — not just that orders are created, but that they reach the OMS, the warehouse, and the customer's inbox, with tracking flowing back
• Error rates and server logs, watched daily rather than checked once, since a small persistent failure rate looks like nothing on day one and a lot by day thirty
• 404 reports, for the redirect gaps only real traffic reveals
• Conversion and funnel metrics against the pre-migration baseline, segmented by device — a mobile-only regression is easy to miss in a blended number
• Marketing tag and pixel fire rates, compared against the historical baseline, because this category fails silently and passes every visual check

Staff it deliberately. The most common failure in this window is not that nobody noticed a problem, but that the person who noticed had no route to someone who could act on it, because the project team dispersed the day after launch.

Where this fits

Zero-downtime cutover is the fifth of the seven disciplines in Anatta's replatforming method. It depends on the one before it: a cutover plan is only as good as the confidence you have in the data on the other side of it, which is what parity testing establishes.

Frequently Asked Questions

Is zero-downtime migration realistic for a complex ecommerce site?

Yes. It requires a detailed, hour-by-hour runbook with named checkpoints and a tested rollback plan, not a hope that nothing goes wrong. Nuts.com's migration — a homegrown platform, live subscriptions included — is a real example at meaningful scale.

What's the biggest risk to a zero-downtime cutover?

Testing only against average traffic rather than realistic peak load. Capacity issues that surface only under spike conditions are the most common cause of an otherwise well-planned cutover running into trouble.

Should we rehearse the cutover?

Yes, at least once against staging, timed. A rehearsal surfaces the steps that take far longer than estimated and confirms the named owners can actually perform their step — both much cheaper to learn before the real window.

What is a rollback trigger, and why write it in advance?

It's a pre-agreed condition that ends the cutover and reverts to the old system. Writing it in advance matters because a trigger nobody documented becomes a debate at the moment there's least time for one, and the default outcome of that debate is always to push forward.

Does zero downtime mean nothing can go wrong?

No. It means the plan has a defined response for the things that can, and none of those responses require taking the store offline. It's worth agreeing which definition of "zero downtime" the plan delivers — storefront availability, order acceptance, or no revenue gap — because those are three different commitments.

What needs watching in the first 30 days after cutover?

Order flow end to end, error rates in server logs, 404 reports, funnel metrics segmented by device, and marketing tag fire rates against the historical baseline. Staff it with someone who has a route to a person who can act, not just observe.