Squarespace Pre-Migration Preparation Checklist

A Squarespace Product sits inside a website and belongs to one Store Page. Preparation must establish that page relationship, the Product type, and what the selected data path can actually carry before a catalog export is treated as a complete commerce package.

Squarespace preparation should establish how the commerce catalog fits inside the broader website before any migration run begins. Each Product belongs to one Store Page, while physical, service, gift card, and download Products have different variant and inventory behavior. Contacts, Orders, Transactions, Pages, Blog Posts, navigation, extensions, and site design also remain separate record families.

Squarespace preparation should record each required action together with its accountable owner, supporting evidence, and clear ready condition. This prevents a complete Product export from being mistaken for a complete Store Page, a Contact from being treated as a subscription or member entitlement, or historical payment data from being confused with current checkout configuration.

Confirm the Squarespace Site and Store Page Model

Define the intended relationship among the website, Store Pages, Products, content, navigation, and connected systems. Record the destination site version, plan, permissions, enabled commerce features, and separately owned digital, membership, subscription, booking, or fulfillment services that the design needs. Confirm those prerequisites alongside the actual Source Store and selected workflow; a supported connection is not proof of complete Product-type or operation coverage.

The model is ready when every major commerce and content record has one intended Squarespace or external owner and each Product family has an assigned Store Page.

Prepare Access, Source Archives, and Recoverable Evidence

Collect:

• source administrator access and required Squarespace website and commerce permissions;
• dated exports or backups for Products, Customers, Orders, content, subscribers, and relevant custom data;
• Product images, downloadable files, page media, and source content archives;
• Store Page, navigation, domain, and URL inventories;
• extension, API, webhook, and external-system evidence;
• external Product, Contact, Order, and transaction identifiers;
• a source-change owner for Products, Contacts, Orders, content, and inventory during the migration window.

If an application or external system cannot provide an export, record the affected scope, evidence alternative, owner, and readiness decision. Protect dated archives and credentials and name the recovery owner. Freeze original Product and variant IDs, Store Page assignments, person IDs, Order references, URLs, and file relationships before approved transformations; new destination identifiers must remain traceable to the archived source values.

Prepare Product Types, Variants, Images, and Inventory

Squarespace supports physical, service, gift card, and download Products, but API coverage depends on the version and operation. Current Products API v2 supports variants for physical, service, and gift card Products; Download Products have no variants and can be read or updated through v2 but not created or deleted through that API. The Inventory API covers physical and service variants with tracked or unlimited stock, rather than every Product type. Prepare the actual type, file, variant, stock, and stored-value owner required by the selected workflow.

Prepare representative examples for:

• each Product type used by the business;
• simple and multi-variant Products;
• Product attributes such as color, size, or weight;
• variant SKU, price, stock, and image relationships;
• downloadable files and access expectations;
• service Products and any booking or external scheduling dependencies;
• gift card history or current balances where relevant;
• bundles, subscriptions, personalization, or extension-owned behavior;
• ERP, PIM, warehouse, marketplace, and fulfillment identifiers.

Squarespace native Product CSV import and export cover physical and service Products; that route is not a complete representation of every Product type. The export also omits additional Product information, Customer reviews, featured images, image alt text, and variant images. Archive those required records separately and assign an intended destination or approved exclusion. These native CSV boundaries do not establish the limits of every migration workflow.

The area is ready when every Product family has a type, Store Page, compatible operation, variant model, inventory treatment, media/file owner, and external key. Preserve the original stock meaning and timestamp rather than turning unlimited inventory into a guessed quantity.

Prepare Store Pages, Categories, Navigation, and Product Discovery

Every Squarespace Product belongs to one Store Page. Store Page categories and navigation, however, are separate structures. The Products API does not provide Store Page category assignments, so source evidence for Product grouping and storefront discovery must be prepared directly.

Collect:

• Store Page names, identifiers, URLs, and Product assignments;
• Product categories and merchandising groups used within each Store Page;
• main navigation, secondary navigation, footer links, and landing pages;
• filters, attributes, internal links, and campaign collections;
• high-value shopping paths and source URLs;
• redirects and retirement decisions.

Do not assume that migrating Products automatically recreates Store Page categories, menu placement, or buyer journeys. These relationships need their own evidence and owners. A Product marked visible also needs its Store Page enabled to be available for sale; prepare both states and the intended page assignment, independently of stock quantity.

Prepare Contacts, Address Books, Subscribers, and Customer Identity

The Squarespace Contacts API represents people associated with the site, including Customers, mailing-list subscribers, donors, and other site participants. Contacts can have address books and marketing preferences. The Contact ID, legacy Profile ID, and Customer ID referenced by Orders describe the same underlying site-user identity; they are not three unrelated people. Preserve the actual source relationship and distinguish saved addresses and consent from transaction summaries and Order-time snapshots.

Prepare:

• registered Customers, guest buyers, subscribers, donors, and other Contacts;
• duplicate email or identity examples;
• Contact address books and default shipping addresses;
• marketing preferences and consent evidence;
• Customer/Contact IDs used by Orders;
• account-access expectations;
• memberships, subscriptions, loyalty, booking, or CRM records owned elsewhere;
• external Contact and Customer identifiers.

Authentication and account access should be prepared separately from Contact identity. A Contact record does not by itself reproduce a source password, membership entitlement, or application profile. Confirm the exact Source-to-Squarespace access path, including verification, supported reset or activation handling, first-login expectations, and Customer communications. Keep active billing, membership access, loyalty, and scheduling dependencies with their own application owners.

Prepare Historical Orders, Subscription Orders, and Transactions

Select Orders that expose one-time and subscription purchases, Product and variant lines, Customer IDs, addresses, discounts, taxes, shipping, fulfillment, refunds, and external references. Prepare Transactions separately because financial Documents can contain payments, refunds, fees, and gateway errors related to an Order or donation.

Historical Orders and Transactions preserve past commerce, including original line descriptions, totals, taxes, discounts, refunds, dates, and addresses. Current payment processors, checkout, tax, shipping, discounts, subscription billing, and fulfillment configuration remain separate preparation owned by the responsible teams. Record how historical imports will avoid initiating new payments, recurring charges, stock changes, fulfillment, emails, or extension/webhook actions.

Prepare Content, Blog Posts, Media, Domains, and URLs

Squarespace commerce commonly sits inside a content-led website. Prepare:

• CMS Pages, Blog Posts, Store Page content, Product descriptions, and landing pages;
• authors, dates, tags, categories, media, and internal links;
• image, video, downloadable-file, and alt-text inventories;
• primary domain, secondary domains, locale, currency, and analytics ownership;
• Product, Store Page, content, Blog Post, and campaign URLs;
• metadata, canonical relationships, redirects, and retired paths;
• navigation, footer, and campaign links.

A content record is ready when its body, media, route, owner, and intended presentation layer are known. Copying text alone is not a complete preparation record.

Inventory Extensions, APIs, Webhooks, and External Systems

Create a dependency register covering fulfillment, subscriptions, memberships, bookings, email marketing, CRM, accounting, tax, shipping, reviews, loyalty, marketplace, donations, analytics, and custom applications.

For each dependency, record:

• business purpose;
• Products, Contacts, Orders, Transactions, content, or files affected;
• authoritative system and external IDs;
• export or API availability;
• configuration owner;
• continuing destination, replacement, or retirement decision;
• source evidence required before the destination workflow is configured.

The register is ready when every active extension-owned field or record has a named owner, parent entity, continuing consumer, durable identifier, and source evidence that can be recovered without relying on the storefront display alone.

Select Representative Migration Test Samples

For every sample, record the source ID, source URL where relevant, Product type, Store Page, business reason, original values and related files, intended Squarespace representation, approved exclusions, external keys, and responsible reviewer. Include a Gift Card variant or a visible-Product/disabled-page case where relevant to the selected scope. The packet must state the expected representation before the representative migration test begins.

Complete the Squarespace Readiness Gate

The gate is complete when no critical Store Page, Product type, variant, Contact, Order, Transaction, content, route, or extension decision depends on an undocumented assumption. Resolve each required gap, exclude it with approval, or hold readiness; recording an owner and due date is not sufficient.

Conclusion

Squarespace preparation should produce a website-and-commerce evidence package. Products must be assigned to the correct Store Page and Product type, variants and inventory must retain their relationships, Contacts must remain distinct from specialized account programs, Orders and Transactions must preserve historical context, and content or routes must have clear owners.

When those decisions are documented before the representative migration test, the sample set can represent the intended Squarespace site without confusing imported commerce records with site design or live checkout configuration.

Common Questions