Keeping your design when you migrate

The mistake that produces an almost-right rebuild is starting from pages. Someone opens the homepage, eyeballs it, and rebuilds it — then does the same for the product page, with slightly different spacing. Six templates later the site is subtly inconsistent in a way nobody can point at. The method that works starts with the system: extract the type scale, the spacing rhythm, the colour values, the border radii, the shadow definitions and the breakpoints, and encode them as tokens before building a single template. Every component then references the tokens rather than a designer's memory. If a rebuild starts from page screenshots instead, do not accept it: past about six templates the inconsistencies are unfixable without redoing the work. This is also what makes the result maintainable — a store that cannot change its accent colour in one place did not get a design system, it got a copy.

"Does it look the same?" is not a question you should be answering by scrolling. Set up visual regression testing: capture the old storefront at three viewport widths across your ten highest-traffic templates, capture the new one at the same widths, and diff them. The differences become a list rather than an argument, and each item gets a decision — fix, or accept and record why. Skip the second run and the check is not worth doing, because the class of problem that only appears with real data is exactly what staging hides: the product title that wraps to three lines, the category with one item in the grid, the review section with no reviews.

• Capture at mobile, tablet and desktop widths for the top ten templates
• Diff against the old storefront and turn differences into a tracked list
• Re-run after launch with live data, not staging fixtures
• Test the empty and overflow states — one-item grids, long titles, no reviews

Web font licences are frequently scoped to a domain, a pageview volume, or a specific hosting arrangement, and a migration can quietly breach all three. A font bought for the old site may not cover the new one; a font loaded through a service tied to your old platform stops working when that platform goes; a licence priced on monthly pageviews may need upgrading if the new store is faster and gets crawled harder. Check this in week one, because discovering it in launch week means either a rushed licence purchase or shipping a fallback that makes every page look subtly wrong. Where the licence cannot be carried, choose the replacement early and put it through the visual diff. Swapping a typeface the night before launch is how a brand arrives looking subtly wrong.

Three things routinely survive a migration because nobody questioned them, and each one costs money. A mega menu with 200 links, which exists because the category tree was never pruned and which no phone user has ever successfully navigated. Homepage carousels come next. Measurement almost always shows engagement collapsing after the first slide, so rebuilding four slides faithfully means rebuilding three nobody sees. And colour combinations that fail contrast requirements, which are both an accessibility exposure and a conversion problem on a phone in daylight. An element nobody has measured has not earned a faithful copy. Reproducing it preserves the design's mistakes rather than its value.

Ask for faithful rather than identical, and understand what you are trading. Identical means reproducing every element exactly as rendered, including the ones that only look that way because of a builder's markup quirks — and it costs more while sometimes carrying performance problems across with it. Faithful means the design system, the visual hierarchy and the brand read as unchanged to a customer, while the underlying markup is rebuilt properly. On a product page a customer will not notice four pixels of padding. They will notice the layout shifting while an image loads, and that is the kind of fidelity worth paying for. Where the two conflict, we choose faithful and document it — but a store rebranding at the same time should say so up front, because that is a different project with a different brief.

Animations are where estimates go wrong: invisible in a screenshot, usually absent from the brief. Scroll reveals, hover states, page transitions, sticky behaviours, drawer timings, gallery gestures on touch — each needs a rebuild or an explicit decision to drop it. List them before development, and two things fall out: a handful nobody wants, and one or two that turn out to be load-bearing.

If the current site was built from a theme demo and nobody ever adapted it, there is no design to preserve and pretending otherwise wastes budget — start from the brand instead. If the store is planning a rebrand within the year, reproducing the outgoing design is money spent twice, and the honest sequence is to do the rebrand first or accept a temporary look. And if the design predates mobile-first thinking badly enough that the phone experience is a scaled-down desktop, faithful reproduction preserves the reason mobile conversion is bad. In that case say so plainly and quote a redesign, not a migration.