Risk
What fails, and
who you ring at 2am
Every migration page describes the happy path. This one describes the other one, because that is the question actually being asked.
Nothing here is hypothetical for its own sake. These are the failures that recur, and the ones worth planning around before rather than after.
What actually recurs, worst first
1 · Subscription and stored-payment breakage
The most expensive failure available, and the least reversible. Card tokens belong to the old gateway, so recurring billing has to be re-established rather than moved. Handled badly it costs a proportion of the subscriber base permanently. This is why any store with subscriptions gets that treated as the primary workstream rather than a migration detail.
2 · Redirect gaps on high-authority URLs
Not the volume of misses but which ones. A handful of missed URLs carrying most of the inbound links costs more than a thousand missed long-tail pages. Caught by crawling the live site against the URL map after cutover, not by trusting that the map was applied.
3 · Stock sync failing quietly
A sync that stops is noticed. A sync running behind is not, and it oversells for a day before anyone connects the cancellations to it. Caught by alerting on queue depth and sync age rather than on errors — the failure mode has no error.
4 · Tax and shipping edge cases
The 95% path is configured and tested. The remainder — one region, one product class, one customer group — surfaces days later as a margin problem rather than a visible fault. Caught by testing the exceptions deliberately, because they will not appear in normal traffic during UAT.
5 · The process nobody mentioned
A weekly export somebody in accounts has run for six years, a label format the warehouse depends on, a report that feeds a supplier. Invisible in discovery because it is nobody's project. Caught only by asking the people who do the work what they do all day — which is why UAT is run by the merchant's team and not demonstrated to them.
Rankings after a replatform — the honest version
Search visibility moves after a migration. Anyone promising it will not is either not doing the work or not watching afterwards. What can be controlled is how far it moves and how quickly it comes back.
The mechanism is straightforward: Google has to recrawl and reprocess the new structure, and until it does, rankings reflect a site that has changed shape.
The honest ceiling: a well-executed migration is a recovery job, not an uplift one. If the pitch is "replatform and rank better", the ranking gain is coming from the content and technical work done alongside the move, not from the move itself — and that should be quoted and measured separately so nobody is confused about which one worked.
A dip, then a recovery
- A clean redirect map
- Content unchanged through the move
- Internal linking preserved
A loss
- Missing redirects
- Thinner content on the new store
- A structure that abandons the old hierarchy
Who answers, and what is covered
Who. Tony Cooper, directly, for the duration of the engagement — not a ticket queue and not an account manager relaying to someone else. Where a subcontractor built the failing component they are brought in, but the merchant's call goes to one place and stays there.
When. Cutover night and the days either side are staffed deliberately, and the specific windows and response times are written into the engagement contract rather than published here as a generic promise. A merchant should be able to point at a clause, not at a marketing page.
Insurance, stated precisely. StoreBuilder Ltd holds public and products liability cover. Professional indemnity sized to five-figure delivery work is a condition of contracting rather than something already in force: no PI limit is claimed on this page, and confirmed cover — certificate and limit — is provided before any engagement is signed, rather than being something a client should have to ask for.
And what insurance does not do. No policy gives back a fortnight's trading. Cover matters after the worst has happened; the rehearsal, the reconciliation gate and the rollback plan are what stop it happening. Anyone selling the certificate as the reassurance has the order backwards.
The failures that are yours, not ours
Said plainly, because a supplier who never names these is a supplier who will be surprised by them.
Decisions arriving late. A migration has a critical path and design or data decisions sit on it. Two weeks to approve a structure is two weeks on the end date, and no amount of effort at the other end recovers it.
UAT delegated back. Testing has to be done by the people who will use the system. When it is handed back to the supplier to "just check", the processes nobody mentioned stay unmentioned until they fail in production.
Access and third parties. Registrar credentials, gateway accounts, the ERP vendor's cooperation. Where a third party has to act, their timeline is real and outside everyone's control — which is why they are contacted in week one, not week ten.
Scope added quietly. "While we're in there" is the most expensive phrase in a migration. Every addition is welcome and gets a written change and a revised date, because absorbing them silently is how a plan stops being a plan.
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.