Details in this account are generalised and figures are omitted where they would identify the client.
The situation
A specialist retailer with a catalogue in the low thousands, most sales through their own site, and a meaningful proportion of traffic arriving from search on specific product and category terms.
The existing shop ran on an ageing platform with an accumulation of plugins, some no longer maintained. Page speed had degraded steadily, checkout had a known problem on certain phones, and updates had been deferred for over a year because the last one broke the basket.
The commercial risk was clear. The risk of moving was equally clear: their search visibility was a substantial asset built over years, and replatforms are where businesses lose it.
The constraint that shaped everything
Protecting rankings was the primary requirement, ahead of design and ahead of new features.
That framing changed the project. It meant the URL mapping was the first deliverable rather than a launch-week task, and it meant several design suggestions that would have changed the site structure were declined.
What the preparation involved
A full crawl of the existing site, producing every URL that returned a page. This came to considerably more than the product count, because of filter combinations, old campaign pages and content nobody remembered.
Traffic and link data per URL. Which pages actually received search traffic, and which had inbound links from elsewhere. This identified about two hundred pages that mattered disproportionately, including several discontinued products with links from forums and review sites.
A mapping for every URL. Each old address to its equivalent, its nearest parent, or a category. Nothing to the homepage except as a last resort, because a redirect to the homepage passes almost nothing and gives the visitor no help.
Existing titles and descriptions recorded, so that anything performing well could be carried across rather than rewritten by somebody who did not know it was working.
The product data was the project
As it usually is.
The existing catalogue had accumulated inconsistencies over years: the same attribute recorded three ways, variants structured differently across categories, dimensions in mixed units, and a description field that had been used for specifications, marketing copy and internal notes depending on who entered it.
Cleaning this consumed more of the timeline than the build. It was also where the lasting benefit came from — a consistent catalogue made the new site's filtering work properly, which was not possible before.
The build was predictable. The data was not, and it set the timeline. That is the normal shape of an ecommerce migration and it is worth planning for rather than discovering.
What nearly went wrong
Two things.
The development site was blocked from search engines, correctly. That block was very nearly carried into production. It was caught during the pre-launch checks — it is on the list precisely because it is the most common serious launch mistake, and knowing that does not make anybody immune.
Structured data was initially omitted. The old site had product markup showing price and availability in search results. The new build did not, and nobody noticed until a pre-launch comparison against the old pages. Had it launched that way, the visible difference in search results would have cost clicks immediately and the cause would have been hard to identify.
Both were caught by working through a checklist rather than by anybody being clever — see the website launch checklist.
Launch and afterwards
Single cutover, mid-morning midweek, with the old site retained and reachable internally for comparison.
The 404 report was reviewed daily for the first fortnight. It found around thirty URLs that had not appeared in the original crawl — mostly old campaign pages linked from external sites. Each was redirected within a day.
Rankings moved for about three weeks and then settled. That temporary movement is normal while search engines recrawl, and knowing to expect it prevented an unnecessary panic in week two.
What we would do differently
Start the product data work earlier and separately. It could have begun months before any build decision, because a clean catalogue is valuable regardless of platform.
Test the checkout on more real devices, sooner. The old site's checkout problem on certain phones had been costing sales for some time. We should have made that a specific pre-launch test case rather than part of general testing.
The general lessons
Rankings are lost to missing redirects, not to replatforming. The URL map is the deliverable that protects the asset.
Product data determines the timeline. Profile it in week one.
Do not delete discontinued product pages.
Our ecommerce team replatforms shops for UK retailers with the redirect map as a first deliverable. Start a conversation.