Blog

Migrating From Squarespace to Swell: A Complete Guide (2026)

A step-by-step guide to moving a store from Squarespace Commerce to Swell: what exports, what doesn't, field mapping, redirects, and subscription cutover.

Swell Team |

Squarespace Commerce caps every product at six option types and 250 variant combinations, and a store can accept only one currency at a time. Those two numbers end more Squarespace tenures than any sales pitch does. By the time a brand is reading a migration guide the decision is usually made, and the open question is what actually survives the move.

The honest answer splits three ways. Products, categories and customer records come across cleanly with a modest amount of scripting. Order history comes across as a flat archive rather than as live, reconcilable records. Digital downloads and active subscriptions do not come across at all. Squarespace states plainly that it is not possible to export download products, and its own subscription documentation warns that connecting a different payment processor means customers will have to resubscribe.

What follows is the pre-migration audit, a field-by-field mapping into Swell's data models, storefront rebuild options, a redirect plan for Squarespace URL patterns, the payment cutover, a testing checklist and effort estimates by catalogue size. It assumes a store on Squarespace 7.1. For the fuller catalogue of ceilings that push brands off the platform, see the companion piece on Squarespace Commerce limitations.

Key Takeaways

  • Squarespace exports physical and service products to CSV, up to 10,000 items, but the export drops customer reviews, featured images, alt text and variant images, and download products cannot be exported at all.
  • Order data exports with 49 fields, but partially refunded orders display the full purchase price, so financial history needs reconciliation before it is trusted.
  • Every customer resets their password. No platform exports password hashes. Swell stores passwords with bcrypt and ships password reset fields to drive the re-onboarding email.
  • Live subscriptions are the hardest part. Squarespace subscriptions run only on Squarespace Payments or Stripe. Swell's `date_trial_end` field lets a rebuilt subscription resume on its original billing date without double-charging.
  • No off-the-shelf tool migrates Squarespace to Swell. Vendors such as Next-Cart support 80 or more platforms and list roughly fifty migration targets for Squarespace, and Swell is not among them, so plan on CSV plus scripted API work.
  • Budget 2 to 3 weeks for a catalogue under 100 products and 4 to 6 weeks at 1,000 or more, with subscriptions and digital goods adding the most time.

Why Brands Outgrow Squarespace Commerce

Squarespace earns its reputation honestly. For a brand selling fifty simple products with a strong visual identity it is hard to beat: the editor is excellent, hosting is handled, and a founder can run the store without a developer. Brands rarely leave because Squarespace is bad. They leave because they hit a specific wall with no workaround.

The Catalogue and Variant Ceiling

An apparel brand running colour, size, fit and length reaches the 250-variant ceiling with a single style. Site-wide, stores cannot exceed 10,000 products, and sites cap at 1,000 pages, with Squarespace recommending no more than 400 pages for performance. Swell models the same catalogue with `options`, `variants` and a separate `attributes` field for arbitrary structured data, plus `bundle_items` for kits and `purchase_options` for one-time versus recurring pricing on the same product. There is no published variant-combination cap to design around.

One Currency and Two Processors

Squarespace is explicit that a store accepts one currency at a time. Multi-currency checkout lets shoppers pay locally, but prices, payouts and reporting stay in a single base currency, and there is no per-market price list. Swell separates currencies into base, display and priced roles, where priced currencies carry explicitly defined amounts rather than daily conversions, so a round 49 EUR price in Europe can sit alongside a 59 USD price in the States.

Subscriptions are tighter still. Squarespace subscription products require Squarespace Payments or Stripe, and PayPal, Apple Pay and ACH cannot process them. Customers can buy only one subscription product per checkout and cannot add other products to that transaction. Renewal-frequency changes apply only to new subscribers, so repricing an existing cohort means discontinuing a product and launching a replacement. Swell treats recurring billing as a core API object with a `billing_schedule` and a separate `order_schedule`, so billing monthly while shipping quarterly is configuration rather than workaround.

An API That Stops at the Back Office

Squarespace publishes nine Commerce APIs covering products, orders, inventory, transactions, discounts, contacts, analytics, profiles and webhooks. They are back-office APIs. There are no cart, checkout or storefront endpoints, the Orders API returns up to 50 orders per page and its only writes are creating an order from a third-party sales channel and marking one fulfilled, and API keys for the Orders, Inventory and Transactions APIs require the Core, Plus or Advanced plan. Swell exposes a self-describing Backend API for administrative work and a separate Frontend API that owns cart, checkout and account sessions, which is what makes a genuinely headless build possible rather than a themed one.

What You Can and Cannot Export From Squarespace

Before scoping anything, sort the data into three buckets. This is the most useful hour of the whole project, because the third bucket sets the timeline.

Comes Out Cleanly

Comes Out Partially

  • Product media. The CSV excludes featured images, alt text and variant images. Assets must be pulled from their CDN URLs and re-uploaded separately.
  • Customer reviews. Excluded entirely. If reviews are a conversion asset, treat re-collection as its own workstream.
  • Customer addresses. Only the last-used shipping and billing address is exported, not a full address book, so repeat customers lose their saved extras.
  • Refund history. Partially refunded orders show the full purchase price in line-item data, so net revenue has to be rebuilt from the transactions record.
  • Additional product information. The rich-text block beneath the standard description is not in the CSV and needs scraping or manual re-entry.

Does Not Come Out At All

  • Download products. Squarespace states it is not possible to export them. Squarespace also blocks downloading your own uploaded files, so the source assets have to come from your own copies rather than from the store, and the product records are rebuilt by hand.
  • Customer passwords. Squarespace accounts require a minimum of 10 characters and reset only through the login flow.
  • Saved payment methods. Customers see only the last four digits of a stored card; the credentials live with the processor, not the store.
  • Active subscriptions. There is no subscription export, and changing processor account forces customers to resubscribe.
  • Member Sites and course access. Gated-content entitlements are a separate product surface with no path into a commerce data model.

The Migration Plan, Step by Step

Step 1: Run a Pre-Migration Audit

Spend the first few days counting things, because every later estimate depends on these numbers.

  • Total SKUs, and how many products exceed four option types. These are the ones that were straining the platform.
  • Count of download products and total file volume, since each is a manual rebuild.
  • Count of active subscribers, their renewal dates, and which processor holds their cards.
  • Twelve months of order volume, and whether finance needs queryable history or a static archive.
  • Your top 200 URLs by organic traffic from Search Console, which become the redirect priority list.
  • Every third-party extension in use, and whether Swell has a native equivalent, an integration, or needs custom work.
  • Outstanding gift card liabilities, which have to be recreated as balances before cutover.

Step 2: Map Squarespace Fields to Swell Models

Swell's models use snake_case field names that map predictably onto the Squarespace CSV columns. The mapping below covers the fields that matter.

Product fields:

  • `Title` to `name`
  • `Product URL` to `slug`, stripping the leading store-page path and the `/p/` segment
  • `SKU` to `sku`, or to `variants.sku` on variant rows
  • `Price` to `price`; `Sale Price` to `sale_price` with `sale` set true
  • `Description` to `description`; `Excerpt` to `summary`
  • `Stock` to `stock_level`, with `stock_tracking` enabled
  • `Weight` to `shipment_weight`; `Length`, `Width`, `Height` to `shipment_dimensions`
  • `Categories` to `categories`, creating the category records first so products reference real IDs
  • `Tags` to `tags`
  • `Option Name 1` through `3` and their values to the `options` array, which then generates `variants`
  • `Visible` to `active`
  • `SEO Title` and `SEO Description` to `meta_title` and `meta_description`
  • Squarespace product type to `type`, which accepts `standard`, `subscription`, `bundle` or `giftcard`; create downloads as `standard` with the `virtual` boolean set true, which leaves `delivery` null so nothing is queued for shipment

Customer fields:

  • `Email` to `email`, the unique key on the Swell account model
  • `First Name` and `Last Name` to `first_name` and `last_name`
  • Last-used shipping block to `shipping`; last-used billing block to `billing`
  • `Tags` to `tags`, or to `group` where a tag represents a pricing tier such as wholesale
  • `Total Spent` and `Total Orders` have no direct equivalent, since Swell derives them from order records. Carry them as custom fields only if they drive segmentation
  • No password field exists. Leave `password` unset and drive re-onboarding through `password_reset_key` and `password_reset_url`

Step 3: Move Products and Categories

Create the category tree first, then transform the Squarespace CSV into Swell's import format. Swell accepts product import in CSV or JSON, with a template available from the import dialog.

For anything beyond a simple catalogue, scripting against the API beats the CSV path, because it handles images, categories and variants in one pass. Swell's batch endpoint carries up to 1,000 operations per request, which turns a 5,000-SKU catalogue into five calls rather than five thousand. Images need their own pass: pull each asset from its Squarespace CDN URL, re-upload, and attach it to the product or variant.

Step 4: Move Customers Without Passwords

Import accounts with email, names, billing and shipping, and leave the password unset. A Swell account with no password behaves as a guest record until the customer sets one, which is exactly the state you want.

Then plan the communication. A reset email arriving with no warning reads as phishing and gets deleted. Send an advance notice three to five days before cutover, then the reset itself on launch day. Expect reactivation in waves over several weeks.

Step 5: Archive Order History

Most teams overthink this one. Recreating historical orders as live records produces data that looks real but reconciles against nothing: the payment sits with the old processor, the refund state is unreliable, and totals will not match the books. Three workable options:

  • Keep the export as a cold archive. Cheapest, and sufficient for most brands. Support looks up old orders in a spreadsheet or a read-only tool.
  • Load history into a custom model in Swell. Past orders live alongside the store as reference data without pretending to be live orders, and customers see their full history in one account view.
  • Import as native orders, marked paid and fulfilled. Only worth it when returns, warranties or subscription entitlements depend on the original record being actionable. Accept that the financial data is approximate and exclude it from reporting periods.

Whichever path you take, pull the data through the Orders API rather than the CSV if the store is on Core or above. The API returns structured line items, includes subscription-generated orders, and avoids the refund distortion in the CSV export.

Step 6: Rebuild Subscriptions

This step decides whether the migration is a two-week project or a two-month one. Read the payments section below first, because the plan depends entirely on who holds the cards.

Assuming card data moves, the rebuild is mechanical. Create a Swell subscription per subscriber with `account_id`, `product_id`, the matching `billing_schedule` and `quantity`. The critical field is `date_trial_end`: Swell charges the default billing card immediately on creation unless a trial end date is set, and changing that value updates the billing period. Set it to each subscriber's next scheduled renewal date and the subscription resumes on its original cadence with no double charge and no gap.

Run this against internal test accounts first, then a pilot cohort of 20 to 50 real subscribers, and only then the full base. Watch one complete live renewal cycle before calling it done.

Step 7: Choose a Storefront Approach

Swell separates the storefront from the commerce backend, so the rebuild is a real choice rather than a theme swap. Three paths, in increasing order of effort:

  • Proxima with the Sunrise theme. Proxima is Swell's default storefront app, installed automatically with a new store, and Sunrise is its default theme. Fastest route to a working store and the closest analogue to how Squarespace already works.
  • A Shopify Online Store 2.0 theme rendered through Proxima. This opens up a large commercial theme market, with documented limits: Shopify app blocks are not rendered, Shopify-specific scripts are unsupported, and search is limited to products.
  • A fully custom headless storefront on Next.js or a comparable framework, talking to the Frontend API. Highest effort, and the reason most brands choose Swell in the first place.

A useful sequencing trick: build the storefront against a Swell store loaded with sample catalogue data while the Squarespace site is still live and selling. Storefront work never needs to block on the final data import.

SEO and Redirect Strategy

Mapping Squarespace URL Patterns

Squarespace 7.1 product URLs always insert a `p/` segment between the store page slug and the product slug, and additional slashes inside a product slug are forbidden, which is why nested product URLs do not exist on the platform. The practical mapping:

  • `/shop/p/product-name` to `/products/product-name` on the new storefront
  • `/store/p/product-name` to `/products/product-name`, and any other store page slug follows the same rule
  • `/shop` to `/products`, or whichever collection route the new storefront uses
  • Category pages are filtered store URLs whose slug is editable per category, so enumerate them from the dashboard rather than assuming a pattern, then map each to its `/categories/<slug>` equivalent
  • `/blog/post-title` to the new blog route, noting that Squarespace blog URLs can include date variables depending on the configured format
  • Static pages such as `/about` and `/contact` usually map one to one
  • Cart, checkout and account URLs need no redirects and should be excluded from the map

Preserve the product slug wherever possible. Changing the slug and the path structure in the same move doubles recovery time for no benefit, and removing `/p/` is already change enough.

Redirect Mechanics

Squarespace's own URL mappings tool uses an `/old-url -> /new-url 301` syntax and supports a `[name]` variable for collection pages, with a field limit of 400 KB or roughly 2,500 lines. That tool is useful for staging work while the site is still on Squarespace, but it stops mattering the moment DNS moves. The redirects that count are the ones implemented on the new host, whether that is Next.js config, a Cloudflare rule set or a CDN redirect table.

Use 301 rather than 302, since this is permanent and 302s pass no authority. Keep redirects live for at least a year rather than the three months that feels sufficient. Test the top 200 URLs individually before launch and again the morning after. Submit the new sitemap on launch day and expect recrawl to take several weeks. Keep the old site reachable on a temporary subdomain for a week or two so support can verify anything that looks wrong.

Payments and Subscription Cutover

Which Processor Holds the Cards

If the store is on Stripe, the path is workable. Stripe supports PCI-compliant data migrations between accounts and between processors, preparing an encrypted export of card data and arranging a secure transfer. It will only transfer to a PCI DSS Level 1 compliant processor that can supply a current Attestation of Compliance or a Visa Global Registry listing, plus a PGP public key of 4096 bits or greater. Since Swell connects to Stripe directly as a gateway, a merchant who owns their Stripe account often avoids the migration entirely by reconnecting the same account to the new platform.

If the store is on Squarespace Payments, assume the cards do not move. Card credentials held inside a platform's own payments product are not portable to a competing platform, and the warning about resubscribing should be read literally. The migration then includes a customer-facing re-authorisation campaign: subscribers are emailed, asked to re-enter payment details, and a meaningful percentage will not. Model that churn honestly before committing to a date, and consider an incentive for re-subscribing inside a set window.

Sequencing the Cutover

Where the subscriber base justifies it, run both systems in parallel for one billing cycle. New subscriptions are created on Swell from day one, while existing ones run out their current period and migrate in cohorts by renewal date. Slower than a single switch, and it converts an all-or-nothing risk into small observable ones.

The Reality Check: What Actually Hurts

Order History Becomes a Second-Class Citizen

However it is handled, historical orders in the new platform will not be as good as they were. Customers who could see three years of purchases will see either nothing or a read-only list, and support will check two systems for a while. Finance cannot simply import the CSV and trust it, because of the refund distortion.

Password Resets Cost Real Customers

The reset email is the largest source of preventable loss in any migration. Warn people in advance, keep the flow short, allow guest checkout, and re-send to non-responders after two weeks.

Digital Downloads Are a Full Rebuild

Squarespace download products cap at 300 MB, one file per product, with the download link expiring 24 hours after purchase. None of that configuration exports, so every digital product is recreated by hand: file re-uploaded, product record rebuilt, fulfilment logic reimplemented. The destination is more flexible, since Swell handles digital goods as `virtual` products with delivery rules under your control rather than fixed at 24 hours.

Note the fee difference that often triggers the move. Squarespace charges digital-product transaction fees of 7 percent on Basic, 5 percent on Core, 1 percent on Plus and 0 percent on Advanced, on top of card processing. A creator doing meaningful digital revenue on a lower tier pays a material tax on every sale.

The Real Cost Picture

Squarespace list pricing is $19 per month for Basic, $29 for Core, $49 for Plus and $99 for Advanced on annual billing, or $25, $39, $65 and $139 billed monthly. Physical-product transaction fees are 2 percent on Basic and 0 percent on Core and above, with card processing at 2.9 percent plus 30 cents for standard cards on Basic and Core, and 3.2 percent plus 30 cents for American Express.

Swell's published pricing works on revenue tiers rather than a flat fee: Starter at $29 per month, Basic at $79, Standard at $299 and Unlimited at $2,250, each billed yearly and each carrying a trailing twelve-month revenue ceiling of $50K, $250K, $1M and $5M respectively. Past the ceiling an overage rate applies to sales at 2 percent, 1.5 percent, 1 percent and 0.4 percent, falling as the plan rises, with custom pricing above $10M in annual sales. Usage beyond the included allowances bills at $5 per 100,000 API requests or function calls and $5 per additional gigabyte of storage per month. Model this against actual trailing revenue, since the overage rate rather than the monthly fee determines cost at scale.

Then add the parts no pricing page shows: developer time for the storefront rebuild, the transform scripts, the image migration and the subscription re-authorisation campaign. For most brands these exceed the first year of platform fees.

Testing Checklist Before You Cut Over

Work through this on a staging store with real data. The failures that matter only appear with messy production records.

  • Every product renders with correct price, images, variants and stock, including those that were straining the 250-variant ceiling.
  • Variant selection produces the right SKU and price at every combination, spot-checked against the old store.
  • Tax calculates correctly for domestic and international addresses, and for any tax-exempt customer group.
  • Shipping rates match expectations at several weights and destinations, including the heaviest and lightest items.
  • A full checkout completes on a real card in live mode, then refunds cleanly.
  • Discount codes apply, stack or fail to stack exactly as intended.
  • A migrated customer can request a reset, set a password, log in and see their addresses.
  • Guest checkout works end to end without an account.
  • A test subscription bills on its scheduled date, and a mid-cycle change behaves correctly.
  • Transactional emails send with correct content, branding and links.
  • The top 200 redirects resolve with a 301 to a live page, verified individually.
  • Analytics, pixels and consent banners fire on the new storefront.
  • Inventory decrements on purchase and restores on cancellation, and carried-over gift card balances redeem for the correct amount.

Timeline and Effort by Catalogue Size

These assume one developer with a competent operator, no active subscriptions, and a storefront on Proxima rather than fully custom. Add 1 to 3 weeks for a custom headless build, and 2 to 4 weeks if live subscriptions are in scope.

Under 100 Products: 2 to 3 Weeks

The CSV path is sufficient. Products import through the dashboard, images are re-uploaded manually, customers arrive as a single file, and order history stays an archive. Most calendar time goes to the storefront and testing rather than to data.

100 to 1,000 Products: 3 to 5 Weeks

Scripting starts to pay for itself. Write a transform that reads the CSV, resolves categories and posts through the batch endpoint, and automate the image pull rather than doing it by hand. Expect a full week on data alone, and expect the first import run to fail in interesting ways on products with unusual variant configurations.

1,000 to 10,000 Products: 4 to 6 Weeks or More

At this size the export limits bite: the product export caps at 10,000 items, and the site was probably already near the page ceiling. Plan multiple import passes, a reconciliation step that diffs source against destination by SKU, and a real staging environment. Data quality work usually takes longer than the import itself.

Choosing Your Path

Not every Squarespace store should migrate, and not every migration should go headless.

  • Stay on Squarespace if the catalogue is under a few hundred simple products, sales are domestic and single-currency, there are no subscriptions or digital goods at volume, and nobody on the team writes code. The platform is doing its job and a migration would be an expensive lateral move.
  • Move to Swell if products need more than six option types or 250 variants, you sell into multiple markets and want per-market pricing, subscriptions are a real revenue line, you need B2B or wholesale pricing tiers, or the storefront needs to be a custom application rather than a theme. These are the cases where the ceilings are structural rather than cosmetic.
  • Move to a different hosted platform if the only real complaint is the variant cap and the team has no developer capacity at all. Swell rewards teams that can use an API, and a brand with no technical resource may be better served elsewhere.
  • Delay if a peak selling season is within eight weeks, or if the subscriber base sits on Squarespace Payments and no re-authorisation campaign has been planned. Neither problem gets easier under time pressure.

If the evaluation is still open, the companion guides on migrating from WooCommerce and Wix ecommerce limitations cover adjacent ground and the same decision framework.

Frequently Asked Questions

Can order history be transferred from Squarespace to Swell?

Order data can be extracted, but not transferred as live records. The CSV export carries 49 fields, and the Orders API returns richer structured data on Core plans and above. What cannot come across is the payment linkage, since the original transactions sit with the old processor. Most brands keep history as a read-only archive, either as files or in a custom model in Swell, rather than recreating it as native orders.

Will customers have to create new passwords?

Yes. No ecommerce platform exports password hashes, so every migrated customer sets a new one. Import accounts without a password, then use Swell's password reset fields to send a reset. Warn customers a few days ahead so the email is expected, and keep guest checkout enabled so a forgotten password never blocks a purchase.

What happens to active subscriptions?

They have to be rebuilt, and difficulty depends on the processor. On Stripe, a merchant who owns their account can often reconnect it to Swell, or use Stripe's PCI-compliant data migration to move card data. On Squarespace Payments, assume the cards do not move and plan a re-authorisation campaign. When rebuilding, set `date_trial_end` to each subscriber's next renewal date so billing resumes on the original cadence without a double charge.

Can Squarespace digital downloads be migrated?

Not automatically. Squarespace states it is not possible to export download products, so each one is recreated by hand. Squarespace does not let you download your own uploaded files either, so re-upload from your own copies (one file per product, under 300 MB) and rebuild the product records, pricing and fulfilment rules. Swell handles these as `virtual` products with configurable delivery rather than a fixed 24-hour download link.

Is there a tool that migrates Squarespace to Swell automatically?

No. Migration vendors extract Squarespace data well, but their destination lists do not include Swell. The practical path is Squarespace CSV and API extraction, a transform script, and import through Swell's CSV or JSON import or the Backend API. For most catalogues this is a few days of scripting rather than a blocker.

How long will SEO take to recover?

With correct 301 redirects on the top-traffic URLs and preserved slugs, expect several weeks of recrawl and a temporary dip rather than lasting loss. The failure mode is not migration itself, it is redirects built after launch instead of before it, or a slug structure changed in the same move. Map redirects before cutover, keep them live for at least a year, and submit the new sitemap on launch day.

Does Swell charge transaction fees the way Squarespace does?

The structures differ rather than one being simply cheaper. Squarespace charges plan-based transaction fees on top of processing, 2 percent on Basic for physical goods and up to 7 percent on digital products. Swell's pricing is built on revenue tiers, each with an included trailing twelve-month revenue ceiling and an overage rate on sales past that ceiling, falling from 2 percent on Starter to 0.4 percent on Unlimited. Card processing is billed separately by the gateway in both cases, so compare against actual trailing revenue rather than list prices.