Website Migration Checklist: Moving to a New Builder or Host

Moving to a new website builder or host is really six separate jobs wearing one trenchcoat: content, URLs, email, forms/checkout, the domain, and a post-launch check. Treat it as one action — "launch the new site" — and it's easy to break the pieces that don't show up in a screenshot: a redirect that never got mapped, an MX record a migration wizard deleted, a booking calendar that quietly stopped working. This checklist puts those six jobs in a working order, with the specific mechanics for each one covered in more depth elsewhere on this site.

What order should I actually do this in?

1. Inventory and export everything from the old site.
2. Set up redirects so old URLs still resolve.
3. Move or reconnect email without an interruption.
4. Replace or re-embed forms, booking and checkout, tested before launch.
5. Point the domain at the new site, last.
6. Verify the move in Google Search Console, after launch.

The domain step is deliberately near the end, not the start: everything before it can be tested on a staging URL or the new platform's own subdomain, while the old site is still live on the real domain. Only flip DNS once the new site is actually ready.

How do I inventory and export the old site?

Before you touch anything, get everything out of the old builder that has an export path — and confirm what doesn't. Content, structured data, and your domain are three separate kinds of export, and almost no builder gives you all of them the same way. Our export capability matrix checks source code, structured content, data archives, and domain portability separately for 16 builders against their own documentation — start there to know exactly what you're getting and what you'll need to rebuild by hand or screenshot instead.

• Export blog posts, pages, and products in whatever structured format the old builder offers (XML, CSV, JSON).
• Download images yourself — most content exports don't bundle them.
• Screenshot or manually record anything with no export path (custom CSS, closed-editor layouts).
• Keep the old site's subscription active until every export is verified to actually contain what you expect.

How do I keep my URLs and rankings?

A new design doesn't cost you search rankings on its own; un-redirected URLs do. Before launch, build a full inventory of every URL that gets traffic or links (Google Search Console's Pages report, plus a crawl of the live site), and map each one to its exact new address — not "close enough." Our redirects checklist covers building that URL inventory, setting the 301 itself on Squarespace, Wix, Webflow, and self-hosted WordPress, and the common mistake of redirecting everything unmapped to the homepage instead of the closest real replacement.

• Every indexed or linked URL has a specific new-address mapping, not a blanket homepage redirect.
• Each redirect is a real 301, not a 302, and doesn't chain through an intermediate URL.
• The mapping document itself is saved somewhere outside either platform, in case a URL turns up missing later.

How do I keep email working through the move?

Your website and your email usually run on different services that just happen to share one domain, pointed to by different DNS record types — A/CNAME for the site, MX (plus SPF, DKIM, and DMARC as TXT records) for mail. The failure mode here is almost always the same: a migration tool or a "clean up my DNS" step touches the mail records by accident while moving the site records. Our email and DNS guide covers which record types to protect and a safe cutover order.

• Every MX, SPF, DKIM, and DMARC record identified and exported before touching anything.
• Only the website-pointing A/CNAME records changed — mail records left untouched.
• A test email sent and received successfully right before, and again right after, the domain change.

If the new site connects by changing nameservers rather than individual records, this step matters even more: a nameserver change moves the entire DNS zone at once, mail records included, so recreate every mail record at the new DNS host first.

How do I keep forms, booking, and checkout working?

A form, a booking calendar, and a checkout are three different kinds of thing your builder built for you, and none of them travel in a code or content export — only the data behind them does (a CSV of submissions, a client list, an order history). The working feature itself has to be rebuilt or, in some cases, simply left where it is. Our forms, bookings, and checkout guide covers which category needs a full replacement and which — like a standalone scheduler — you can often just re-embed unchanged on the new site.

• Every form's submission history exported, with any payment or order details it excludes recorded manually.
• A decision made per feature: does the tool travel with you (re-embed it), or does it need a genuine replacement (migrate the data, rebuild the workflow)?
• A real test submission, a real test booking, and a real test order placed on the new setup before announcing the switch.

How do I move or reconnect the domain?

This is the step to do last, once everything above is verified working on the new platform's own temporary URL. Decide first whether you're changing DNS only (keeping the domain registered where it is) or transferring the registration itself to a new registrar — these are different jobs with different mechanics, timelines, and lock periods. Our domain transfer guide covers the authorization-code process for Squarespace, Wix, GoDaddy, Shopify, and Weebly specifically, including the roughly 60-day ICANN lock that applies to all of them after a recent purchase or contact change.

• Decided: repoint DNS only, or transfer the registration too?
• Every existing DNS record recorded, so anything that doesn't carry over can be recreated.
• Domain pointed at the new site only after the new site is confirmed working elsewhere first.

How do I check the move worked in Google Search Console?

Once the new site is live on the real domain, Google's own site-move documentation lays out what to do next. If you changed domains or subdomains, "submit a Change of Address in Search Console for the old site" (Google Search Central, "Site moves with URL changes", checked September 2026) — this isn't needed for a same-domain change like adding HTTPS. Google's own recommendation on how long to keep the old redirects running is direct: "Keep the redirects for as long as possible, generally at least 1 year" (same source).

• Change of Address submitted in Search Console, if the domain or subdomain changed.
• New sitemap submitted; old sitemap removed only after the new one is confirmed indexed.
• Search Console's Pages report checked over the following weeks for a spike in "Not found (404)" or "Page with redirect" — a sign a URL mapping was missed.
• Redirects kept live for at least a year, not removed as soon as the new site launches.

What if I find a problem after launch?

Nothing on this list is a one-way door if you kept your exports, your URL mapping, and your DNS records from before the change. A missing form submission is almost always a notification email that was never re-entered on the new service. A 404 in Search Console traces back to your URL inventory — add the missing redirect, it doesn't need to be perfect on day one. A broken mail flow is fixed by restoring the exact MX, SPF, DKIM, and DMARC values you recorded before the switch, at whichever DNS host is actually authoritative for your domain now. The one truly hard-to-recover mistake is not keeping records of the old setup in the first place — every step above exists to make sure you have something to restore from if a later step goes wrong.

Where does Figment fit into this?

If the new destination is a Figma-designed site published through Figment, the content and redirect steps above still apply the same way — Figment publishes real, server-rendered HTML from a Figma file, and its paid plans support a custom domain you connect with the DNS steps in this checklist. Figment doesn't run forms, bookings, or checkout itself, so those pieces of the migration point at whichever third-party tool you choose to keep or replace, the same as they would moving to any other platform.

Bottom line: export and inventory first, map redirects before you need them, protect email's DNS records specifically, decide form-by-form and booking-by-booking what actually needs rebuilding, move the domain last, and confirm the whole thing in Search Console afterward. Each step has its own detailed guide linked above — this checklist is the order to use them in.