Squarespace to Shopify Migration

The design does not exist as anything you can take with you, and this is the fact most Squarespace merchants have never had to confront. The native export is XML, it explicitly excludes style settings and custom CSS, and store, portfolio, index and cover pages are not exportable at all. Squarespace states the general case outright: it is not possible to export content from one Squarespace site and import it into another. Not "the design will need updating" — there is zero export path for your design, even between two Squarespace sites. What you have is a set of configuration values interpreted by a proprietary renderer, and none of it is a file.

There is no templating language exposed at any level. CSS injection is the entire code surface, and Squarespace’s own documentation puts even that outside the scope of its support. So there is no source to port and no partial credit: the front end is rebuilt from screenshots and intent. That is the floor of the project rather than its risk case, and any quote that treats the design as a migration task rather than a design task is wrong about the platform.

Fluid Engine is 7.1-only, and upgrading a 7.0 section to it cannot be undone once saved. Which version and which editor the site is on changes what can be captured before anything moves, so establish it first — including on any 7.0 site somebody is halfway through converting.

Squarespace sells in one currency at a time, full stop. That is its sharpest isolation from Wix and BigCommerce, and it has a specific consequence for the migration: you arrive at Shopify Markets with no existing multi-currency behaviour to preserve. Every decision about foreign pricing is a new one, made from scratch, which is simpler than reconciling an old model and more work than a toggle.

And if the business takes appointments, Acuity Scheduling is a separate company and a separate product, usable entirely independently of a Squarespace site. Bookings do not migrate with the website because they were never part of it — that account relationship simply continues, or it does not, and either way it is a decision rather than a data transfer.

Squarespace allows 6 options and 250 variant combinations per product, caps variant names at 100 characters, and does not support variants on digital products at all. Against Shopify’s 3 options and 2,048 variants, that is the same option ceiling as Wix with roughly a quarter of the variant headroom — by far the lowest of the three site builders. In practice the option ceiling is what bites: a product with four or more options splits and is stitched back with Combined Listings. The 100-character variant name cap is worth checking too, because it means some of your existing variant names are already abbreviations of what they were supposed to say.

There is no modifier concept — nothing comparable to the non-variant inputs BigCommerce and Wix both have. That cuts both ways: there is no personalisation layer to remap, and equally there is no existing pattern if the store has been faking one by burning variant slots on made-to-order inputs. If it has, the migration is the moment to move those to line-item properties and get the variant budget back.

There is no multi-location inventory. Shopify’s locations model is therefore new capability rather than a migration target, and it is one of the few places where the move adds something on day one rather than after a build.

Category structure is the awkward one, because Squarespace has no flat collections concept at all. Categories live inside whatever Store pages the merchant happened to build, and Squarespace documents no depth or count limit to map against. So the catalogue’s structure is not a documented tree you can read out of the platform — it is whatever the site’s page tree grew into, and it has to be inventoried by hand before it can be re-expressed as Shopify collections.

The named lossy point: the product CSV export silently drops featured images, variant images and alt text. Catalogue data migrates cleanly; imagery needs a separate recovery pass regardless of how small the catalogue is. This is the single most common way a Squarespace migration ships looking broken — the products are all there, and every one of them is missing its picture.

A Squarespace product URL is exactly two path segments: the Store page’s slug, then the product slug. Squarespace explicitly disallows more — it is not possible to add more slashes to a product URL. But the Store page slug is the merchant’s own choice, so products may live at /shop/x, /store/x or /buy-now/x, and a site with three Store pages has three different prefixes in play at once.

There is no fixed prefix system for any content type, which is exactly what makes redirect mapping here a manual crawl of the page tree rather than a rule you can express once. Shopify is the opposite in a way that helps: /products/, /collections/, /pages/ and /blogs/ are fixed and not redirectable, with only the handle after them editable. You are moving from a structure nobody documented to one you cannot change, so the whole map has to be enumerated from a crawl.

One assumption worth correcting before it costs you: 7.0 Index sub-pages are not deep paths. They get hash-based URLs — domain.com/#/page-title — which are not separate URLs to a crawler and cannot be redirected to anything. The defensible statement about Squarespace URLs is "no fixed prefixes", not "deep nesting", and if an audit has told you that you have hundreds of index sub-pages to redirect, check what they actually are first.