Migration
Move a live platform without a bad weekend
Big bang cutovers fail for the same reason every time: the first moment anyone finds out whether it works is the moment there is no way back. We move traffic incrementally, keep the old platform warm, and prove the rollback before we need it.
- Traffic routed by market, by route or by percentage, so the blast radius is always small
- Shadow traffic against the new platform for weeks before any real customer sees it
- Complete URL map with redirects shipped in the same release as the change
- Data migrated with reconciliation reports for catalogue, customers, orders and vouchers
- Rollback rehearsed and timed, with the decision criteria written down in advance
Cutover
Four stages, each one reversible
Incremental cutover with traffic splitting
Figure 09 / migration planFigure 09. Typical shape for a multi market retailer. Single market clients usually split by route instead, moving category pages first and checkout last.
Search visibility
Migrating URLs without losing rankings
Organic traffic is usually the largest single channel and the easiest one to destroy in a replatform. It is treated as a delivery work package with its own owner and its own acceptance criteria.
| Step | What we do | Evidence produced |
|---|---|---|
| Inventory | Full crawl of the live site plus log file analysis and Search Console export, so we map what is actually indexed and actually earning traffic | URL inventory with traffic, revenue and crawl frequency per URL |
| Mapping | Every old URL mapped to exactly one new URL. Anything that cannot map gets an explicit decision rather than a default to the home page | Signed off redirect map, including parameter and pagination rules |
| Parity | Titles, meta descriptions, headings, internal links, structured data and hreflang checked template by template against the old site | Template parity report with differences and the reason for each |
| Release | Redirects ship in the same release as the cutover, at the edge, with a single hop and no chains | Redirect test suite that runs on every deploy |
| Monitoring | Index coverage, crawl errors, rankings and organic revenue watched daily for eight weeks, with a named owner | Weekly written report and an alert threshold that triggers a rollback conversation |
Table 07. Across our last five migrations the median ranking change eight weeks after cutover was zero positions, and the worst case was a loss of two positions on one template that recovered inside six weeks.
Managed support
Then we run it
Most agencies leave at go live, which is exactly when the platform starts to matter. Our run service uses the same engineers who built the system, with a service level you can enforce and a monthly engineering budget so the platform keeps improving.
- Named engineers, not a shared ticket queue with a rotating cast
- 24/7 monitoring on business metrics, not just infrastructure metrics
- Monthly engineering budget for improvements, carried over for one month if unused
- Quarterly platform review covering cost, performance, security and technical debt
- Annual peak readiness programme before your trading season
| Priority | Definition | Response | Workaround target | Communication |
|---|---|---|---|---|
| P1 | Customers cannot buy, or data is at risk | 15 minutes, 24/7 | 2 hours | Bridge opened, update every 30 minutes |
| P2 | A major journey is degraded but revenue continues | 1 hour in business hours | 8 hours | Update every 2 hours |
| P3 | A defect with a workaround | 1 business day | Next release | Daily on the board |
| P4 | Cosmetic or low impact | 3 business days | Backlog | Monthly report |
Table 08. Every P1 gets a written blameless post incident review inside five working days, with actions tracked to closure on the same board as feature work.
Next step
Tell us what is slowing your commerce platform down
Send the brief. A principal architect reads it, then you get a written technical assessment with options, effort and risk inside five working days. No sales call required first.