Risk
The risks, and how
each one is handled
A migration carries a known set of risks. Each one below is planned for before the cutover, with the check that catches it named in advance.
One person is accountable for all of them, and he is named at the foot of the page.
What 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 part of the subscriber base permanently, so any store with subscriptions gets it treated as the primary workstream rather than a migration detail.
2 · Redirect gaps on high-authority URLs
Which URLs are missed matters more than how many. 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 gets noticed. A sync running behind doesn't, 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 won't 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's nobody's project. Caught only by asking the people who do the work what they do all day, which is why your team runs UAT rather than watching a demonstration of it.
Rankings after a replatform
Search visibility moves after a migration. What can be controlled is how far it moves and how quickly it comes back.
The mechanism is simple: Google has to recrawl and reprocess the new structure, and until it does, rankings reflect a site that has changed shape.
The limit: 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. We quote and measure that separately, so it's clear 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 or an account manager relaying to someone else. Where a subcontractor built the failing component, they're brought in, but your 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. You should be able to point at a clause, not at a marketing page.
Insurance. StoreBuilder Ltd holds £1m professional indemnity with AXA, alongside public and products liability cover. The certificate is available on request before you sign.
And what insurance doesn't 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.
What your side owns
Decisions arriving late. A migration has a critical path, and design and 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're 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 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.