Squarespace combines website presentation and commerce inside a managed platform. That integration simplifies many operations, but it also concentrates migration risk at the boundaries between Product data, Store Pages, site content, Customer identity, historical transactions, and external services. A source feature can have a familiar label while depending on code, extensions, database structures, or workflows that do not become a native Squarespace record.
A supported Product, Contact, Order, or content record can preserve information while the source Store’s behavior remains unrepresented. Products belong to Store Pages, Product types have different capabilities, and variant-level fields depend on type. Contacts connect several site relationships. Historical Orders and Transactions document past commerce while current checkout, subscriptions, tax, and fulfillment retain separate owners.
Every major risk should therefore be traced from assumption to platform constraint, migration consequence, operational impact, mitigation direction, and a control signal.
Risk context and assumptions
Squarespace does not expose the same technical ownership as a self-hosted Store. Source database tables, server-side code, checkout modifications, theme logic, and extension records cannot be assumed to have one-to-one destinations. The practical constraint is that migrated records must fit Squarespace commerce, website, content, and integration structures.
A custom source column may store a useful value while the logic that interprets it lives in code or an external service. Putting the value into an available Squarespace field preserves it only if the continuing owner can consume it. When that owner is missing, the operational loss can be an unusable filter, account rule or integration rather than an obvious import error. The catalog or application owner therefore needs a defined destination for both the value and its business use.
Control the exposure before approving broad record totals. Separate a native record relationship from site implementation and external-service work, then identify the outcome that each owner must deliver. The evidence is a usable relationship in the intended Store context, not a claim that a managed platform reproduces the source database or codebase.
| Source assumption | Squarespace constraint | Migration consequence | Operational impact | Mitigation cue | Control signal |
|---|---|---|---|---|---|
| Database fields can be recreated directly. | Squarespace exposes defined Product, Contact, Order, content, and API resources rather than arbitrary source tables. | Custom fields or relationships are flattened, excluded, or placed in the wrong owner. | Staff lose filtering, account context, or integration continuity. | Classify every nonstandard value by business owner and continuing consumer. | Each required value has a supported destination or explicit external owner. |
| Source design and code migrate with content. | Site layout, templates, scripts, and embedded services belong to the target website implementation. | Content arrives without the behavior or presentation that made it usable. | Important pages look incomplete or customer interactions fail. | Separate durable content from presentation and integration logic. | The underlying content and the replacement behavior have distinct owners. |
| A Product record is sellable by itself. | Every Product belongs to one Store Page, and visibility depends on both Product and Store Page state. | Products can exist while remaining unavailable or disconnected from the intended Store path. | Merchants see complete counts while shoppers cannot reach or purchase items. | Preserve the Product-to-Store Page relationship and intended visibility. | Priority Products are attached to the correct enabled Store Page and route. |
| Imported Orders prove operational readiness. | Orders and Transactions are historical resources; current checkout and fulfillment are configured separately. | Past commerce is readable, but new commerce follows incomplete rules. | Payment, tax, shipping, notification, or fulfillment failures appear after launch. | Keep historical evidence and live operational settings under separate ownership. | Old Orders remain intelligible without being treated as configuration. |
The managed-platform boundary is a constraint, not a defect. Risk becomes material only when the migration plan ignores which layer owns the required outcome.
Core record and relationship risks
Product types and the offer being sold
Squarespace currently distinguishes physical, service, gift-card, and download Products. These types are not cosmetic labels. Physical Products involve shipping or pickup and support variants. Service Products can represent experiences or tiers. Gift cards carry denomination and redemption meaning. Download Products involve digital goods and do not use the same variant structure.
A source Store may use one generic Product type plus applications for bookings, subscriptions, licenses, bundles, deposits, or configurable services. Mapping every source Product into the nearest Squarespace type can preserve title and price while losing the behavior the merchant actually sells.
Native Product types and API operations are different boundaries. Products API v2 can represent physical, service, gift-card, and download Products, but it cannot create or delete download Products; older API versions have different type coverage. A source offer may therefore fit a native type while the selected transfer path still lacks the required operation. Decide how the actual offer, file access, or entitlement will be recreated before counting it as covered.
The source offer must be understood before choosing its destination Product type. A service name can conceal a reservation, while a recurring price can conceal a payment and access agreement. If that relationship is reduced to a title and price, the catalog can look plausible even though scheduling, renewal or fulfillment has no functioning owner. Catalog, service and finance owners must agree on the actual offer and the separate records or configuration that keep it usable.
The controlling decision is therefore broader than type matching. Identify what is delivered, who grants access or fulfills it, and whether the chosen transfer path can perform the needed native operation. A required booking, subscription, component-stock or digital-delivery relationship with no continuing owner remains a scope gap. The table compares these exposures; it does not make a copied Product proof of the complete offer.
| Assumption | Platform constraint | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|---|
| All Products are structurally alike. | Squarespace Product types support different fulfillment and variant relationships. | Download, service, gift-card, and physical records receive inappropriate fields or behavior. | Customers encounter shipping on services, missing files, or unusable purchase choices. | Classify Products by what is delivered and which system owns access or fulfillment. | Each representative Product type follows the intended purchase and delivery model. |
| A subscription is only a recurring price. | Recurrence, entitlement, cancellation, and payment-token behavior can depend on separate services. | Product data moves while the recurring relationship does not. | Customers lose expected renewals or access, and support cannot explain account state. | Keep Product identity separate from the system that owns recurring billing and entitlement. | The continuing subscription owner recognizes the Customer and Product relationship. |
| A booking is a service Product. | Schedules, capacity, resources, deposits, and attendee records are not ordinary Product fields. | The service title and price survive but availability and reservation history disappear. | Staff cannot operate the booked service from migrated Product data. | Assign scheduling and reservation records to a compatible booking system or archive. | The booking owner can trace the Product, Customer, and reservation identity. |
| A bundle can be represented as one Product. | Component inventory and fulfillment may belong outside the Product record. | The offer is visible but component availability and reporting are lost. | Overselling and picking errors occur. | Define the component owner and preserve stable Product/variant identifiers. | The system responsible for fulfillment can identify every component. |
The affected owners include catalog managers, fulfillment teams, subscription or booking administrators, and finance. The mitigation is to retain the business object, not merely its storefront label.
Variant identity, media and stock authority
Squarespace variants can hold sellable identifiers and type-appropriate commercial fields. Physical and service Products support options and variants; gift cards use denomination variants, and downloads do not use that variant structure. Dimensions belong to relevant physical fulfillment, while the Inventory API manages physical and service variant stock, not gift-card denominations or downloads. Preserving parent values alone can lose the purchase grain, and assigning stock to every variant type can invent inventory meaning.
The target model also has hard combination limits that belong in migration risk analysis: a Product can use up to 6 Product options and 250 variant combinations. Source Products above those boundaries require an explicit redesign or scope decision before migration; preserving the source option labels without resolving the combination model does not make the Product launch-ready.
Variant identity is the link between the buyer’s choice and the commercial values used by operations. If child SKUs become descriptive text or parent-only values, a selected choice can retain its label while pointing to the wrong price, image, stock rule or fulfillment data. That failure affects catalog and fulfillment owners together, and an external stock feed can amplify it by updating an incorrectly matched record.
Keep the sellable grain and the availability rule explicit. A tracked physical item, an unlimited service and an externally maintained quantity do not have the same stock meaning, even when each displays a number. The control is a consistent Product-type, variant and inventory-owner relationship; the evidence must show the intended choice and ongoing stock path rather than only an opening total.
| Risk chain | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|
| Child SKUs are combined under a parent without variant identity. | Stock, price, dimensions, and image relationships are overwritten or generalized. | Customers purchase the wrong option and staff cannot reconcile inventory. | Preserve every independently managed child as the intended Product Variant. | Variant identifiers and commercial values match the sellable choices. |
| Variant attributes are copied as descriptive text. | Size, color, tier, or denomination no longer identifies a distinct purchase option. | The Product displays information but cannot sell the intended combination. | Retain the Product–attribute–variant relationship. | The selected variant retains the SKU, price, image, and any stock meaning appropriate to its Product type. |
| Images are migrated only at Product level. | Variant-specific media relationships disappear. | Buyers select one option while seeing imagery for another. | Preserve image assignment where a source image identifies a specific variant. | Representative variants display the intended image relationship. |
| Unlimited and tracked inventory are treated alike. | Quantity values are interpreted without the source availability rule. | Valid services become unavailable, or finite items remain oversellable. | Classify tracked, unlimited, unavailable, and externally owned inventory separately. | Each inventory class follows the intended sellable behavior. |
| External stock authority is replaced by a snapshot. | Squarespace starts with a count but lacks the continuing identifier relationship. | Inventory drifts after the first external update. | Retain Product Variant and external-system keys used by the stock owner. | A continuing stock update resolves to the correct variant. |
The operational owners are catalog, fulfillment, and integration teams. The mitigation direction is to protect variant identity before considering presentation.
Discovery and storefront-scope risks
Every Squarespace Product belongs to one Store Page. Store Page state and Product visibility both influence whether the Product is available for purchase. This creates a risk chain when source Stores use several websites, departments, collections, landing pages, or visibility rules that do not map cleanly to one Store Page relationship.
The Products API does not make source Categories, navigation, and Store Page ownership one object. A Product can migrate correctly but appear in the wrong commercial context or remain hidden because the site structure around it is incomplete.
A source Category, menu entry and landing page can describe the same assortment without being the same relationship. If only the grouping is recreated, shoppers can lose the route that exposed it. If Store Page state is ignored, correct Product records may still be unavailable; if a missing menu link is mistaken for privacy, a restricted assortment may remain purchasable.
The site-commerce owner must govern the chain from Product ownership through Store Page state and public navigation. Define which separation by brand, region or operation remains necessary, then preserve the appropriate assortment and destination rather than merging by title. Evidence of control is a reachable, correctly visible assortment under the declared site context, with navigation placement assessed separately from access and purchase availability.
| Source assumption | Constraint | Migration consequence | Operational impact | Mitigation cue | Control signal |
|---|---|---|---|---|---|
| Product Categories recreate the site hierarchy. | Store Pages, Product groupings, navigation, and content routes have separate responsibilities. | Category-like data is preserved while buyer paths and landing context disappear. | Shoppers cannot find Products through expected routes. | Map catalog grouping and site navigation independently. | Priority browse paths reach the intended Store Page and Products. |
| Product visibility is one field. | Store Page enabled state and Product visibility both affect purchasability. | A visible Product remains unavailable because the Store Page is disabled, or a hidden Product is exposed incorrectly. | Revenue loss or premature publication occurs. | Define the intended Store Page and visibility state as one control chain. | Product and Store Page states produce the intended public outcome. |
| Several source Stores can be merged by Product title. | Store ownership may reflect brand, region, language, legal, or operational separation. | Distinct assortments and routes are combined without a replacement governance model. | Content, pricing, and reporting lose context. | Preserve only justified consolidation and retain external or route identifiers where separation continues. | Staff can identify the intended site context for every priority Product. |
| A Store Page is only a Product container. | It also participates in route, page, navigation, and website presentation. | Product data is complete but the commercial page lacks content or the intended site placement. | Conversion falls despite accurate catalog records. | Treat Store Page ownership as both catalog and site architecture. | The Store Page presents the intended assortment and supporting content. |
Navigation placement is a separate control. A Store Page in the Not Linked area is absent from navigation, but that placement does not make its visible Products private or prevent purchase. Removing a menu link cannot substitute for the Product visibility and Store Page state required by a restricted assortment.
This risk area overlaps with content and SEO but remains distinct: Store Page ownership is the bridge between catalog records and the public site.
Identity and access risks
Squarespace Contacts can represent Customers, mailing-list subscribers, donors, and other site relationships. Their identifiers connect Profiles and Order Customer links, and email uniqueness within a site is a matching constraint. Primary email, reusable addresses, and structured marketing preferences have different meanings. A source duplicate or shared-email case therefore needs an explicit identity decision rather than an assumption that every account becomes a separate Contact.
This richer model creates several risk chains. A source Customer table may include guest buyers, subscribers, duplicate accounts, organization contacts, old addresses, and consent records that should not be collapsed into one generic Customer import.
Identity errors can propagate without changing the Contact count. When a shared email or duplicate source profile is resolved incorrectly, Orders, reusable addresses and marketing preferences can attach to the wrong person. A guest transaction, newsletter relationship and registered account may also need different continuing treatment. Customer operations and marketing owners therefore need the source identity and relationship evidence before approving a match.
Separate what identifies the person from what authorizes communication or describes a past delivery. Preserve the source-to-target Contact link and the intended current address-book data while keeping Order-time addresses and consent provenance distinguishable. A correct match is supported by the person’s business relationships; email uniqueness is a platform constraint, not permission to merge every source record that shares an address.
| Assumption | Squarespace constraint | Migration consequence | Operational impact | Mitigation cue | Control signal |
|---|---|---|---|---|---|
| Email alone is a neutral matching key. | Contacts are unique by email within a site, while source systems can contain duplicates or shared addresses. | Unrelated people merge, or one person’s Orders and consent attach to another profile. | Support, marketing, and analytics become unreliable. | Resolve duplicates and shared-address cases through source IDs, Orders, names, and external keys. | High-value and ambiguous Contacts map to the intended identity. |
| Every Order address belongs in the Contact address book. | Historical Order addresses and reusable Contact addresses have different lifecycle meaning. | Old or one-time addresses become current account data. | Customers and staff see misleading delivery information. | Keep Order snapshots separate from reusable address-book relationships. | Current addresses and historical Order addresses remain distinguishable. |
| A subscriber is equivalent to a Customer account. | Contacts can originate from account registration, guest checkout, donation, newsletter signup, or API creation. | Marketing-only records gain unsupported account meaning. | Lists and account expectations become confused. | Preserve the origin and continuing use of the Contact relationship. | A Contact’s buyer, subscriber, or donor context remains understandable. |
| Marketing consent is an ordinary boolean. | Preference state includes opt-in/out meaning and timing. | Imported Contacts may be treated as marketable without valid provenance. | Compliance and campaign targeting are weakened. | Preserve only supported consent information with clear source and purpose. | Marketing systems can distinguish identity from permission to communicate. |
| Order history can be linked later by email. | Orders use Customer IDs that correspond to Contact identity. | Contact and Order records remain disconnected when matching changes. | Customer service and analytics lose consolidated history. | Protect the source-to-destination identity relationship during migration. | Representative Customers show the intended Order history through one identity. |
The risk is controlled when Contact identity, reusable addresses, historical addresses, marketing preference, and Order relationships retain their separate meanings.
Transaction and continuity risks
Squarespace Commerce separates Orders, Transactions, Products, Inventory, Contacts, Discounts, and other resources. Orders can represent one-time or subscription commerce, while Transactions record financial events. Historical import can preserve useful context, but it does not configure current payment, tax, shipping, discount, notification, or subscription behavior.
Historical commerce and current operating authority answer different questions. An Order total or payment label may explain a past sale, but it cannot authorize a new charge, recreate a renewal schedule or establish the opening stock position. Flattening lines, financial events or fulfillment references also leaves support and finance unable to explain a return, refund or complex purchase even though the Order is searchable.
Customer service and finance own the historical explanation; payment, subscription, inventory and fulfillment owners govern future activity. Keep those responsibilities linked through stable references without treating imported history as live configuration. The control signal is interpretable past commerce alongside a separately declared current operating model, including how retained obligations will continue without being charged or fulfilled again unintentionally.
| Source assumption | Constraint | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|---|
| Order totals are sufficient history. | Orders depend on line items, Customer identity, addresses, fulfillment, discounts, and financial events. | Staff see a number but cannot explain what happened. | Support and finance cannot reconcile complex cases. | Preserve readable line and adjustment context with stable source references. | Refund, subscription, and multi-line examples can be interpreted end to end. |
| Payment labels recreate transaction state. | Transactions are separate financial records and current gateways are configured independently. | Historical labels are mistaken for usable payment authority. | Refund and reconciliation expectations become unsafe. | Keep non-sensitive historical references and active gateway configuration separate. | Staff can trace old payments without treating them as credentials. |
| Subscription Orders recreate recurring commerce. | Recurring billing, future schedule, entitlement, and cancellation behavior need a continuing owner. | Past Orders migrate while future renewals or access do not. | Revenue and Customer expectations are disrupted. | Connect historical Orders to the continuing subscription system or archive strategy. | The system of record recognizes the intended active subscriptions. |
| Shipping history defines current fulfillment. | Historical fulfillment details do not configure current shipping or pickup rules. | The site looks complete but new Orders follow incomplete operations. | Fulfillment teams cannot rely on the target setup for new Orders. | Preserve old fulfillment evidence and define current methods independently. | Historical and current shipping responsibilities are clearly separated. |
| Imported Orders should alter current inventory. | Historical Order transfer and current Inventory Items serve different responsibilities. | Stock is decremented again or opening quantities become inconsistent. | Inventory can become overstated or understated at launch. | Establish the intended opening inventory state separately from historical records. | Order history does not change the approved opening stock position. |
The structural control is to keep historical transaction evidence separate from current payment and checkout authority. Detailed proof can then test the declared boundary without redefining it.
Content, route and presentation risks
Squarespace can hold Products, Store Pages, CMS Pages, Blog Posts, media, navigation, metadata, domains, and other website structures. Source page builders, custom code, scripts, embedded services, and plugins can contain business logic that is not ordinary page content.
A content record can arrive while its customer-facing purpose disappears. A buying guide may depend on an embedded form, a Product link or a media reference; a historical URL may depend on a Store Page or Blog route that the new site does not reproduce. Treating page HTML or file totals as completeness hides the loss until readers follow an important path.
Site, content and SEO owners must identify the durable content, route and interaction separately. Preserve the material and the references that make it usable, choose relevant destinations for priority old paths, and give any replacement block, embed or external behavior a continuing owner. The evidence is a usable route and interaction, not visual similarity or the mere presence of an image file.
| Source dependency | Squarespace constraint | Migration consequence | Operational impact | Mitigation cue | Control signal |
|---|---|---|---|---|---|
| Page HTML carries the whole page meaning. | Layout, blocks, scripts, embeds, forms, and connected services may be separately owned. | Text transfers but interactions and presentation disappear. | Lead capture, navigation, or conversion paths fail. | Separate durable content from block layout and external behavior. | Each important page has content, route, and behavior owners. |
| Source URL patterns can be retained automatically. | Product, Store Page, Blog, and CMS routes follow Squarespace site structure. | High-value paths change without continuity. | Search traffic, backlinks, and bookmarks reach missing pages. | Assign canonical destinations and redirect relationships for priority URLs. | Priority old paths resolve to the intended live resource. |
| Categories and tags are the same as navigation. | Classification, Store Page grouping, menus, and landing pages are distinct. | Content exists but discovery paths do not. | Users cannot find Products or editorial content efficiently. | Rebuild navigation around the migrated content model. | Key user journeys require no orphaned taxonomy assumption. |
| Custom code can be copied as content. | Hosted site behavior must use supported blocks, extensions, embeds, or external services. | Obsolete or incompatible code is reintroduced without a functioning owner. | Security, performance, and business interactions become unreliable. | Recreate only the required outcome through an explicit supported owner. | The business function works without depending on unexplained source code. |
| Media counts prove content completeness. | Images and files can be embedded, assigned to variants, or referenced by pages and posts. | Files exist while the relationships that display them are broken. | Products and content appear incomplete. | Preserve attachment and embedded-link relationships, not only files. | Representative pages and variants reference the intended media. |
The primary owners are site, content, SEO, and integration teams. The control signal is route and behavior continuity, not visual similarity alone.
Extension, integration and custom-data risks
Squarespace extensions and external services can own subscriptions, bookings, fulfillment, accounting, CRM, loyalty, email, Product information, inventory, and custom workflows. A similar destination extension does not guarantee a compatible data model.
An extension name identifies a component, not a compatible business schema. If source balances, schedules or operational records are flattened into notes, the continuing service may be unable to recognize them. Regenerating a key can be equally damaging when an accounting, fulfillment or CRM system still uses the original identity to find the record.
The application and integration owners must agree on the actual entity, parent relationship, stable identifier and continuing consumer. Retain useful history and matching keys while separating them from obsolete synchronization state. A custom field is controlled only when a named workflow can use it correctly; API access or a similarly named destination extension does not establish that outcome.
| Dependency assumption | Platform constraint | Migration consequence | Operational impact | Mitigation direction | Control signal |
|---|---|---|---|---|---|
| Similar extension names imply data portability. | Vendors define their own entities and identifiers. | Records are flattened into notes or duplicated in a new service. | Active balances, schedules, or workflow history disappear. | Map the source application entity to the actual continuing owner. | The destination service recognizes the intended Customer, Product, or Order. |
| External IDs can be regenerated. | Connected systems may treat existing keys as authoritative. | CRM, accounting, inventory, or fulfillment updates attach incorrectly. | Synchronization and reporting lose continuity. | Preserve durable IDs on the destination object that represents the same entity. | A lookup from the external system resolves to the intended Squarespace record. |
| A custom field reproduces custom logic. | Fields store values; they do not reproduce source scripts, eligibility, or automation. | Data arrives without the business rule that interprets it. | Staff see unexplained values and Customers lose expected behavior. | Assign the behavior and the value to explicit owners. | The continuing workflow consumes the migrated value correctly. |
| Historical integration state belongs in core commerce. | Sync cursors, event IDs, export flags, and app state are operational integration records. | Technical residue pollutes Products, Contacts, or Orders. | New integrations misread stale state. | Retain only the integration keys and history that have continuing value. | No active workflow depends on abandoned source-state fields. |
| API availability guarantees equivalence. | APIs expose supported resources, not every source relationship. | Teams overestimate what ordinary Product, Contact, or Order migration can represent. | Scope gaps surface after site implementation. | Evaluate resource ownership and business semantics before mapping. | Every required external relationship has a named destination owner. |
The risk is controlled through a dependency ledger that distinguishes native Squarespace resources, extensions, site implementation, and external systems.
Risk priorities, owners and controls
Resolve the constraints that determine the operating model before treating later controls as sufficient. Product type and sellable identity come first because Store Page exposure, stock and fulfillment depend on them. Contact matching must be resolved before historical Orders and communication preferences can be trusted. A continuing service or external system needs its identity and record contract before its workflow is reactivated.
Assign priority by the business outcome that would fail. An offer that cannot be represented, an ambiguous Customer identity or an active obligation without a continuing owner can block the affected launch scope. A declared replacement, archive or exclusion changes that scope; assigning an owner without a workable outcome does not remove the constraint. The final matrix collects those responsibilities and their control signals after every risk domain has been developed.
| Risk domain | Primary owner | Business impact if uncontrolled | Mitigation direction | Control signal |
|---|---|---|---|---|
| Product type and variants | Catalog owner | Unsellable or misrepresented offers | Define Product type, variant grain, digital or service owner, and image relationships. | Representative Products preserve intended purchase behavior. |
| Store Page and visibility | Site-commerce owner | Products exist but cannot be found or purchased | Map Product ownership, Store Page state, and route separately. | Priority Products are reachable through the intended Store Page. |
| Inventory | Fulfillment or inventory owner | Overselling, unavailable Products, or external drift | Protect variant identity and continuing stock authority. | Opening and continuing stock resolve to the intended variant. |
| Contacts | Customer operations owner | False merges, consent errors, broken Order history | Define identity, addresses, preference, and Order linkage. | Ambiguous Contacts and high-value Customers resolve correctly. |
| Orders and Transactions | Customer service and finance | Unreadable history or unsafe payment assumptions | Preserve transaction evidence while separating current operations. | Complex historical cases can be explained without source access. |
| Site content and routes | Site and SEO owner | Broken discovery, traffic loss, incomplete pages | Assign content, navigation, route, media, and redirect ownership. | Priority paths and interactions reach usable destinations. |
| Extensions and integrations | Application owner | Orphaned workflows and broken synchronization | Preserve entities and stable keys under the continuing owner. | External systems recognize the migrated parent records. |
This matrix keeps the analysis focused on structural exposure. The risk owner and control signal state the condition that must be governed, and all subsequent work can follow that declared ownership.
Conclusion
Squarespace migration risk is created by mismatched ownership. Product types, Store Pages, variants, Inventory Items, Contacts, Orders, Transactions, site content, routes, and extensions each control different parts of the operating model. A record can migrate accurately while the selling behavior, Customer identity, route, or external workflow remains incomplete.
The strongest controls separate Product records from subscriptions or bookings, Store Page ownership from navigation, Contact identity from marketing preference, historical Orders from current operations, content from site-builder behavior, and native resources from extensions. Those distinctions convert broad warnings into complete risk chains with responsible owners and observable control signals.
Use these ownership and control decisions in Squarespace Pre-Migration Preparation Checklist to gather the evidence needed for the affected scope.
Common Questions
What is the largest structural risk in a Squarespace migration?
A central structural risk is treating migrated Products and content as a complete recreation of the source Store. Squarespace also requires correct Product types, Store Page ownership, variant and inventory relationships, site routes, Contacts, and external-service ownership. Prioritize the missing relationship by the actual purchase, identity, route, or continuing obligation it would prevent; one universal ranking does not replace that business assessment.
Why can a Product exist but remain unavailable for purchase?
Each Product belongs to a Store Page, and both the Product’s visibility and the Store Page’s enabled state affect purchasability. Correct Product data does not compensate for the wrong Store Page relationship or visibility state.
How do Product types change migration risk?
Physical, service, gift-card, and download Products differ in variants, fulfillment, stock, and digital access. Native type support also differs from the API operations available to a transfer path. A matching type name does not prove that the complete offer or entitlement can be recreated.
Why are Squarespace Contacts more than Customer records?
Contacts can represent Customers, subscribers, donors, guests, and other people associated with the site. Identity, address books, marketing preferences, and Order relationships must remain distinct to avoid false merges and consent errors.
Do imported Orders recreate subscriptions, payments, and fulfillment?
No. Orders and Transactions preserve historical commerce. Active subscriptions, gateways, tax rules, shipping, notifications, and fulfillment remain owned by current Squarespace or external-service configuration.
When does an external service create the highest migration risk?
Risk is highest when the service owns active balances, schedules, entitlements, inventory, or identifiers that cannot be represented by ordinary Squarespace fields. The continuing service must recognize the same Product, Contact, or Order relationships after migration.
Does native Product-type support mean every migration path can create the same Squarespace offer?
No. Type, API version, and operation must be qualified together. For example, Products API v2 can represent download Products but cannot create or delete them. The required digital access or service behavior also needs a continuing owner.
Does removing a Squarespace Store Page from navigation make its Products private?
No. Not Linked controls navigation placement. Purchase availability still depends on the Product’s visibility and Store Page’s enabled state. A restricted assortment needs explicit visibility and access decisions rather than a missing menu link.