What Happens to My Forms, Booking and Checkout When I Switch Website Builders?

Your form, booking, or checkout data usually exports as a spreadsheet; the working feature behind it almost never does. A form export gives you the list of who submitted what. It doesn't give you spam filtering, notification routing, or the service itself. A booking export gives you your client list and appointment history. It doesn't give you a live calendar your customers can book into. This post covers what each category actually exports, what silently doesn't move with it, and the replacement pattern for each — so nothing that currently makes you money goes quiet on migration day without you knowing in advance.

What happens to native forms?

Squarespace. Open the form block's settings, go to Storage, and click Export Submissions, which "generates a CSV file your browser downloads automatically" (Squarespace). Every form field comes through as a column, but "uploaded files aren't included in the export" — you get direct links to download them separately, not the files themselves (same source).

Wix. From the Forms & Submissions dashboard, select submissions and click Export. The catch is specific to payment-collecting forms: Wix's own help center confirms that "when using the new Wix Forms to collect payments, order details such as the Order ID, payment information, and total amount are part of the order data. You can see this information in the submissions table, but it is not included when you export your submissions as a PDF or CSV file" (Wix). If any of your forms collect payment, record those order details manually before you migrate — the export won't carry them.

Webflow. Go to Site settings → Forms, open View submissions for a form, and click Export all to download a CSV, which "includes all submission data for that form," with uploaded files included as links rather than files (Webflow). The critical line for anyone leaving Webflow entirely: "If you've exported your site for external hosting, Webflow will not process form submissions on your site. You'll need to use a third-party tool to collect form submissions on the exported site or embed a third-party form integration" (same source). A Webflow code export gives you the form's HTML markup, not a working form.

What doesn't move, in all three cases: the processing behind the form — spam filtering, the notification email routing, and any connected integration (Zapier, Mailchimp, a CRM) — is built into that platform's account and doesn't transfer with an export. The replacement pattern: point your form's HTML at a dedicated third-party form service (the kind that accepts a plain HTML <form> action or a JavaScript embed independent of your page builder), reconnect your notification email and any integrations there, and confirm with a real test submission before you retire the old form.

What happens to booking and scheduling?

Acuity Scheduling (used as Squarespace Scheduling). Under Clients → Import/export → Export client list, choose a client group and export; the file includes "Client name, Client email address, Client phone number, Notes on the client file" and days since last appointment (Acuity). Under Reports → Import/Export, export a date range of appointments to get start/end times, appointment type, price, payment status, and intake form answers (same source). Acuity is a standalone product, not tied to any one page builder: its own documentation says "you can embed your scheduler in almost any website, whether you're using a Squarespace website or one from another provider," and lists specific embed steps for GoDaddy, Shopify, WordPress, Wix, and others (Acuity) — with one exception worth knowing before you rely on it: "You can embed your scheduler on sites built using WordPress, but not on sites hosted by WordPress.com" (same source); Acuity identifies those as sites whose address ends in wordpress.com. The replacement pattern here is the simplest of the three: don't migrate the booking tool at all. Keep the Acuity account exactly as it is and re-embed the same scheduler in your new site with a fresh copy of the embed code.

Wix Bookings. Go to Booking Calendar → Manage → Export booking data, choose a report type and date range. The Booking List report includes "Session date, Start time, Registration date, Client name, Client email, Client phone, Client address, Spots filled, Minutes, Service name, Service type, Staff name, Booking status, Attendance status, Payment status" (Wix). Unlike Acuity, Wix Bookings is a Wix-specific product built to run inside a Wix site; there's no documented way to keep the live Wix Bookings calendar running once you leave Wix. The replacement pattern here is different from Acuity's: treat the exported client and appointment history as your starting data for a new, standalone booking tool, rather than assuming the booking widget itself can travel with you.

What happens to my store or checkout?

Product, order, and customer data export as CSVs on every major commerce platform — Squarespace's Commerce orders export to CSV from the orders dashboard, and Shopify's Data Exporter app handles order and customer backups the same way (both covered in detail in our export capability matrix). What doesn't come with any of those exports is the working function: payment gateway configuration, tax calculation rules, shipping rate setup, inventory sync, and discount codes are configured inside that platform's commerce engine and have no export path to a different platform's engine. Rebuilding a full checkout on a new platform from a CSV of past orders is a different, much larger project than a marketing-site migration. The replacement pattern for checkout is usually to not migrate it: keep the store running on its current commerce platform (Shopify, Squarespace Commerce, or Wix Stores) exactly as it is, and link or embed it from your new marketing site, the same way you'd keep Acuity running and just re-embed it. Only replatform the store itself as its own deliberate project, with its own testing period, separate from a site redesign.

What should I check before I cut over?

• Every form on the old site inventoried, with its submission export downloaded and its file uploads (if any) saved separately.
• Every payment-collecting form's order/payment details recorded manually if the platform excludes them from export (Wix Forms does).
• A replacement form service chosen and tested with a real submission before the old form is removed.
• Booking and scheduling: confirmed whether the tool is standalone (Acuity — keep it, re-embed it) or platform-tied (Wix Bookings — export the data, plan a replacement tool).
• Commerce: a decision made, explicitly, about whether the store stays on its current platform (linked from the new site) or gets replatformed as its own project — not assumed by default.
• A test form submission, a test booking, and a test order placed on the new setup before announcing the switch, not after.

What if something breaks after the switch?

Nothing above is a one-way door if you kept the export files and didn't cancel the old accounts prematurely. A missing form submission means checking whether the new form service's notification email is actually configured — the most common cause is a notification address that was never re-entered on the new service. A missing booking on an Acuity setup means confirming the embed code on the new site still points at the same Acuity account, not a stale one from testing; if you replaced Wix Bookings, check the new booking tool's calendar and notification settings instead. A broken checkout, if you kept the store on its original platform, is almost always a link or embed problem on the new marketing site, not a data problem — the store itself never moved. Keep the old accounts (Acuity, the old commerce platform, the old form export files) active until you've confirmed all three work on the new site, since none of these categories has a single "undo" button the way a code deploy does.

For the rest of what does and doesn't survive a platform switch — email, DNS, and your blog specifically — see will switching builders break my email and how do I keep my URLs and rankings.

Bottom line: Export the data from every form, booking tool, and store before you touch anything else. Then decide, category by category, whether the underlying tool travels with you (Acuity does; Wix Bookings and native checkout usually don't) — and test the replacement with a real submission, a real booking, and a real order before the old one goes away.