Wix vs custom — when should you migrate?

The short answer

Migrate off Wix (or Squarespace, or Framer, or any templated builder) when the site is actively losing you work — slow loads, poor search rankings, frustrating admin, features you can't get built no matter how much you ask. Stay on the platform if the site mostly does its job, you're not bleeding leads, and you're not ready to invest in a rebuild. The dangerous middle ground is "frustrated but scared to switch." That's where most small businesses waste two or three years paying platform fees on a site that's quietly costing them leads.

The decision framework

Signs it's time to leave

Any two of these in combination is enough reason to migrate. Three or more is urgent.

Mobile Lighthouse Performance score below 60. Run your site through pagespeed.web.dev. A sub-60 on mobile means Google is already deprioritising your pages in competitive searches.
You rank for your own brand name and not much else. Type your primary service + town into Google. If you're nowhere on page 1 after 12 months in business, your site isn't set up to rank — and templated builders typically can't be fixed into ranking.
Admin is slow. Making a text change takes 15 minutes of loading and page-building. Scaling up to content marketing on this is miserable.
You want a feature that the platform can't do. You've hit a structural wall. Wix added a store module, sure, but can it embed a proper quoting calculator? Handle multi-step forms? Ship valid JSON-LD for a non-standard schema type? Usually: no.
Paying more than $30/month for the platform and still not owning your schema, your DNS, or the full source of your content.
The site's been sitting at the same traffic level for 18 months. Sites with SEO potential grow. Sites without it plateau.

Signs it's fine to stay

The site takes two or three enquiries a month and you're happy with that volume. Don't spend $5,000 rebuilding to chase growth you don't need.
You're in a low-competition local market. Small-town trades with no real online competitors can rank on even a weak site — the bar is set by who else is trying.
The business itself might pivot in the next 12 months. Don't rebuild a marketing site for a business that might be rebranding or rescoping.
Budget is genuinely tight. Staying on a platform is a real choice if the capital isn't there. Acknowledge what you're losing and plan the eventual upgrade.
Your Wix/Squarespace site is genuinely well-built. It happens — a designer who knew what they were doing set it up, added schema where possible, tuned images. Those sites can ride out a couple more years.

The middle ground trap

The most common state is "it's doing okay, I don't love it, but migrating sounds scary." That's the expensive state. Every month in it, you're paying platform fees on a site that's probably losing you more than the rebuild would cost.

If you've been in this state for 12 months, the decision has effectively already been made — you just haven't acted on it.

What a migration actually involves

A proper migration is rebuild from scratch with careful preservation of what's already working.

The five-step migration

Step 1 — Audit the existing site.

Which URLs currently rank? (Pull from Google Search Console if it's connected.)
What's the current traffic level?
Which pages convert? Which are zombie pages?
What content is worth keeping, rewriting, merging, or killing?

Step 2 — Scope the new site.

Which of the existing URLs need 301 redirects to new ones?
Which pages will be kept as-is (in concept, rebuilt in implementation)?
Which new pages will the new site need that the old one lacked? (Location pages, FAQ, case studies, journal.)
Which old pages will be killed?

Step 3 — Build the new site on a dev URL.

Full build on a preview URL not yet publicly linked.
Content migrated with voice and structure preserved (or improved — this is the chance).
Full schema from day one.
Performance tuned to target.

Step 4 — The DNS cutover.

Swap the domain from old platform to new.
301 redirects set up for every URL that moved.
sitemap.xml submitted to Google Search Console (new domain or refreshed property).
Old platform account kept active for 30–60 days as fallback, then cancelled.

Step 5 — Monitor for 90 days.

Watch Google Search Console for crawl errors, dropped URLs, ranking movements.
Expect a 10–30% ranking dip for the first 2–4 weeks — Google is reindexing. It recovers if the redirects are right.
If rankings haven't recovered within 8 weeks, diagnose (usually redirect gaps, schema issues, or content shifts that matter more than expected).

The redirect map

This is the step that most migrations mess up. Every URL that existed on the old site and had any organic traffic must have a 301 redirect to the new equivalent.

Examples:

Old: /services/plumbing-tweed-heads → New: /areas/tweed-heads/plumbing (301)
Old: /blog/winter-maintenance-tips → New: /journal/winter-maintenance-tips (301)
Old: /team → New: /about (301, because the new site doesn't have a team page)

Missing even a handful of redirects in the first two weeks can cost a month of lost rankings while Google re-crawls. A migration without a redirect map is worse than no migration — you're actively destroying accrued ranking equity.

What to preserve from the old site

Brand recognition. Don't rebrand in the same pass. One change at a time.
High-performing content. Pages that ranked and converted should be rebuilt with the same core message, improved structure.
Internal links. The new site should preserve or improve the internal-linking graph.
Schema signals built up over time. sameAs references to social profiles, entity linkages, awards — all carry over.

What to leave behind

Zombie pages. Pages with no traffic, no conversions, no inbound links. Kill them, let the 404s reindex naturally (or redirect to the closest relevant page).
Auto-generated blog posts from 2021 that nobody reads. Cull.
Outdated copy. The migration is the chance to rewrite.
Any schema invention. If the old site had fake review schema, fake opening hours, or any other non-compliant markup, leave it behind.

How long does migration take?

For a small-business site:

Simple (5–10 pages, one service, one location): 3–4 weeks.
Standard (10–20 pages, 2–3 services, 5–8 locations, blog): 4–6 weeks. Most Vellero builds sit here.
Complex (20+ pages, rich integrations, significant existing content): 6–10 weeks.

DNS cutover itself is a single day. The weeks are the build, the content migration, and the careful redirect-map setup.

The ranking risk

Every migration carries a ranking risk. Done well, the dip is typically 10–30% for two to four weeks, then recovery. Done badly, the dip can run 40–60% for two to three months, and full recovery can take half a year. The variance is almost entirely about execution, not the platforms involved.

The difference between "done well" and "done badly" is almost entirely:

Redirect map completeness.
Preserved internal-linking structure.
Content structure preservation (H1/H2s don't reshuffle if they were ranking).
Schema continuity.
Page-performance improvement (a faster new site recovers faster).

A designer who can't walk you through this framework shouldn't be running your migration.

The Vellero migration approach

When Vellero migrates an existing site:

Full audit of existing URLs, traffic, and rankings (Search Console pull)
Redirect map built as part of scope, before the build starts
Content rewritten to voice, preserving high-ranking structure
DNS cutover scheduled for a low-traffic day (usually a Sunday evening)
First 90 days' Search Console monitoring included in the care plan

Migration builds are priced the same as new builds — $4,000 to $8,000 range — because the work of a proper migration is equivalent to a new build plus careful redirect scoping. The savings of "we already have content" are offset by the work of preserving what was working.