How a store moves platforms without going offline.

The fear that stops most migrations is not the price. It is the picture of the shop being down for a weekend while somebody sorts out the mess, with orders lost and customers landing on errors.

That picture comes from migrations run as a switch: turn the old store off, turn the new one on, deal with whatever breaks. We do not work that way. The new store is built beside the old one while the old one keeps selling, and the switch at the end is short, planned, and reversible.

The old store trades throughout.

From the first day of the project to the last, your current store takes orders exactly as it does now. Nothing we do touches it. The new store is assembled separately, on a private address only we and you can reach, so there is no window where the business is not selling.

It also means you see the new store working before you commit to it. You click through it, place test orders, and check your own products with your own eyes rather than approving a screenshot.

What you are asked to do.

Your part is smaller than most owners expect and it is concentrated at the two ends. Early on we need access and answers about how the store really works, including the parts that only exist in your head. Near the end we need you to walk the new store as a customer and tell us what is wrong, because you know your products and we do not.

Everything between those two points happens on the new store, without you, while the old one keeps taking orders.

Data comes across, then gets checked.

Products, variants, collections, customers and order history are moved and then verified against the old store. Verified is the operative word. An import that reports success is not the same as a catalogue that is correct, and the difference shows up in option names, images attached to the wrong variant, and products that quietly did not arrive.

Checking means putting the two stores side by side and comparing: counts by collection, a sample of products with every option combination, customers with order history against those without. It is unglamorous work, and it is the whole difference between a migration that is finished and one that keeps producing surprises for a month.

Redirects, URL by URL.

Every page on your current store has an address that search engines have indexed and that customers have bookmarked, linked and shared. When the structure changes, each of those addresses needs to point at its new equivalent.

We map them one by one rather than sending everything to the home page. A blanket redirect to the home page is technically a redirect and practically a dead end: the visitor who wanted a product gets a shop front and leaves, and the ranking that page had earned does not transfer with it.

Payments tested with real transactions.

Before anything goes live we run real transactions end to end: a purchase, a refund, a declined card, and the emails each of those sends. Payments is the one part of a store where finding out in production is unacceptable, so it gets tested like it matters.

The switch takes one evening.

The cutover itself happens outside trading hours and comes down to pointing the domain at the new store. It is short because everything that could take time has already been done and checked. If something unexpected appears, the old store still exists and still works.

Someone watches it afterwards.

The days after a switch are when the remaining problems surface: a redirect nobody thought of, a courier integration behaving differently under real orders, an email template still pointing at an old address. We watch the store through that period and fix what appears.

We guarantee this in writing. Not as a line in a sales conversation, as a term in the agreement: your store does not go offline and your existing URLs keep working. When you are handing someone the thing that pays your salaries, a promise you can read is worth more than a promise you were told.

The process, the guarantee and the fixed price are all on one page. See how we migrate a store.