Process
How a migration
runs
Every migration runs to a written runbook: the stages, what can't come across, the cutover hour by hour, and the gate that decides whether it goes ahead.
It's written for your store, rehearsed against staging, and in your hands before the day.
The shape of the work
Twelve to sixteen weeks is typical for a migration of this kind. Catalogue complexity and the number of systems being integrated move it more than catalogue size does. 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's 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 at the start. Every current URL, its inbound links and its destination on the new structure, as a document you hold. It comes early because it constrains the build: the information architecture has to serve it, and finding that out 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. Each pass is reconciled and the delta shrinks, so the final run on cutover day has been rehearsed.
Weeks 9–11 · Integration and UAT
Systems connected against the staging store and run with real order flow. Your own team tests the processes they'll perform, because the person who does the job daily finds the faults that matter.
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 doesn't come across
Products, customers and order history migrate. Four things don't, and each is better known in week one than found in week eleven.
Password hashes
Customers can't be moved with their passwords intact. They'll be asked to reset, and how that's communicated is a commercial decision to make deliberately, before it arrives as a surprise email.
Stored payment methods and live subscriptions
Card tokens belong to the old gateway. Where subscriptions exist, the billing relationship is yours to re-establish, and it's the largest risk in any migration that has them.
Historic analytics continuity
The data survives in the old property; the continuous series doesn't. Annotate the cutover date and keep the old view rather than treating the numbers as comparable across it.
Reviews, where the app is proprietary
Often exportable, sometimes not. We check in discovery, because the answer can decide which review app the new store uses.
The cutover, hour by hour
A representative runbook. The real one is written for the specific store, rehearsed against staging, and in your 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.
T-1 day. Final rehearsal on staging. Rollback plan confirmed. Everyone who will be awake knows what they're 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. The first hours of real traffic are when cutover faults surface.
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 to point back at the store that's still standing, rather than restore from backup.
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's 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 don't: 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, so it isn't argued about at 3am.
Tell us what you need
What the systems are doing now, and what you need them to do. We'll tell you whether it's a platform problem or something cheaper.