Migrating a store without a week of broken checkout

A store migration goes well when checkout is the last thing you disturb and the first thing you prove. An ecommerce migration checklist is a sequence: a staging copy, catalog parity, payment in test, DNS last, and a person watching the first real orders.

The failure mode is familiar. The new shop looks finished, the domain switches, and the first afternoon is a string of carts that cannot pay. You do not need a week of that. You need the new store to take a real order before the old store stops being the one customers see.

Staging is the store, with the doors closed

Build the new shop on a staging address that your team can use and customers cannot. Put the real theme, the real catalog, and the real pages there. A prototype with placeholder products will not tell you whether sizes, images, or taxes survive the move.

Treat staging as the place you are allowed to break. Create an order. Edit a product. Open the same product on a phone. If a basic path fails here, it will fail in public, with less time to think.

Keep the current shop untouched while this happens. Customers are still buying from the live site. The migration is a parallel build, not a renovation done in the aisle.

Give staging its own passwords and a robots rule so it does not pretend to be the public shop. People should not land on it from search, and the team should not confuse its admin with the live one. Label the browser tab. The mistake you are preventing is a half-finished product edit on the store that is still taking money.

Catalog parity before any visual debate

Parity means the new catalog matches the decisions you meant to keep. Same live products. Same prices. Same variants that should still be for sale. Same policy pages a shopper needs at the moment of payment: shipping, returns, and contact.

Diff the two catalogs in a sheet. Live on the old shop and missing on the new one is a blocker. Present on the new one and discontinued on the old one is a decision you should make on purpose, not by import accident. Photographs that show the wrong color are blockers too. A migration that ships the wrong object is a worse bug than a font you dislike.

Freeze the catalog once parity is agreed. Later edits happen in one place, with a named owner, or they happen twice and disagree. The freeze can be short. It cannot be imaginary.

Read a sample of products out loud from both shops. Name, price, the variant that matters, and one sentence of description. Ten products chosen on purpose, including an awkward one, will show import damage that a dashboard count will hide. A count of "1,200 products moved" can still mean the sizes came across as separate items.

Payment in test, then one real order

Checkout is where a migration becomes a business event. Baymard Institute's research on abandonment names failures a broken launch will cause on purpose. The institute states that 17 percent of US online shoppers have abandoned an order because the checkout was too long or complicated. The same account of reasons includes a site that had errors or crashed, and a shopper who did not trust the site with a credit card. A cutover that throws errors at the moment of payment walks into those failures.

Run payment in test mode until the happy path and the obvious failures are boring. A successful card payment. A declined card. A coupon you actually honor. Shipping that matches the live rules. Tax that matches the live rules. The confirmation page and the email that follows, both stating what happens next.

Then place one real order for a small amount, on production credentials, while the new shop is still on the staging hostname or a private domain. Refund it. You are proving the pipes, not making a sale. If that order fails, DNS stays where it is.

web.dev describes Core Web Vitals as field measures of loading, interactivity, and visual stability, with good thresholds of an LCP within 2.5 seconds, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, judged at the 75th percentile for mobile and desktop. Check the new product page and the checkout on a phone before you switch. A shop that only feels finished on a studio display will feel broken to the person paying.

Write down the test card results and the one live order number. When someone asks whether checkout works, the answer is a record, not a recollection from the meeting.

DNS last

Point the domain only after staging, parity, and payment have passed. DNS is not the moment you discover a missing variant. Lower the TTL ahead of time so a rollback is fast if you need one. Know who can change the records, and know the previous values.

Have the old shop's admin and the new shop's admin both open. For a short window you may take final orders on the old system, export the last few, and import them once, or you may pause for an announced hour. Pick one plan and write the hour down. An improvised overlap is how two systems sell the same last unit.

Redirects go on with the domain. Every old product url that still deserves a visit should land on the new product. Check the list. A sample of ten is a start. The urls in your last newsletter and your top sellers are the ones to open by hand.

Do this on a day when the person who can refund, edit a product, and change DNS is available. A Friday evening cutover with nobody watching is how a small bug becomes a weekend.

A person watches the first real orders

After the switch, someone who understands the shop watches the first orders come in. They are looking for a confirmation email, a charge that matches the total, a product that can actually be picked, and a customer who can reply to a human if something looks wrong.

Set a simple watch for the first hour, then the first day. How many checkouts started. How many paid. Any error in the payment log. Any page that 404s from an old link you forgot. The point is a person, not a dashboard nobody opens.

If the error rate is ugly, roll the domain back and fix it on staging. A short return to the old shop is a better story than a day of broken carts. Tell the team the condition in advance so rollback is a step, not a defeat.

The sequence, written so it can sit in the project channel, is short:

1. Staging holds the real catalog and the real templates.
2. Parity is checked, then the catalog is frozen.
3. Test payments pass, then one small live order is refunded.
4. DNS moves, with redirects and a known rollback.
5. A named person watches the first real orders and can stop the line.

What you choose to keep in the shop itself, separate from the mechanics of the move, is the earlier decision. Read what to keep in an ecommerce redesign before you treat every old page as either sacred or disposable.

Migrations of this kind are part of the shop work in Hanabi's selected work, including storefronts that had to leave an older system without losing the brand.