How to switch website builders without dropping anything

People switch website builders for four reasons, and only one of them is design. The other three are money, a feature the current platform will not add, and the slow realization that the thing they are paying for every month is holding content hostage. Whichever reason brought you here, the mechanics are the same, and they are not the mechanics the marketing pages describe. There is no button. There is an inventory, a file or two, a spreadsheet of URLs, a week of quiet rebuilding, and one nervous afternoon when you point the domain somewhere new.

This page is the order of operations. Follow it and the worst thing that happens is a fortnight of wobbly rankings. Skip the middle of it and you can lose a decade of links, your business mailbox, or a checkout that customers were mid-purchase on.

First, work out whether you are moving or rebuilding

Two different jobs get called migration, and confusing them is the single most expensive mistake in this whole exercise.

A move is when a file comes out of one platform and goes into another. Squarespace writes a WordPress-format XML file; WordPress reads it. That is a move. It is imperfect, but the text and the structure travel.

A rebuild is when a human opens two browser windows and retypes the site. Nothing comes out as a file, so nothing goes in as one. Wix to Squarespace is a rebuild. GoDaddy’s builder to anywhere is a rebuild. Most builder-to-builder changes are rebuilds, because the two companies have no reason to make leaving easy and no shared format to make it possible.

Neither is shameful, and a rebuild is often better — you drop the pages nobody visits and fix the navigation you have hated for two years. But a rebuild takes ten to forty hours depending on page count, and if you have scheduled one afternoon because a comparison article used the word seamless, you will be halfway through with a half-live site and a domain pointing at nothing.

Decide which one you are doing before you cancel anything. We wrote out the full reckoning in rebuild or migrate, including how to estimate the hours honestly.

Take the inventory before you touch anything

Every move starts with a list, and the list has five columns: what it is, where it lives now, where it will live, who can recreate it, and whether it can be exported at all.

• Pages. Every URL, including the ones not in your navigation — old landing pages, thank-you pages, anything you once sent an email blast to.
• Blog posts. Titles, dates, authors, and their exact URLs. Dates matter more than people expect: an import that resets every post to today’s date destroys your archive.
• Products. SKUs, variants, prices, images, inventory counts, and any digital downloads, which almost never export.
• Forms and their submissions. Form definitions never migrate. Past submissions usually can be exported as CSV, and usually only from the platform you are leaving.
• Everything connected to the domain. Email, subdomains, verification records, anything with a DNS entry. This is the column people forget, and it is the one that takes a business offline.

Forms, members, bookings, reviews and custom code are in none of those exports and rarely in anybody’s plan either — the parts that never migrate covers each one. Do this as a spreadsheet, not as a mental note. It becomes your redirect map, your rebuild checklist and your post-launch test plan, and you only have to write it once. The full template is in the moving-day checklist.

What each builder actually lets you take out

Here is where the marketing and the reality diverge hardest. “Your content is yours” is true in the legal sense and often meaningless in the practical one. What matters is whether there is a file, what is in it, and whether anything on the other end can read it.

Every one of those platforms also has some kind of redirect panel of its own — Squarespace calls it URL Mappings, Shopify calls it URL Redirects, Wix calls it the URL Redirect Manager — and none of them will help you here, for a reason set out two sections below. Three of the rows deserve spelling out, because they are the ones that surprise people.

Wix does not export your site. Its own help centre states plainly that it is not currently possible to export blog posts to other platforms. There is a blog RSS feed, and it is genuinely useful, but Wix documents it as showing up to twenty of the most recent posts — so for anything with an archive it is a sample, not an export. Products, orders and contacts do come out as CSV. Pages do not come out at all.

Squarespace’s export is real but narrow. You get one .xml file in WordPress format. Squarespace documents that it carries layout pages, one blog page including its posts, and text and image blocks — and that album, cover, index, info, calendar, portfolio and store pages do not export, along with drafts, style settings and custom CSS. If you run two blogs, one of them is not coming. Images are not exported in bulk either; the importer on the other end fetches them from your live site, which is why you do not cancel the old plan on day one.

GoDaddy’s builder has no export at all. Not a limited one — none. Every third-party guide to leaving it describes the same manual copying, because there is nothing else to describe. If you are on it, plan a rebuild and budget accordingly.

We kept the longer version of this inventory, platform by platform, in the builders with no way out.

The URL map is the step people skip and regret

If your site has any search traffic at all, this is the most valuable hour of the entire project, and it happens before you build anything.

Every platform imposes its own URL shapes. Shopify insists on /products/, /collections/, /pages/ and /blogs/ prefixes. WordPress lets you choose but defaults to something with a date in it. Squarespace has its own conventions per collection type. Your old URLs will not survive contact with the new platform, which means every link anyone ever built to you is pointing at a page that is about to stop existing.

The fix is a two-column spreadsheet: old path, new path. Build it from the inventory you already made. Then, on the new platform, create a 301 redirect for every row before you send any traffic. Squarespace has a URL Mappings panel that takes /old -> /new 301 one rule per line. Shopify has URL Redirects with a CSV import — with the wrinkle that it only redirects URLs that currently return an error, which on a brand-new store is conveniently all of them. WordPress needs a plugin or a server rule.

One thing that catches people: the redirect panel on the platform you are leaving stops mattering the moment the domain points elsewhere. Redirects have to exist on the receiving end. Setting them up on the old builder the night before feels productive and achieves nothing.

The procedure, including how to pull a URL list without crawling software, is in build the redirect map.

Build the new site while the old one is still live

Never take the old site down to build the new one. Every platform on this list gives you a way to work privately — a trial, a password-protected site, a staging domain — and the overlap costs you one month of double subscription at most.

The destinations most people are choosing between at this stage are Squarespace, Shopify if there is a store involved, WordPress if portability is the reason you are leaving, and Wix if you are coming the other way. Start the trial, and work on a temporary address. Rebuild or import the pages. Load the products. Set up the forms again from scratch, because they will not have come across. Enter every redirect from your map. Then click through the whole thing on a phone, because that is where broken rebuilds show up first.

Only when the new site is genuinely finished do you touch the domain. And only after the domain has moved and settled do you cancel the old plan — not before, because the old site is still where your images are being fetched from and still where you will look things up when you discover something missing. Run both sites in parallel covers the overlap window and the order of cancellations.

Cutover day: domain, DNS, and the mailbox nobody remembered

Two separate things are often confused here. Transferring a domain moves its registration to a different registrar. Pointing a domain leaves the registration where it is and changes the records so it resolves somewhere new. You only need the second one to launch. Transfers can wait, and sometimes they have to — ICANN’s sixty-day lock applies after a registration, a transfer or a change of contact details, and no registrar can wave it away.

The mechanics of the switch itself are unglamorous. Lower the TTL on the relevant DNS records a day or two ahead so caches expire quickly. Make the change. Wait. Verify from a network that has never visited your site.

The genuine danger is email. If mail for your domain is delivered through MX records that your old builder created, replacing the whole record set in one go takes your mailboxes down with the website. Copy your existing MX records — and any TXT records for verification or mail authentication — before you change anything, and re-enter them on the new side. This is the failure that turns a quiet Tuesday into a very loud one. The DNS cutover walks the whole sequence.

The first thirty days on the new platform

Rankings wobble after a platform change. That is normal and it is not a reason to panic or to undo anything. What matters is that the wobble has a floor and a recovery, which it does when the redirects are right and does not when they are not.

In the first week: re-submit your sitemap, spot-check twenty old URLs and confirm each one lands on the right new page with a 301, and watch your error reports for paths you missed. If you also changed domain — not just platform — Google’s Change of Address tool is the right instrument, but note its own limits: it works at domain-property level and does not move subdomains for you.

After a month, compare like for like. If a page has genuinely lost position, check whether the content actually came across in full before blaming the move. Truncated imports are a more common cause than algorithmic punishment. The first thirty days sets out what to measure and when to worry.

Three moves we would talk you out of

Not every switch is worth making, and a site that tells you otherwise is selling something.

Do not move a healthy store during your busy season. Checkout, payment provider, tax settings, shipping rules and every product URL all change at once. Pick the quietest month you have.

Do not switch platforms to fix a design problem. Every builder on this page can produce a good-looking site and a bad-looking one. If the complaint is that your site looks dated, a new template on your current platform costs a weekend instead of a month.

Do not start the move with the domain. It is the one step that is instantly visible to the public and the one step with a mandatory waiting period attached. It goes last, always, for both reasons.

If the reason you are leaving is a hard ceiling — a feature that genuinely does not exist, a bill that genuinely does not work, a platform that is genuinely being wound down — then the move is worth the hours. Start with the inventory, and give yourself twice as long as the number you first thought of.