Migrating away from Squarespace to a custom Solidus store

What Squarespace is, and who should stay on it

Squarespace is a design led website builder with a shop bolted on. You pick a template, arrange content blocks in a visual editor, and the result is a good looking site with very little effort. For a small catalogue that is genuinely what many shops need, and if that describes you, this article is not an argument to leave. A maker selling forty products, a studio with a booking page, a brand that is mostly a beautiful homepage with a modest store underneath: Squarespace does that job well, the hosting is handled for you, and moving to a custom build would cost more than it returns.

I build custom shops on Solidus, an open source ecommerce framework on Ruby on Rails, so you know where I stand. That is exactly why I want to be fair about where Squarespace is the right answer. The person this article is written for has outgrown the builder: the catalogue has swollen past what the admin handles comfortably, the checkout cannot be changed in the ways the business now needs, an integration with a warehouse or an accounting system keeps not quite fitting, or the shop has simply become the business rather than a channel beside it. When the way people buy from you is part of why they buy from you, you reach the walls of a closed builder, and then the question is how to move without losing what you have built.

This is the honest account of that move: what Squarespace hands over cleanly, what it hands over in part, what you have to rebuild, and how I would plan the whole thing. For the deep mechanics of each kind of data, I link the guides in this migration series rather than repeat them. Start with the overview, what moves and what does not, which sits above every platform specific piece including this one.

What you own on Squarespace, and what the builder keeps

The first thing to understand before any export is how little of a Squarespace shop is actually yours to take.

You do not own the code. There is no application you can copy, no repository, no server you control. The storefront is rendered by Squarespace's own templates and their JavaScript and CSS, and those stay with Squarespace. You do not own the database. Your products, orders and customer records live inside Squarespace's systems, reachable only through what Squarespace chooses to expose. You do not own the hosting, the URL structure or the checkout flow. The content you arrange sits inside proprietary blocks that exist only inside the builder.

What you do own is your data, in the limited sense that you can get a copy of most of it out. That distinction is the whole migration. On an owned platform the shop is an asset you hold. On a closed builder the shop is a service you rent, and leaving means extracting your data from the service and rebuilding everything the service was doing around it. None of that is a scandal. It is what a builder is, and it is the trade you accepted for the easy start. I cover the ownership question in general in who actually owns your business data.

The export reality: what comes out, and in what shape

Squarespace has two separate export paths, and neither gives you the whole shop.

The first is the site content export. From the settings you can export your pages and blog to an .xml file in the WordPress format. Squarespace is explicit that this is for moving content to a WordPress site, and that it leaves a great deal behind: it carries layout pages, one blog page with its posts, and text and image blocks, but it does not export store pages or product blocks, and it does not export your style settings or custom CSS, because so many features depend on Squarespace's own code.¹ For a shop, the content export is useful for blog posts and little else. Your products are not in it.

The second path is the product export. In the Products panel you click Export all, and Squarespace produces a product CSV you can open in a spreadsheet.² This is the real catalogue export, and it is the cleanest thing you get. A few limits shape it. The CSV format covers physical and service products, not download products, so digital goods are outside it. The catalogue path carries up to 10,000 products on a current version 7.1 site and up to 250 variants per product.² And it is a one time extract: it is a copy taken at a moment, not a live feed, so anything that changes after you pull it has to be pulled again. For moving a catalogue of real size that is the file I work from, after mapping its columns onto the new shop's product model. The detail of that mapping, the SKUs, the variants, the option structure and the images, is in migrating products and catalogue data.

What the two export paths do not give you is orders and customers in bulk. There is no single button that hands over your full order history and your customer list in a clean, documented file the way the products panel does. For those you drop down to the API.

The Commerce API, and where it stops

Squarespace does publish a set of Commerce APIs, and for a serious migration they are the proper tool. They are also where the platform's ceiling becomes visible, so it is worth being precise.

To use the developer API keys at all, the shop has to be on the Commerce Advanced plan. Squarespace states plainly that a custom application for a merchant site is built on Commerce Advanced.³ On a lower plan the keys simply do not offer the commerce scopes, so the first cost of a clean migration can be an upgrade to the top plan for the months the move takes.

With a key in hand, the permissions are granular. Orders, Inventory, Products and Contacts can each be granted read only or read and write. Transactions is read only. The older Profiles API is in maintenance mode, and Squarespace directs new work to Contacts instead.³ For a migration I need read access across Orders, Products, Inventory and Contacts, which the key can grant.

The rate limits are modest and you plan around them rather than fight them. The Commerce APIs allow 300 requests a minute, which Squarespace equates to five requests a second. Go over it and you receive a 429 response with a one minute cool down.⁴ For a large catalogue and a long order history, paging through at five requests a second with retries is a job measured in minutes to hours, not seconds, so the extract script has to be patient and resumable.

What the Orders API actually returns is good, within its bounds. Each order carries the order number, the customer email, the billing and shipping addresses, the line items with their SKUs and prices, the subtotal, discounts, shipping, tax and grand total, and the fulfilment status with tracking details.⁵ Squarespace describes the Orders API as access to order history for both one time purchases and subscription orders.⁶ That is enough to rebuild a readable order history in the new shop. For how I bring order history across and how far back is worth keeping, see migrating order and purchase history.

Here is the important limit. The only payment information on an order is its payment state, a value such as paid or refunded.⁵ No card number, no saved card, no payment token comes out of the API, and the Transactions API that sits beside it is read only.³ That is correct and safe behaviour, and it is also the hard wall that every migration hits. Raw card data never leaves a compliant platform, and saved cards belong to the payment processor, not to Squarespace. Customer passwords are the same: they are stored as one way hashes that no export and no API will ever hand over, so every customer sets a new password on the new shop. I cover accounts and the password question in migrating customer accounts and addresses, and the saved card question in migrating payment tokens and saved cards.

The traps specific to Squarespace

Every platform has a handful of things that catch people on the way out. These are the Squarespace ones.

Digital products and member areas rebuild from scratch. If part of your business is downloads, courses, or a members only area behind a login, none of it comes out through the product CSV, and the member access model is proprietary. On the new shop those become features you build: a digital download that is delivered on payment, a gated area tied to a customer account, a course structure. That work is usually worth doing well, because on a custom shop you finally control how it behaves, but you must budget for it as a rebuild, not an import.

The URL structure is Squarespace's, and your rankings sit on it. Squarespace decides the shape of your product and page URLs, and years of links and search rankings have accumulated against those addresses. The day you move, every one of them has to redirect to its new home or it returns a 404 and the ranking drains away. Google's own guidance for a move with URL changes is to map every old address to its new one with a permanent redirect, point each redirect straight at the final destination, and keep the redirects in place for at least a year.⁷ Building that map is the unglamorous work that protects the traffic you already have, and I treat it as part of the catalogue move in migrating products and catalogue data.

Payments and saved cards depend on your processor. Squarespace shops take money through Squarespace Payments, Stripe or PayPal. Where your saved cards can go next depends entirely on which of those you use and whether the new shop can connect to the same processor account. If the shop already runs its own Stripe account, the saved cards can stay exactly where they are and the new shop connects to them, which is the best case. If the cards sit inside Squarespace Payments, plan on customers re entering them. The mechanics are in migrating payment tokens and saved cards.

Active subscriptions are the hardest thing to move. If you sell on a recurring basis, a subscription box or a membership that bills every month, those live schedules are tied to Squarespace and its processor, and they are the single most delicate part of any migration. Moving them without a gap in billing or a wave of failed payments usually needs the cooperation of the losing platform or the gateway, and sometimes a deliberate re enrolment of customers. Do not leave it to the last week. The whole question has its own guide in migrating subscriptions and recurring payments.

What moves, what is partial, what is rebuilt

The honest one page summary of a Squarespace move looks like this.

Part of the shop	What you get from Squarespace	What it means for the move
Blog and page content	WordPress .xml export, no store pages, no styling1	Import the text, rebuild the design
Products	Product CSV via Export all, physical and service only, one time2	Cleanest export, map onto the new product model
Digital products and member areas	Not in the CSV, proprietary access model	Rebuild as features on the new shop
Orders	Commerce API, Orders read, email, addresses, line items, totals5	Bring across as read only history
Customers	Commerce API, Contacts read, no passwords3	Import records, customers set new passwords
Saved cards	Payment state only, no card data or token5	Keep the processor, or customers re enter cards
Subscriptions	Order history only, live schedules tied to the processor6	Plan early, often needs processor cooperation
Design, code, hosting, checkout	Not portable	Rebuilt and then owned

Read down the right hand column and the shape of the project is clear. The catalogue and the content are a mapping exercise. The accounts and orders are an API extract with a clear ceiling. The design, the checkout and anything proprietary are a rebuild, and the rebuild is the point, because at the end you own it.

The honest move plan

I run a Squarespace move in a way that protects the two things you cannot get back: your search rankings and your customers' trust. The method is the same one in the pillar guide, applied to this platform.

Snapshot the history early. Before anything changes, I pull a full copy of what the APIs and exports give: the product CSV, the orders, the contacts, and your analytics. Squarespace's own analytics do not travel, so if you want to keep the ability to look back and forecast, the time to capture it is now, while the old shop is still live. The reasons and the method are in migrating analytics and historical data for forecasting.

Keep, snapshot or rebuild, decided per thing. Some data is carried live into the new shop (products, current customers, recent orders). Some is snapshotted and archived rather than imported (old orders beyond a few years, raw analytics). Some is rebuilt because it cannot move (the storefront, the checkout, digital delivery, member areas, integrations). Writing that decision down for every part of the shop is most of the planning.

Build and run in parallel. The new Solidus shop is built and tested on a staging address while the old Squarespace shop keeps trading. For the last few weeks the catalogue on the old shop is frozen, so the two do not drift apart, and the final extract on cutover morning holds no surprises because it has been rehearsed.

Map every URL before you switch. The redirect map is built and tested before cutover, not after. Every old product and page address points at its new home with a permanent redirect, and the redirects live inside the new shop so they survive every future deploy.

Keep the old shop for a month. After cutover the Squarespace site stays exactly as it was for thirty days as a fallback and a source of anything missed. Only after a clean month end on the new shop do you cancel the plan.

If you want the money side of this, how a five year cost on a custom build compares with staying on a rented platform, I work it through in the five year total cost of ownership, and I compare the platforms themselves in Solidus versus Shopify, Shopware, Magento and WooCommerce.

A worked example

Take an invented business. Saltmarsh Ceramics (saltmarsh.example) is a Brighton studio that started on Squarespace five years ago with forty glazed pieces and a beautiful homepage. It worked perfectly, and the shop grew. Today it lists around nine hundred products with colour and size variants, runs a monthly glaze club that bills subscribers, sells a handful of online courses as downloads, and wants to offer trade pricing to the galleries and interior studios that now buy in volume. The admin has become slow to manage, the checkout cannot ask a trade buyer for their account terms, and the course downloads are held together with a third party app that keeps breaking. Saltmarsh has outgrown the builder.

Here is how the move went, honestly. The nine hundred ceramic products came out through the product CSV cleanly, variants and all, and mapped onto the new product model in a couple of days of careful checking. The blog, five years of studio journal posts, came across through the WordPress export and was reformatted into the new shop. The customer list and three years of orders came out through the Commerce API over an afternoon of patient paging at five requests a second, and went into the new shop as records and read only history. Every customer received a friendly message before cutover explaining that they would set a new password on their first visit, because no password could be carried across.

Three things were rebuilt rather than moved. The course downloads became a proper digital delivery feature on the new shop, which finally worked reliably. The trade pricing, impossible on the old checkout, became an account type with its own price list. And the glaze club was the delicate part: because Saltmarsh already billed it through its own Stripe account, the subscriptions and the saved cards stayed with Stripe and the new shop connected to the same account, so no subscriber had to re enter a card or re enrol. Had the club been billed through Squarespace Payments, that would have been a re enrolment campaign instead. The redirect map ran to about twelve hundred rows, every old product and journal URL pointed at its new home, and the search traffic held through the switch. The old Squarespace site stayed up for a month, then the plan was cancelled.

Saltmarsh now owns its shop: the code, the database, the checkout and the three features that the builder could never have given it. Year one cost more than another year of Squarespace would have. From year two on, there is no plan tier standing between the studio and the next thing it wants to build.

Who should move, and who should stay

Stay on Squarespace if your shop is small, your catalogue is modest, your checkout is conventional and the design is most of the value. You will not get that ease back by moving, and a custom build you do not yet need is money spent early.

Move when the shop has become the business. When the catalogue is large, when the checkout needs to do things the builder will not allow, when digital products or member areas or trade pricing or subscriptions are central rather than a side feature, and when you want the shop to be an asset you own rather than a service you rent. That is the point at which a closed builder costs you more in what you cannot do than a custom shop costs to build.

If you are somewhere in the middle and genuinely unsure, that is exactly what a conversation is for. Bring your Squarespace shop, your catalogue size, your integration wish list and your frustrations to a free workshop, and the first two weeks of work are on me. I will tell you honestly whether you have outgrown the builder yet, and if you have not, I will tell you to stay.

Footnotes

1. Squarespace Help Center, Exporting your site (WordPress format .xml export, store pages, product blocks, style settings and custom CSS do not export), accessed 14 November 2026, https://support.squarespace.com/hc/en-us/articles/206566687-Exporting-your-site ↩ ↩²

2. Squarespace Help Center, Importing and exporting products with a .csv (Export all in the Products panel, physical and service products only, not download products, up to 10,000 products on version 7.1 and 250 variants per product, a one time export that does not sync later changes), last updated 22 January 2025, https://support.squarespace.com/hc/articles/115000378108 ↩ ↩² ↩³

3. Squarespace Developers, Authentication and permissions (Commerce Advanced plan required for a custom application, Orders, Inventory, Products and Contacts read only or read and write, Transactions read only, Profiles in maintenance mode), accessed 14 November 2026, https://developers.squarespace.com/commerce-apis/authentication-and-permissions ↩ ↩² ↩³ ↩⁴

4. Squarespace Developers, Rate limits (300 requests per minute, five requests per second, 429 Too Many Requests with a one minute cool down), accessed 14 November 2026, https://developers.squarespace.com/commerce-apis/rate-limits ↩

5. Squarespace Developers, Retrieve all orders (order number, customer email, billing and shipping addresses, line items with SKUs and prices, totals, fulfilment status and tracking, payment state only), accessed 14 November 2026, https://developers.squarespace.com/commerce-apis/retrieve-all-orders ↩ ↩² ↩³ ↩⁴

6. Squarespace Developers, Making requests to Commerce APIs (the Orders API provides access to order history for one time purchases and subscription orders), accessed 14 November 2026, https://developers.squarespace.com/commerce-apis/making-requests ↩ ↩²

7. Google Search Central, Site moves with URL changes (map every old URL to its new one, use permanent redirects, point each straight at the destination, keep them at least a year), accessed 14 November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩