Redesign, Migration, or Both? Deciding What You Actually Need

"We need a new website" usually means one of three different projects wearing the same sentence. Untangling them matters, because they carry different costs, different risks, and, when combined carelessly, they multiply each other's failure modes.

The three projects hiding in one sentence#

A redesign changes how the site looks and reads: layout, typography, imagery, copy. The platform and the URLs can stay put.

A migration changes where the site lives: Wix to WordPress, Wix to Shopify. The design can, in principle, be reproduced as-is.

A restructure changes what the site is: new pages, merged pages, new navigation, new URL architecture. This one is the sleeper, it is the piece that actually endangers rankings, and it can sneak into either of the other two.

Most "new website" projects are some blend. The question is which blend, and in what order.

Why "everything at once" is the risky default#

When you change design, platform and structure simultaneously, you also destroy your ability to diagnose problems. Traffic drops six weeks later, was it the lost URLs? The rewritten copy? The new page structure? The slower theme? You changed every variable at once, so the data cannot tell you.

Google is also re-evaluating more at once. A moved page that looks identical is an easy equivalence for a search engine to accept: same title, same content, new address, 301 between them. A moved page that is also rewritten, retitled and merged with two other pages is a genuinely new page that happens to claim ancestry. Some equity transfers; some does not.

None of this means "never do both". It means both-at-once is a decision to make with open eyes, not a default to fall into because the projects share an invoice.

When migration alone is the right call#

• Your traffic and rankings are meaningfully valuable right now.
• The design is serviceable, dated maybe, but not broken.
• The motive is escaping the platform: costs, lock-in, missing features.

Move like-for-like: same content, same structure, reproduced design, complete redirect map. This is the lowest-risk migration there is, because the only variable that changes is the address, and 301s exist precisely to handle that variable.

A bonus most people do not expect: the same content on a faster, cleaner platform often improves Core Web Vitals on its own. You get a modest technical uplift without touching a single headline.

When redesign-during-migration makes sense#

Since a Wix exit is a rebuild anyway. Wix exports nothing, every page is being reconstructed regardless. Reconstructing it better costs little extra, which is why "refresh while we move" is often sensible:

• The current design is actively hurting you (mobile-broken, illegibly dated, untrustworthy for your price point).
• Your traffic is modest, so there is less equity at stake and less diagnostic value to protect.
• You can hold the line on the one rule that matters: refresh the shell, preserve the substance. New layout, new typography, new imagery, same URLs where possible, same titles, same heading structure, same content covering the same searches.

That last constraint is the difference between a refresh and a restructure. A migration can absorb a refresh safely. A restructure is its own project.

If you genuinely need everything#

Sometimes the honest answer is: wrong platform, dated design, and a site structure that no longer matches the business. Then sequence it:

Step one, migrate with the refresh. New platform, refreshed design, structure preserved, full redirect map. Wait for rankings to stabilise (four to eight weeks of quiet Search Console).

Step two, restructure deliberately. Merge pages, build new sections, retire old ones, now with per-page before/after data, on a platform where you control redirects natively, one change set at a time.

Two smaller projects, each diagnosable, each reversible. The combined cost is barely more than the big bang; the risk is a fraction of it.

The short version#

Redesign changes how it looks; migration changes where it lives; restructure changes what it is. Migration plus a design refresh is a safe pairing if URLs and content substance hold still. Restructuring is the risky ingredient, give it its own project, after the move has proven itself. And if someone proposes changing everything at once, ask them one question: when traffic moves afterwards, how will we know why?