In this guide 6 sections
Rebuild an e-commerce website when the platform itself, not just the design, limits conversion, integration or maintainability. Repair, extension and redesign should already have been assessed and found insufficient. A rebuild driven only by a dated look usually costs more than it returns, so audit first and release in stages.
Audit conversion, performance, maintainability and integration gaps first
Separate symptoms from causes before deciding anything. Low conversion may be checkout friction fixable in place, or it may come from a platform that cannot support the payment methods buyers now expect. Slow pages may be oversized images and unminified scripts, which need no rebuild, or an architecture already tuned as far as it will go.
Judge integration gaps by today’s needs. A site that was adequate five years ago may never have anticipated the ERP sync, the B2B price lists or the payment methods the business now depends on. Write the gaps down.
Repair, extension, redesign and full replatforming
Four options escalate in cost. Jumping straight to the most expensive option without testing the three cheaper ones is the most common and most costly mistake in this decision.
Take an eight-year-old shop on an old platform version: if the audit shows checkout is slow because of unoptimised code, repair or extension may be enough. If the platform can no longer accept a supported update and the agency that built it cannot be reached, the problem is structural. Repair cannot fix that. Replatforming moves up the list.
- Repair: fix bugs in place.
- Extend: add features to the current core.
- Redesign: new front end, same backend.
- Replatform: move everything to a new platform.
Catalogue, customer data and search-ranking migration risk
A rebuild can destroy what currently works. Three things are at stake: search rankings that depend on URL structure and careful redirect mapping, customer accounts with their order history, and catalogue attributes collected over years. Plan for each one explicitly.
Good practice lowers the risk through 301 redirects from every old URL to its closest new equivalent, and through keeping URL patterns identical wherever possible. Rankings may still move. Search performance depends on many factors outside the migration, so no rebuild should be sold on a promise of unchanged traffic or rankings.
A staged release with redirects and a rollback option
Launching a full replatform in one cutover is high-risk for any site with meaningful order volume, because one bad hour can freeze checkout, payments and fulfilment together. Start with one category. Or run the full cutover inside a low-traffic window agreed in advance, with developers, support staff and the payment contact all reachable until the first orders clear.
Test the rollback plan. Agree the exact trigger for reverting, such as checkout errors or a drop in completed orders, before launch day, because nobody decides calmly at midnight.
Business continuity after launch, not just launch day
Track conversion rate, page speed, error rates and organic traffic for several weeks after launch, and compare each against baselines captured before the switch. A rebuild can look fine on launch day and still lose organic traffic or conversion over the following month, and by then nobody connects the decline to the migration.
The earlier audit pays off here. With a recorded baseline you can state, with evidence, whether the rebuild delivered what it was meant to, instead of relying on a general feeling that things seem better. Impressions are not evidence.
Commerce rebuild decision tree
A decision tree starting from the audited symptom (conversion, performance, maintainability, integration). It routes to repair, extend, redesign or replatform, depending on whether the cause is fixable within the current platform or structural to it. It ends in a staged-release and rollback checklist for whichever path applies.
Open a blank worksheet to printQuestions owners ask
Can a redesign fix backend problems?
A redesign changes only what customers see. If the problem is a platform that cannot integrate with your ERP or handle your catalogue’s complexity, a new front end on the same backend will not resolve it. That needs extension or replatforming.
How do we protect existing search traffic?
Map every old URL to its new equivalent and add 301 redirects before launch, so search engines and bookmarked links land on the right page. Change little at once. Redirects reduce the risk without removing it, since rankings depend on factors beyond the migration itself, such as competitors, content quality and how quickly the new pages are crawled.
Is a dated design a reason to rebuild?
Rarely on its own merit. A dated look is usually solved by a redesign that keeps the existing backend, product data and customer accounts in place at far lower risk. Rebuild when the platform is the limit.