When Squarespace stops being enough for the selling part

Four limits come up repeatedly. Product options and variants that need rules rather than a fixed list. Customer-specific or tiered pricing for wholesale. Catalogue and inventory operations at a scale where bulk editing and imports matter more than a pretty admin. And integrations — accounting, ERP, warehouse, marketplace sync — where the answer needs to be an API rather than a manual export. If none of those describe you, the honest recommendation is to stay and spend the money on demand generation instead.

• Variant and option rules the platform cannot express
• Wholesale or tiered pricing per customer
• Bulk catalogue and inventory operations at scale
• Integrations that need an API, not a CSV export

Squarespace stores are often content-led: editorial pages, journals, lookbooks and long-form product storytelling that earned real search traffic over years. That content is usually the most valuable thing being moved, and it is the part most often treated as an afterthought while everyone focuses on products. Inventory the content first, keep the URL structure wherever you reasonably can, and migrate the pages that have links and traffic before the ones that have neither. Anything you decide to drop needs a redirect to the closest relevant page, not a 404.

Products, categories, images, prices and stock export and import with normal care, though options and variants need mapping by hand. Customers transfer without their passwords, so a reset flow has to be part of the launch plan. Blog and page content exports, though the block structure will not survive intact and the layouts are rebuilt. Design does not move at all. Any commerce feature you configured inside the platform — discount rules, member areas, subscriptions — needs a WooCommerce equivalent chosen and configured, and that inventory is part of the quote rather than a surprise.

Product and category URLs will change shape. So will some content URLs, depending on how the new structure is designed. Every one of them needs an explicit 301 mapped before launch and verified on staging. Two habits prevent most of the damage: export the complete live URL list before anything changes, and pull your top pages by clicks from Search Console so the highest-value URLs are checked first rather than last. After go-live, watch coverage and 404s daily for a fortnight — what to do if rankings drop is the recovery path if something was missed.

Ownership of your data, your checkout and your code; no platform commission on top of payment processing; and the ability to express any selling rule you can describe, because nothing is gated behind what the vendor decided to support. For a store with genuine complexity, that is transformative. For a simple store, it is a set of powers you will not use, bought at the price of maintenance you now own — which is the trade the platform choice page walks through question by question.

Hosting, updates, security patching, backups and uptime stop being included in a monthly fee and become someone's job. That is not an argument against moving; it is an argument for deciding, before launch, who that someone is. Stores that migrate without answering this question do not notice for six months and then discover the cost in a single expensive incident. A maintenance plan or an in-house owner should be part of the plan from day one, not a reaction later.

Build on staging while the current store keeps selling. Migrate content first and verify it renders correctly, then products, then customers. Test checkout with real cards and real refunds. Choose a quiet window, freeze catalogue edits, do the final sync, switch DNS, and keep the old subscription active for a month. Verify order emails, payment webhooks and analytics events on the new environment specifically — a migration is not finished when the site loads, it is finished when a real order flows end to end and appears in your reports.