How to migrate website builder software
The switching cost nobody prices in: your design never exports — it is proprietary and rebuilt from scratch — your content transfers only in fragments, and the real damage is the rankings you lose the day your old URLs start returning 404s. What actually moves, the redirect map that protects your traffic, and the DNS cutover that avoids downtime.
The content moves; the design and the rankings don’t
Every website-builder switch is sold as a lift-and-shift. It is not. The design — templates, layouts, styling, animations — is proprietary to Wix, Squarespace, Webflow, Framer or Shopify and does not export in any form that another builder can read. You rebuild it by hand. What actually moves is raw content, and even that transfers unevenly: WordPress gives you a full WXR file, Squarespace a partial WordPress-format export, and Wix almost nothing at all, so you copy pages manually. Images usually come down and go back up one by one, shedding alt text on the way.
The part that bites hardest is invisible until traffic craters: search rankings are attached to URLs, and every builder structures URLs differently. Move without a 301 redirect from each old URL to its new home and the equity you built over years 404s overnight. Add the connected pieces — forms, analytics, payment and e-commerce apps, and the DNS and MX records that route your domain and email — and it is clear this is a rebuild-and-repoint project, not a copy. Sequence it deliberately, and anchor the new-platform choice to how to choose website builder software.
The five phases of a website builder migration
Run a crawler (Screaming Frog or the free equivalent) to capture every live URL, page title and meta description — this list becomes your redirect map later, so it is the most important artifact of the whole project. Then inventory blog posts, images, forms, and every connected app: analytics, payment, e-commerce, booking, email capture. Finally, document current DNS: nameservers, A/CNAME records, and the MX records that route your email. You cannot protect what you have not written down.
Pull whatever export the source offers: a WordPress WXR file, Squarespace's partial WordPress export, or a manual copy from Wix. Download all images to a local folder and record their alt text. If you run a store, export the product catalog, customers and orders to CSV — Shopify does this well, most builders less so. Then set expectations: none of this recreates your layout. The export is raw text and media; the design is a rebuild.
Build the new site fully on a staging domain or subdomain while the live site keeps serving traffic. Reconstruct the design, re-import content, and re-enter page titles, meta descriptions and image alt text as you go. Then reinstall and re-authorise every integration — analytics, Search Console, payment gateway, e-commerce, forms, email capture — because none of them carry over. Nothing goes live until the staging site is complete and every form and checkout has been tested end to end.
Take the crawl from Phase 1 and map every old URL to its new equivalent with a 301 redirect — this is the step that decides whether you keep your rankings or lose them. Match the URL structure where you can, and where the new builder forces a different pattern, redirect explicitly rather than letting pages 404. Preserve titles and meta, keep the same H1s, and prepare a fresh XML sitemap. Confirm the redirects work on staging before cutover, not after.
Repoint DNS — nameservers or A/CNAME records — at the new host during a low-traffic window, keeping MX records exactly as they were so email keeps flowing. Keep the old plan active until propagation completes so there is no downtime. Then submit the new sitemap in Search Console and watch it hard for a full month: crawl errors, 404 spikes, and ranking movement on your top pages. The first month is when a missed redirect shows up as lost traffic, and when catching it early still saves the position.
The export gotchas, named
No — and this is the single biggest misunderstanding about website builder migrations. The design, layout, templates and styling on Wix, Squarespace, Webflow, Framer or Shopify are proprietary and locked to that platform. There is no export that recreates your site's look on another builder; you rebuild the design from scratch. What you can move is the raw content — text, images and blog posts — and even that transfers only partially. Plan the switch as a rebuild, not a copy, and budget the bulk of the effort for reconstructing the design on the new platform.
Partially, and it depends entirely on the source. WordPress exports a full WXR file with posts, pages and media references. Squarespace exports a partial WordPress-format file that carries blog posts and basic pages but drops most page layouts. Wix has almost no meaningful export, so you copy content by hand. Images usually have to be re-downloaded and re-uploaded, losing their alt text unless you carry it deliberately. Whatever the source, treat the export as raw text and media only — never as a working site — and re-enter metadata as you rebuild.
You will if you skip the redirect map — this is where site migrations quietly destroy traffic. Every builder structures URLs differently, so on cutover your old URLs 404 and the rankings attached to them evaporate. The fix is non-negotiable: crawl and list every live URL before you move, and map a 301 redirect from each old URL to its new equivalent. Preserve page titles and meta descriptions, keep the same H1s, submit a fresh sitemap, and watch Search Console for crawl errors for at least a month.
The domain stays yours; you just repoint it. Migration means changing DNS — nameservers or A/CNAME records — to aim the domain at the new host, and there is a propagation window where getting it wrong means downtime. The trap is email: if your mailboxes are tied to the domain through the old builder, moving the domain can break email unless you preserve the MX records exactly. Document your current DNS and MX records before touching anything, change records at a low-traffic hour, and keep the old plan active until propagation completes.
Always build in parallel — it is the whole point. A small brochure site is one to two weeks; a content-heavy site with a blog archive, forms and connected apps is three to six weeks; a store with a product catalog, orders and payment integrations is longer. Build the new site fully on a staging domain or subdomain, rebuild the design, re-connect every app, test forms and checkout, and only flip DNS on a fixed date once the redirect map is ready. Never take the old site down before the new one is live and the redirects are in place.
One email when the rankings move. The shortlist, the tradeoffs, the price changes. No filler.