Process
How a migration
actually runs
The plan that stops it falling over is the proof that it will not. This page is the runbook, published rather than described.
It exists because a buyer at this size is not choosing between features. They are asking whether the person doing it has done it before, and whether there is a plan for the night it goes wrong.
The shape of the work
Twelve to sixteen weeks is typical for a migration of this kind. The variables that move it are catalogue complexity and the number of systems being integrated — not catalogue size, which matters less than people expect. These are stages rather than a promised calendar, and the proposal carries the dated version.
Weeks 1–2 · Discovery
Read the existing store rather than interview it: the extension list against what is load-bearing, the custom code, the integrations, the analytics and the backlink profile. Output is the scope, the URL inventory and the risk list — the three things everything later depends on.
Weeks 2–3 · The URL map
Built here, at the start, not at the end. Every current URL, its inbound links and its destination on the new structure, as a document the merchant holds. It is written early because it constrains the build — the information architecture has to serve it, and discovering that in week ten is expensive.
Weeks 3–9 · Build and data
Storefront, checkout and the rebuilt logic, alongside repeated trial data migrations. The data is migrated many times, not once — each pass is reconciled and the delta shrinks, so that the final run on cutover day is rehearsed rather than attempted.
Weeks 9–11 · Integration and UAT
Systems connected against the staging store and run with real order flow. The merchant's own team tests the processes they will actually perform, because the faults that matter are found by the person who does the job daily, not by the person who built it.
Week 12 · Cutover
The runbook below, executed. Scheduled at the operation's quietest hours and never immediately before a peak trading period or a bank holiday.
Weeks 12–16 · Post-launch
Redirect verification against live crawl data, index monitoring, sync observation under real volume, and the defect list worked down. Thirty days of this is in scope as standard.
What genuinely cannot come across
Products, customers and order history migrate. Four things do not, and each is better known in week one than discovered in week eleven.
Password hashes
Customers cannot be moved with their passwords intact. They will be asked to reset, and how that is communicated is a commercial decision worth making deliberately rather than letting it happen as a surprise email.
Stored payment methods and live subscriptions
Card tokens belong to the old gateway. Where subscriptions exist, the billing relationship is the merchant's to re-establish, and it is the single largest risk in any migration that has them.
Historic analytics continuity
The data survives in the old property; the continuous series does not. Annotate the cutover date and keep the old view rather than pretending the numbers are comparable across it.
Reviews, where the app is proprietary
Often exportable, sometimes not, and worth checking in discovery because the answer occasionally decides which review app is chosen on the new store.
The cutover, hour by hour
A representative runbook. The real one is written for the specific store, rehearsed against staging, and in the merchant's hands before the day.
T-7 days. Go/no-go criteria agreed in writing. DNS TTL lowered so the switch propagates in minutes rather than hours — the single most commonly forgotten preparation step.
T-1 day. Final rehearsal on staging. Rollback plan confirmed. Everyone who will be awake knows what they are watching and who they call.
T-0, hour 0. Old store to maintenance mode. Final delta migration of orders and customers placed since the last pass.
Hour 1. Reconciliation: counts and totals compared old against new, and a sample of records checked by hand. This gate is passed before anything is pointed at the public.
Hour 2. DNS switched. Redirects verified against the URL map — automated across the full list, then spot-checked on the highest-value pages. SSL confirmed.
Hour 3. Live transaction tests: a real order through each payment method, each shipping option, and each channel. Integrations confirmed writing in both directions.
Hours 4–8. Watch. Error rates, checkout completion, sync queues, support inbox. Most cutover faults surface inside the first four hours of real traffic and nowhere else.
T+1 day. Sitemap submitted, index coverage monitored, full redirect crawl against the live site, first reconciliation of the day's orders end to end.
Rollback, and the go/no-go gate
The old store stays intact and deployable throughout. Rollback is a DNS change, which is why the TTL was lowered a week earlier — the plan is not "restore from backup", it is "point back at the store that is still standing".
The window in which rollback is clean is bounded, and it closes when orders have been taken on the new store, because those orders exist in only one place. That boundary is stated up front, and it is the reason the reconciliation gate sits before the DNS switch rather than after it.
Critical — these stop the cutover: data reconciliation failing, any payment method not completing a live transaction, the redirect map not verifying, stock sync not writing in both directions, or SSL not resolving on the primary domain.
Cosmetic — these do not: visual defects on secondary pages, minor copy errors, non-critical app configuration, anything fixable forward inside the support window without affecting an order or a ranking.
The distinction is agreed in writing at T-7 rather than argued about at 3am, which is the entire point of writing it down.
Tell us what is breaking
What the systems are doing now, and what you need them to do. We will tell you whether it is a platform problem or something cheaper.