Migrating a store without downtime

Keeping the store reachable is a solved problem: the new environment is live and warm before anything switches, and traffic moves over rather than the old site being turned off. What cannot be avoided is the transition window itself. For a period measured in minutes to hours, some visitors resolve to the old system and some to the new one, depending on their resolver's cache. If both remain writable, orders will land in both, so put the old store into read-only mode at the start of that window. A brief period where a few shoppers cannot check out is much cheaper than order records split across two systems.

This is the single cheapest thing you can do and it is skipped constantly. Your DNS records carry a time-to-live value, often 3600 seconds or higher, which tells resolvers how long to cache the answer. Change the record with a 3600-second TTL and some resolvers keep sending customers to the old server for an hour or more. Drop the TTL to 300 seconds at least 48 hours before cutover — the old TTL has to expire before the new one is respected, which is why doing it on the morning of the switch achieves nothing — and the propagation window shrinks from hours to minutes. Put it back up after launch.

• Set TTL to 300 seconds at least 48 hours before the switch
• Doing it on the day has no effect; the old TTL must expire first
• Verify with a public resolver, not your own machine's cache
• Restore a normal TTL a few days after launch

Between the final data export and the moment the new store takes traffic, any change made in the old system is lost unless you re-import it. That defines a freeze: no product edits, no price changes, no stock adjustments, no order processing on the old system. Most stores can hold a freeze for two to four hours, and the way to keep it short is a delta import — a second pass that pulls only what changed since the main import. Run the main import days earlier, run the delta at the start of the freeze, and reconcile order numbers before switching. Warehouses and fulfilment staff need telling about this window explicitly, because the failure mode is someone shipping against stock levels that no longer exist anywhere.

Session data does not migrate between platforms automatically. Shoppers with an active cart at cutover can reach the new store and find it empty, and for a store with meaningful traffic that is real money — a few dozen people who had already made a decision. Engineering a live-cart transfer is rarely worth its cost or risk. What works is scheduling around it: cut over at your genuine traffic minimum, which for most US stores is somewhere between 2am and 5am Eastern rather than "the evening", and check your own analytics rather than assuming. If you have an abandoned-cart email flow, make sure it survives the migration and fires the next morning.

Two things reliably go wrong at the last minute. The TLS certificate for the production domain has to be issued and installed before DNS moves — requested once traffic arrives, it shows some visitors a security warning, which is the one error message that permanently costs you the customer. Verification methods depending on DNS already pointing at the new server need arranging in advance. Second: a cold cache means your first thousand visitors get the slowest version of the site you have ever shipped. Crawl the top templates before the switch.

Uptime monitors that fetch the homepage every five minutes will report a perfectly healthy store while checkout has been broken for three hours. The check that matters walks the actual purchase path: load a product, add to cart, reach the payment step, and confirm the order object is created. Run it every few minutes for the first 24 hours after cutover. Alongside it, watch order volume against the same hour last week and set an alert threshold you are willing to act on. If orders fall well below that line while traffic holds steady, treat it as a broken funnel rather than a quiet day — it is usually the first honest signal that something is wrong.

Everyone has a rollback plan and almost nobody has tested one. It is worth being blunt about what a real rollback costs: if the old system was frozen and never took orders, reverting DNS is genuinely clean. If the new system has been live for six hours and processed forty orders, rolling back means those orders exist only in a system you are about to stop using, and someone will be re-entering them by hand. That asymmetry is why the decision window matters — agree in advance how long you will give it and what specifically triggers a revert, because deciding at 4am with sales down is how teams roll back from problems that would have resolved in twenty minutes.

A month of parallel hosting is the cheapest insurance in the project. Keep the old store read-only on a non-production hostname, blocked from search engines with authentication rather than robots.txt so nothing is indexed as a duplicate. Cancel it once the first month-end close has come and gone without anyone reaching for it — questions about historical orders arrive for weeks.