Guides → Migrate from Squarespace to SGEN

Migrate from Squarespace to SGEN

Plan the move, run the import, verify the result — without losing the content the template carried.

Squarespace to SGEN migration is the path for moving an existing Squarespace site into the SGEN platform. The work spans three phases: a pre-migration inventory on the Squarespace side, the import event itself, and a validation cycle inside SGEN before the site is treated as production-ready.

This guide walks the full arc — what to export from Squarespace, what to expect when the data lands in SGEN, where the platform model differs, the eight-step sequence to run, the pitfalls to plan for, and the post-migration verification that earns the site a production-ready stamp.

What is this for?

Read this guide when you are planning a Squarespace to SGEN migration and want the structural picture before you commit to a date. The guide pairs the pre-migration inventory with the import procedure and the post-migration validation cycle, so the team knows what to gather, what to expect, and what to verify.

The guide is written for the operator running the migration. The audience is the agency principal, the in-house webmaster, the designer-developer scoping the move, or the founder who has built a Squarespace site and is moving it to SGEN. It assumes basic Squarespace administrator access on the source side and a working SGEN site to import into.

Good use cases

You are an agency migrating one or more client sites from Squarespace to SGEN and need the platform-level map.
You are an in-house team scoping the move and want the import shape laid out before signoff.
You are a designer-developer running the migration and need the sequence, the gotchas, and the verification checklist.
You are a founder evaluating the move and want the realistic timeline by site size.
You are returning to a paused migration and need the next-step anchor.

What NOT to use this for

Per-block translation internals — the Squarespace block-to-SGEN-section mapping varies per page and is handled inside the SG-Builder rebuild, not in this guide.
Squarespace administration help — this guide assumes the Squarespace side is operable. Squarespace-side recovery is outside the SGEN documentation surface.
Template-level visual replication — Squarespace's family of templates and SGEN's SG-Builder use different layout models. The Gotchas section below frames the expectation; this guide does not document template-by-template visual translation.

How this connects to other features

Migration and Import Overview — the parent Reference area for migration discipline in SGEN, including the risk-aware framing this guide leans on.
Import — the structural model for how data lands inside SGEN after the import event.
Backups — the foundational safeguard, captured before any high-stakes operation.
Post Migration — the validation discipline that earns the migrated site its production-ready stamp.
Search and Replace — the bulk-content cleanup pass that usually follows a Squarespace import (asset CDN URLs, embed paths).
Recovery Considerations — the rollback framing if the import behaves in a way the validation cycle cannot accept.
Migrate from WordPress — sibling migration guide; the inventory-export-import-validate-promote shape is the same across sources.
Migrate from Webflow — sibling migration guide; the rebuild-in-SG-Builder discipline shares ground with the Squarespace path.

Before you start

A clean migration depends on the Squarespace side being inventoried and exportable before the import event runs. Gather the following before opening SGEN:

From the Squarespace site

Administrator access to the source Squarespace site, with permission to use the export tool, view all pages and collections, and access the commerce, member-area, and scheduling surfaces if those are in use.
Squarespace export file (.xml) generated from Settings → Advanced → Import / Export Content → Export → WordPress. The file covers the blog posts, the basic pages, the layout pages where the export tool supports them, and the page metadata. The format is WordPress-XML-compatible by design.
Asset catalogue — a list of every image, video, and downloadable file referenced on the source site, including the original filenames and the Squarespace CDN URLs. The export references assets by URL; the binaries must move alongside.
Page list — every page in the source site, including the URL slug, the page type (basic, blog, gallery, events, products, members, scheduling), and any page-level custom code injection.
Block inventory — a sweep across every page noting which Squarespace block types appear (gallery, summary, form, calendar, embed, code, image, text, button, spacer, line, audio, video, archive, donation, OpenTable, product, accordion). Block-level mapping into SGEN's section model is the longest part of the rebuild.
Commerce data — if the source site uses Squarespace Commerce, export the product CSV (Commerce → Inventory → Export All), the orders CSV (Commerce → Orders → Export All), the customers CSV (Commerce → Customers → Export All), and any discounts or subscriptions configured inside the commerce surface.
Custom code surfaces — anything added to Settings → Advanced → Code Injection (header, footer, lock-page, order-confirmation) and per-page Code Injection panels.
Template + style detail — the active Squarespace template family (Brine, Bedford, Five, Avenue, Wells, Pacific, Fluid Engine pages, or any other), the current Site Styles values, the typography selections, and any custom CSS added to the Custom CSS panel.
Forms — every Squarespace Form on the source site, including the field set, the storage destination (Squarespace inbox, Google Sheet, Mailchimp, or Zapier), and any per-form logic.
Site settings — current SEO defaults, OpenGraph defaults, social-account connections, 301 redirects from Settings → Advanced → URL Mappings, and any password-protection or member-area configuration.
DNS posture — the current Squarespace billing plan, the connected custom domain, and whether email forwarding or Squarespace-hosted email is in use.

From the SGEN side

A live SGEN site to import into. The platform supports importing into staging first, then promoting staging to live — this is the recommended posture for any non-trivial migration.
An on-demand backup captured immediately before the import event. The backup is the rollback target if validation does not accept the imported state. See Backups for the safeguard discipline.
Module activation review — confirm the SGEN modules that match the Squarespace feature inventory are enabled on the target site. Forms, e-commerce, events, members, custom objects, and SEO surfaces are first-party modules; activate them before the import so the imported records have a home to land in.

Where to find it

The Import tool lives at the admin → Settings → Import. Select the Squarespace format, upload the .xml export file from Squarespace Settings → Advanced → Import / Export, and confirm module activations before running the import.

Steps

The full sequence is eight steps. Each is explicit about what to do, what changes, and what to verify before moving on.

1. Inventory the Squarespace side

Walk the source site once with the inventory checklist above. Note every page, every block type in active use, every commerce surface, every form, every place custom code injection lives. The inventory is the artefact the rest of the migration leans on — skipping it is the single largest cause of post-import surprise.

Save the inventory as a working document. Mark each item as "covered by SGEN module," "needs rebuild in SG-Builder," or "needs a follow-up decision after import." The three-column shape carries through the rest of the migration.

Pay close attention to three areas Squarespace operators often underestimate. First, the block-by-block sweep — a single page can carry a dozen block types, and the SG-Builder rebuild composes each one from SGEN sections rather than reusing the Squarespace block. Second, the commerce data — products, orders, customers, and subscriptions move through a separate path from the WordPress-compatible XML export. Third, the template-family lock — the visual layout the Squarespace template provides is not exportable as code, so the inventory should capture the visual intent that the SG-Builder rebuild will recreate.

2. Clean the Squarespace source before export

Run a cleanup pass on the source site before exporting. The pass removes content that should not arrive in SGEN — draft pages that were never published, archived blog posts that are no longer relevant, orphaned commerce SKUs that have been retired, asset uploads no longer referenced by any page.

Inside the source site, move retired pages to the Not Linked area or delete them outright, archive blog posts that should not move across, audit the asset library for orphaned uploads, and confirm the product catalogue reflects current inventory rather than historical SKUs. Run a final pass on the Code Injection panels to confirm any third-party snippets (analytics, chat widgets, embedded calendars) are accounted for in the inventory and have a destination on the SGEN side.

3. Export from Squarespace

Export the Squarespace side in three passes — each pass covers a different content layer, and each lands a different file shape.

First, open Settings → Advanced → Import / Export Content and click Export. Select WordPress as the destination format. Wait for the export to be generated, then download the .xml file. Save the resulting file to a known location. The file carries the blog posts, the basic pages where the export supports them, and the page metadata.

Second, if the source site uses Squarespace Commerce, export the product, orders, and customers CSVs separately from inside the commerce panel. Save each CSV to the same known location. The commerce data does not travel with the WordPress-compatible XML export — it moves through its own CSV pipeline.

Third, capture the asset library. Use the asset URLs noted in the inventory to retrieve each image, video, and downloadable file from the Squarespace CDN, either by downloading them individually or by capturing the URLs for the SGEN import wizard's direct-fetch option once the import event begins.

The Squarespace export file does not include every layout primitive verbatim. Pages built with newer block-based or Fluid Engine layouts often arrive with the textual content intact but without the visual structure the source template provided. The block inventory from step one is the input the SG-Builder rebuild leans on in step six.

4. Capture a backup of the SGEN target

In SGEN, open SG-Dashboard → Sites, select the target site, then trigger an on-demand backup before the import event. The backup captures the target site's current state — the rollback point if the validation cycle finds the imported state unacceptable.

Backups run as background jobs. The notification arrives when the backup file is ready. Do not start the import until the backup completes. See Backups for the per-operation Reference.

5. Run the import to a staging context

Open the admin → Migration on the target site. Select Squarespace as the source. Upload the WordPress-compatible .xml export, the commerce CSVs (if applicable), and the asset archive (or point the wizard at the source asset CDN if direct fetch is available). Confirm the destination scope and start the import.

Run the import on staging first. The platform's recommended posture is import-to-staging, validate, promote-to-live. Importing directly to live is supported for low-risk cases where the validation window can be compressed — but a staging-first run pays back the time on every migration above the smallest size.

The import lands records inside the corresponding SG-Admin modules. Pages land in the admin → Pages, blog posts land in the admin → Posts, commerce products land in the admin → STORE MANAGEMENT → Products, and any other Squarespace surface lands in the dedicated SGEN module. Imported records carry identification metadata that distinguishes them from records created directly on the SGEN side. See Import for the structural model.

6. Rebuild the page structure in SG-Builder

This is the step Squarespace migrations spend the most time on. The export carries the text and the metadata; the visual layout the source template provided does not translate into the SG-Builder component tree. The pages need to be rebuilt in SG-Builder, using the imported content as the source of record for copy and assets.

The work is template-driven. Build the page template once for each archetype the site uses — a marketing page template, a blog post template, a product detail template, an event detail template, a gallery template — and apply the template across the imported records. For most Squarespace sites, three to five SG-Builder templates cover the entire surface.

Map each Squarespace block type to the matching SGEN section. Gallery blocks become SGEN gallery sections; summary blocks become listing sections; form blocks become Form module embeds; embed blocks become the matching SG-Builder embed component; image and text blocks become the corresponding text and media sections. The block inventory from step one is the lookup table the rebuild leans on.

Newer Squarespace layouts built on Fluid Engine or the Blueprint editor often need an extra rebuild pass, since the underlying canvas model does not translate one-for-one into SG-Builder. Treat the visual reference from the source as a guide rather than a literal target — the SG-Builder rebuild gets to compose with components that match the visual intent without inheriting the layout-engine differences.

7. Walk the post-migration validation cycle, then run search-and-replace

Once the import lands and the SG-Builder rebuild is complete on staging, walk the Post Migration validation cycle before treating the staging site as ready to promote. The cycle confirms imported records render as expected, internal links resolve, media displays, custom fields landed correctly, and site-wide settings carry the intended values.

A Squarespace export carries the source site's asset CDN URLs verbatim. After the import lands on SGEN staging, run a Search and Replace pass to rewrite the Squarespace CDN URLs to the SGEN equivalents, fix any embedded references, and clean residue that the import preserved verbatim.

Typical replacements include:

Squarespace asset CDN host → SGEN media host (https://images.squarespace-cdn.com/... → the SGEN media equivalent)
Old custom domain → new domain (https://oldsite.com → https://newsite.com)
Squarespace form action paths → SGEN form submission paths (handled inside the form module when the forms are rebuilt, not by string replacement)
Inline analytics, chat-widget, or scheduling-embed snippets that have a first-party SGEN module equivalent — the snippets can be replaced with the module's embed pattern, or stripped if the module renders the same behaviour natively.

Run the search-and-replace pass on staging first. Spot-check the affected pages before confirming the pass landed cleanly.

8. Rebuild forms, commerce, redirect map, then promote staging to live

Squarespace Forms route to the Squarespace inbox by default, with optional integrations. After the import, the form structures land as static markup but the submission path no longer exists. Rebuild each form in SGEN's the admin → Forms module, recreating the field set, the submission destination (email notification, custom object record, integration, or webhook), and any per-form behaviour the source used.

If the source ran a Squarespace Commerce storefront, the products imported as catalogue records in step five — but the orders, customers, and payment-gateway connection need a deliberate cutover. Configure the SGEN payment gateway, import the customer CSV through the commerce module's customer importer, decide whether to bring historical orders across or leave them archived on the Squarespace side, and plan a cutover window that minimises the time orders could land on either platform.

Build the redirect map next. The Squarespace URL structure (especially the /s/ shape on older templates and the per-collection URL templates on newer ones) and the SGEN URL structure may not match exactly. Capture every source URL the redirect map needs to cover (use the URL Mappings export from step one, plus any inventory of external incoming links), and configure the redirects through the SGEN redirect surface.

Once validation passes, the search-and-replace pass is clean, the forms and commerce are rebuilt, and the redirect map is in place, promote the staging site to live through the standard staging-to-live promotion path. Capture a fresh backup of the live target before promotion, so the rollback point survives the promotion event.

After promotion, run a final post-promotion validation pass — the live site sometimes behaves differently from staging because of DNS, caching, or per-environment configuration. The final pass closes the migration.

What success looks like

A successful Squarespace to SGEN migration ends in a verifiable state on the live site. The following observable outcomes anchor the success criteria:

Every page that existed on the Squarespace source resolves on the SGEN site, either at the same path or at a documented rewrite.
Every blog post is published under the correct date, author, category, and tag set.
Every image, video, and downloadable file referenced in content renders from the SGEN media surface, not from the Squarespace CDN.
Internal links resolve to the new site, not to the old one.
Site-wide settings (logo, favicon, contact information, footer text) carry the intended values.
Forms submit and land in the intended destination — inbox, custom object record, integration, or webhook.
The commerce catalogue (if applicable) is intact, the payment gateway is configured, the customer records carry across, and a test order completes end-to-end.
The site's structured data (page titles, descriptions, OpenGraph) matches the planned values.
The visual layout reflects the planned design in SG-Builder, with the block-to-section mapping completed across the major page archetypes.

When all of the above hold, the migration is production-ready.

What to do if it does not work

Migration sometimes lands in a state the validation cycle cannot accept. The following five failure modes cover the majority of cases:

Import event fails mid-run

Open the admin → Migration event log. The platform records per-batch progress, so the failure point is identifiable. Common causes: the WordPress-compatible export is malformed (re-export from Squarespace), a commerce CSV is missing a required column (re-export from the commerce panel), or the asset archive is incomplete (re-package the asset directory). Reopen the import wizard and resume from the failure point.

Imported pages render with content but no visual structure

The Squarespace template drove layout; SGEN drives layout through the SG-Builder. After import, pages will often carry the text and the references to media without the surrounding visual structure the template provided. The fix is the template-driven rebuild described in step six. For sites with consistent page archetypes, building the template once per archetype is the efficient path.

Internal links still point at the Squarespace domain or CDN

Run a Search and Replace pass scoped to the Squarespace CDN host and the old custom domain. If links remain after the pass, the issue is usually an embedded URL in a Rich Text block or a Code block that the search-and-replace pass did not cover. Identify the location, add it to the replacement scope, and re-run.

Forms submit but the submission destination is missing

A Squarespace Form imported as static markup will not post anywhere on the SGEN side until the form is rebuilt in the SGEN Forms module. Confirm the form is rebuilt with the destination configured. Submit a test entry and confirm the destination receives it.

Commerce products imported but orders or customers are missing

The WordPress-compatible export does not carry the commerce side. Confirm the product, orders, and customers CSVs were imported through the commerce module's importer (not through the main migration wizard). If a CSV failed to land, re-export from the source commerce panel and re-import through the dedicated importer.

If none of the above match the failure mode, capture the validation evidence (which pages, which behaviour, what the admin event log shows), then open the Recovery Considerations Reference to plan a rollback to the backup captured in step four.

Pitfalls

Six pitfalls catch most teams running a Squarespace to SGEN migration for the first time. Plan for them before the import event runs.

Pitfall 1 — Treating the WordPress-compatible export as the whole site

Squarespace's export tool produces a WordPress-XML-compatible file. The file covers blog posts, basic pages, and metadata — it does not cover commerce data, member-area data, scheduling data, or the layout structure of newer template-family pages. Operators who upload only the XML end up missing entire surfaces. Plan all the layers alongside each other — XML export, commerce CSVs, asset archive, member-area inventory — and confirm the import wizard receives each one in the right pipeline.

Pitfall 2 — Skipping the block inventory

Squarespace pages compose from blocks. Each block type has a corresponding SGEN section, but the mapping is per block, not per page. Operators who skip the block-by-block sweep end up rebuilding pages section-by-section during the validation cycle rather than during the planned rebuild step. The block inventory is the lookup table that turns the rebuild from improvisation into translation.

Pitfall 3 — Underestimating the template-family rebuild

Squarespace's template families (Brine, Bedford, Five, Avenue, Wells, Pacific, Fluid Engine, Blueprint) each impose a layout model that does not exist as code on the source side. The visual layout is configuration of the template, not exportable HTML. The SG-Builder rebuild composes the layout from SGEN sections, using the source as a visual reference rather than a literal target. Plan the rebuild scope based on the visual intent the source carried, not on the assumption that the layout will transfer.

Pitfall 4 — Forgetting the commerce cutover window

If the source site runs Squarespace Commerce, the migration is two halves — the catalogue, customers, and historical orders move through CSV export, while live order acceptance needs a deliberate cutover. Running both platforms accepting orders for a day causes reconciliation work later. Plan a cutover window where orders pause on the source side, the final order export runs, and the SGEN side opens for orders. Communicate the window to the team handling fulfilment.

Pitfall 5 — Forgetting the redirect map (especially for blog post URLs)

Squarespace generates blog post URLs from the post slug and the parent collection. The SGEN equivalent module may generate URLs with a different template. Pages that lived at one URL on Squarespace may live at a slightly different URL on SGEN, especially across the blog post set. Plan a redirect map before promoting staging to live, with special attention to the blog post URLs and any /s/ URLs from older template families, so external links and search-engine indexes are not orphaned at promotion.

Pitfall 6 — Not capturing the pre-import backup

The backup in step four is the rollback target. Operators who skip it because the import "should work" lose the rollback option when the validation cycle finds something unacceptable. Capture the backup every time — it costs minutes and saves the migration.

Gotchas — behaviour differences Squarespace users plan for

SGEN's architectural model differs from Squarespace's in ways that are not bug-shaped — the platform behaves a particular way by design. Plan for the following so the differences arrive as expected outcomes rather than surprises.

Squarespace blocks vs SGEN sections

Squarespace composes pages from blocks placed inside a template-defined canvas. SGEN composes pages from sections placed inside the SG-Builder component tree. The shift is from "block library inside a template" to "section library inside a builder."

For most Squarespace pages, the block-to-section mapping is one-pass — gallery to gallery, summary to listing, form to Form module embed, image to image section, text to text section, embed to embed component. The mapping is documented during the inventory pass and applied during the SG-Builder rebuild.

Template families vs SG-Builder layout

Squarespace ships templates as a structural choice — selecting a template family locks the layout vocabulary the site uses. SGEN ships SG-Builder as the layout surface — selecting components composes the layout from the section library. The behavioural shape is comparable; the surface model differs.

Operators moving from a Squarespace template family choose the SG-Builder components that recreate the visual intent. The rebuild captures the design rather than the template lock-in.

Squarespace Commerce vs SGEN ecommerce module

Squarespace Commerce ships ecommerce as part of the platform — products, orders, customers, payments, subscriptions all live inside the commerce surface, with the payment gateway configured through the commerce panel. SGEN ships an ecommerce module that covers the same ground through a different surface — products live in the admin → STORE MANAGEMENT → Products, orders live in the admin → STORE MANAGEMENT → Orders, customers live in the admin → Customers, and the payment gateway is configured through the store settings.

The capability shape is comparable; the cutover is the discrete event that hands order acceptance from one platform to the other. Plan the cutover, do not assume a same-second handoff.

Squarespace member areas vs SGEN access control + custom objects

Squarespace Member Areas gate content behind paid or free membership tiers, with the member directory and the access rules administered inside the member-area panel. SGEN's equivalent composes from the access-control surface, Custom Objects (for the member-record shape), and the per-page visibility rules. The behavioural shape is comparable; the rebuild is a deliberate step rather than an import.

If the source uses member areas, treat the rebuild as a discrete project alongside the main migration — the member records, the tier structure, the gated content, and the payment connection each need a configured destination on the SGEN side.

Squarespace scheduling vs SGEN calendar surfaces

Squarespace Acuity Scheduling integrates the booking surface inside the Squarespace platform. SGEN's calendar and booking surfaces cover similar ground through dedicated modules. The behavioural shape is comparable; the rebuild is a discrete step. If the source uses Acuity for live appointment booking, plan the calendar setup, the staff availability, the service catalogue, and the customer-facing booking page as their own configuration pass alongside the main migration.

Custom CSS and Code Injection live in SGEN's Custom Codes surface

Squarespace's Custom CSS panel and the Code Injection surfaces (header, footer, lock-page, order-confirmation) live in the Squarespace settings. SGEN's equivalents are Custom Codes for site-wide CSS and scripts, and the per-page Custom Code surface for page-specific behaviour. The scope shapes are comparable; the surface is administered through the admin rather than through the Squarespace settings.

Operators moving custom snippets from Squarespace should land them in the matching SGEN scope — site-wide snippets into Custom Codes, per-page snippets into the per-page surface.

Backups and recovery are platform-managed

Squarespace ships limited rollback through page history and the platform's internal versioning. SGEN ships backup and restore as platform capabilities, scheduled through SG-Dashboard and stored alongside the site, with on-demand backup available at any time. The behavioural shape is comparable; the surface and the scope differ.

Verification — five post-migration checks

Walk these five checks after the import lands on staging and the SG-Builder rebuild is complete, before promoting staging to live. Each is a concrete observation, not a self-report.

Check 1 — Page count, post count, and commerce count match the inventory

Compare the count of imported pages inside the admin against the count from the Squarespace inventory. Compare the post count against the source blog inventory. If the source ran commerce, compare the product, customer, and orders counts. The numbers should match. A mismatch usually points at a page archetype that did not export cleanly, or at draft content that the cleanup pass removed intentionally.

Check 2 — Spot-check page rendering across page archetypes

Open one marketing page, one blog post, one product detail page (if applicable), one event detail page (if applicable), and any other archetype the site uses. Each should render without console errors, with media in place, with internal links resolved, with the section composition matching the visual intent from the source. The spot-check covers the major archetypes; it is not a per-page review.

Check 3 — Forms, commerce, and module-backed features behave

If the source site used forms, walk one round-trip per form — submit a test entry and confirm the destination receives it. If the source ran commerce, add a test product to a cart, complete a test order, and confirm the order lands in the admin → STORE MANAGEMENT → Orders. If the source used events, scheduling, or any other module-backed feature, walk one round-trip per module to confirm the module is wired through to the imported records.

Check 4 — Search-engine artefacts survived

Page titles, meta descriptions, OpenGraph tags, and structured data should carry the values planned in the inventory. Spot-check via the page source or a structured-data testing tool. The SEO surface is one of the most common places where a migration's value erodes silently — verify it before promotion. Pay particular attention to blog post pages, where the title and description templates may need to be reconfigured inside the SGEN module.

Check 5 — Redirect map covers the blog post and `/s/` URLs

Walk a sample of the old Squarespace URLs and confirm each either resolves directly or redirects to the new equivalent. Pay special attention to blog post URLs and any older template-family URLs that use the /s/ shape. URLs that resolve to a missing-page state should be added to the redirect map before promotion, not after.

When all five checks pass, the migration is verified. Promote staging to live, capture a fresh post-promotion backup, and run the validation cycle a final time on the live site to close the migration.

Examples

Example 1 — Small portfolio site (under 30 pages, blog, no commerce)

A founder is moving a personal portfolio from Squarespace to SGEN. The site has 18 pages, one blog with 30 posts, no commerce, four forms, and a small asset library. The migration runs end-to-end in roughly a day and a half. Pre-migration inventory takes 45 minutes; the export and import event runs in under an hour; the SG-Builder rebuild of the page templates and the block-to-section mapping takes the bulk of the first day; the form rebuilds and the redirect map take the morning of the second day. Post-migration validation, the spot-checks, and the staging-to-live promotion close the migration by mid-afternoon on day two.

Example 2 — Medium service business (100-300 pages, blog, commerce light, scheduling)

An agency is moving a client service business from Squarespace to SGEN. The site has 40 pages, a blog with 120 posts, a small product catalogue (25 products) for digital downloads, an Acuity Scheduling integration for consultations, six forms, and a member area with two paid tiers. The migration runs across four to five working days. Day one is the pre-migration inventory, the block sweep, and the source cleanup. Day two is the import to staging, the commerce CSV import, and the start of the SG-Builder rebuild. Day three is the rest of the rebuild — the page templates, the block-to-section mapping, the form rebuilds, and the search-and-replace pass for CDN URLs. Day four is the scheduling rebuild, the member-area rebuild, the validation cycle, the redirect map, and the staging-to-live promotion. Day five is the post-promotion validation, the live form round-trips, and the commerce cutover.

Example 3 — Large content + commerce site (1,000+ posts, full commerce, member tiers, scheduling)

A publisher is moving a content-and-commerce site from Squarespace to SGEN. The site has 1,200 blog posts, 90 marketing pages, 300 commerce products with three years of order history, a member area with four paid tiers, an Acuity Scheduling integration with eight staff members, twelve forms, and a sizeable asset library. The migration runs across a full working week. Phase one (two days) is the pre-migration inventory, the block sweep, the commerce export, and the source cleanup pass. Phase two (two days) is the import to staging in batches, the commerce data import, the SG-Builder rebuild across the page archetypes, the form rebuilds, and the search-and-replace pass for CDN URLs. Phase three (one day) is the scheduling rebuild, the member-area rebuild, the validation cycle, the redirect map across the blog post URLs, the staging-to-live promotion, the commerce cutover window, and the post-promotion validation. The publisher schedules the commerce cutover for a low-traffic window and runs the validation cycle a final time after promotion.

Recommended timeline

The timeline below covers the work end-to-end. The variability inside each bracket is real — a content-only site with a small blog and no commerce lands at the lower end; a site with commerce, member areas, scheduling, and a long content history lands at the upper end.

Site size	Pages + posts	Commerce + members + scheduling	End-to-end timeline
Small	Up to ~50	None	One to two working days
Medium	50-500	Light commerce, optional scheduling	Three to five working days
Large	500-5,000	Full commerce, member tiers, scheduling	One to two working weeks
Enterprise	5,000+ or multi-location commerce or multilingual	Variable	Two-plus working weeks with a planned migration window

The timeline is wall-clock time including the validation cycle, the SG-Builder rebuild, and any commerce cutover window — not only the import event. The import itself is usually a single afternoon at any size; the SG-Builder rebuild, the form rebuilds, the commerce cutover, the member-area rebuild, and the redirect map account for most of the remaining hours.

Examples in context — how a Squarespace migration earns its production stamp

Migration is the entry path; validation is what closes it. The most common cause of "migration regret" on a Squarespace source is treating the export event as the finish line, then discovering during validation that the blocks did not carry layout structure, the commerce data lived in a separate export, and the blog URLs no longer resolve.

The discipline this guide leans on — inventory before exporting, capture the backup before importing, run on staging before live, rebuild the page structure in SG-Builder, rebuild the forms, plan the commerce cutover, validate before promoting — is the same discipline the Migration and Import Overview lays out at the structural level. Following it on a Squarespace migration is the difference between a migration that produces a working site on day two and a migration that produces a working site on day fourteen after three round-trips of cleanup.

The sibling guide Migrate from WordPress covers the WordPress source path, and Migrate from Webflow covers the Webflow source path. The shape is the same; the source-side specifics differ. All three guides lean on the same inventory-export-import-validate-promote discipline.

Vocabulary cross-reference

WordPress-compatible export — the .xml artefact produced by Squarespace Settings → Advanced → Import / Export Content. Carries blog posts, basic pages, and metadata; does not carry commerce, member-area, or scheduling data.
Commerce CSV bundle — the set of CSVs exported from the commerce surface (products, orders, customers). Moves through the commerce module's importer, not the main migration wizard.
Asset catalogue — the inventory of asset-library files referenced by URL on the source side. Moves alongside the content exports.
Block — a Squarespace content primitive composed inside a page. Maps to an SGEN section during the SG-Builder rebuild.
Template family — the structural choice the source site made (Brine, Bedford, Five, Avenue, Wells, Pacific, Fluid Engine, Blueprint, or others). Recreated through SG-Builder composition during the rebuild rather than transferred as code.
Member area — the gated-content surface inside Squarespace. Rebuilds through SGEN's access-control surface, Custom Objects, and per-page visibility rules.
Commerce cutover — the discrete event that hands live order acceptance from the source platform to SGEN. Planned as a window, not a same-second handoff.
Identification metadata — the trace data SGEN attaches to imported records so they are distinguishable from records created directly on the SGEN side.
Staging-first posture — the recommended discipline of importing to staging, validating, then promoting to live.
Redirect map — the table of old Squarespace URLs and their SGEN equivalents, applied at promotion time. Pays particular attention to blog post URLs and /s/ URLs from older template families.
Promotion — the operation that moves a validated staging state into live production. Distinct from the import event itself.
DNS hand-off — the discrete event of changing the host record from the Squarespace nameservers (or A records) to the SGEN equivalents.

Maintenance discipline

When SGEN's migration tooling adds support for new Squarespace import shapes (additional block type mappings, Fluid Engine layout helpers, commerce-side automation, member-area mapping), update this guide and log the change in Changelog. The guide stays valuable because the structural shape — inventory, export, import, rebuild, validate, promote — stays small. New capability lands inside that shape rather than expanding it.

When the Squarespace side changes (new template family, new editor mode, new commerce capability), revise the prerequisites and the export step rather than spawning a new guide. The single-guide discipline keeps the migration path findable for the operator running it.

On this page