Moving commerce data into Square is not a field-copying exercise. Square represents a merchant’s catalog, stock, Customers, and transactions through connected objects that serve different operational purposes. A source Product may become a catalog item with one or more item variations. A selectable value may define an item option, a sellable variation, a modifier, or buyer-supplied information. Inventory belongs to a specific variation and location context. A historical Order preserves what happened, but it does not become the configuration that controls future payments, fulfillment, taxes, or online presentation.
The central translation question is therefore not whether Square has a field with a familiar name. It is whether the destination record is owned by the correct Square object and remains connected to the records that give it commercial meaning. When those relationships are preserved, staff can sell the correct variation, understand stock by location, find Customers and Orders, reconcile external identifiers, and publish coherent Square Online content. When they are flattened, the data may look complete while behaving incorrectly.
Square Data Meaning Is Built From Related Commerce Objects
Square’s catalog is composed of typed objects rather than one universal Product record. Catalog items describe products or services. Item variations represent purchasable versions. Item options can standardize the values that define variations. Modifier lists describe sale-time changes or additions. Categories organize items. Taxes, discounts, pricing rules, images, measurement units, and custom attributes can participate in the wider catalog relationship.
A source platform may store several of those meanings in one Product table, one configurable Product, or an application-owned structure. Translation requires separating the source record into the destination objects that actually own each behavior.
| Source-store assumption | Square relationship meaning | Translation consequence |
|---|---|---|
| One Product row is the complete sellable unit | The item and its item variation can be separate but connected objects | Preserve the parent item while assigning SKU, price, stock, and other sellable identity to the correct variation. |
| Every option is a variant | Some choices define variations; others are modifiers or buyer input | Classify the commercial effect of the choice before creating destination records. |
| One stock number belongs to the Product | Inventory is tied to item variation and location context | A quantity is incomplete without its sellable variation and operational location. |
| Categories recreate the whole storefront | Catalog Categories and Square Online site structure are connected but not equivalent | Preserve catalog classification separately from pages, navigation, and URL presentation. |
| Customer history recreates account behavior | Customer profiles preserve identity and commerce relationships, not every source login or membership model | Keep durable Customer data separate from source-specific access and application behavior. |
| Imported Orders configure future selling | Orders record historical or current transactions; configuration remains owned by payment, fulfillment, tax, and other Square settings | Preserve the transaction snapshot without treating it as operating configuration. |
This object-based view also explains why external identifiers matter. A source Product ID, warehouse key, CRM Customer ID, or accounting reference should attach to the Square object recognized by the connected system. A generic note on the parent item is not an adequate replacement for a variation-level warehouse identifier if the warehouse treats each variation as a separate stock item.
Items, Variations, Options, and Modifiers Carry Different Selling Meaning
The most important catalog distinction is between the item and the item variation. An item describes the product or service family. A variation identifies a purchasable version and can carry its own SKU, price, measurement, image relationship, and inventory meaning. Even a source Product with no visible options may become one Square item with one default or sole variation because the variation is the sellable object used by other Square relationships.
Item options provide a standardized way to describe variation attributes such as size, color, or style. A variation can reference the selected option values, allowing Square to understand the combination rather than relying only on an inconsistent display name. Source variants should therefore be interpreted through both their parent Product and the values that make the sellable combination distinct.
Modifiers are different. They represent a change or addition selected during a sale and do not automatically define a separate stocked identity. Extra cheese, gift wrapping, preparation preference, or an optional service can be modifier-like. A size with its own SKU and inventory is usually variation-like. Treating a modifier as a variation creates false stock records; treating a true variation as a modifier removes the sellable identity required by inventory and external systems.
| Source pattern | Likely Square owner | Meaning that must remain intact |
|---|---|---|
| Simple Product with one SKU | Item plus one item variation | Product description at item level; sellable SKU, price, and stock identity at variation level. |
| Size and color combinations | Item options, option values, and item variations | Each purchasable combination remains distinguishable and connected to the correct parent item. |
| Optional topping or service addition | Modifier list and modifier | Sale-time choice and price effect without inventing a separate inventory-bearing SKU. |
| Engraving or buyer instruction | Modifier, custom input, Order-line note, or connected application record according to supported behavior | Customer-supplied value remains attached to the purchased line and visible to fulfillment. |
| Kit, bundle, or package | Item, component relationship, pricing rule, connected application, or external-system structure | Component identity, price formation, stock ownership, and reporting purpose are explicitly assigned. |
| Service, appointment, subscription, or digital entitlement | Catalog item plus the Square product area or connected system that owns scheduling, recurrence, or access | The catalog record remains separate from the system that controls time, billing, or entitlement. |
Images, taxes, discounts, measurement units, and custom attributes should be assigned with the same discipline. An image may belong to an item, a variation, or a Category relationship. A tax or discount may be a reusable catalog object referenced by items and Orders. A custom attribute should have a known consumer, such as staff, reporting, an integration, or another Square workflow. Values without a destination owner create noise rather than preserved business meaning.
Categories, Menus, Images, and Merchandising Relationships
Source Categories often perform several jobs at once: hierarchy, browsing, merchandising, reporting, access control, SEO landing pages, and campaign presentation. Square Catalog Categories preserve catalog classification, while Square Online pages, navigation, and merchandising presentation can introduce separate site relationships. A migration should preserve the durable classification purpose without assuming the old storefront tree can be reproduced by Category records alone.
A deep source hierarchy may become a flatter catalog classification combined with Square Online navigation or page structure. A source collection may be a permanent department, a temporary campaign, a filter result, or an editorial landing page. Those meanings should not be collapsed simply because all four appeared as links in the old storefront.
| Source structure | Destination ownership question |
|---|---|
| Permanent department hierarchy | Which Square Categories preserve enduring Product classification? |
| Temporary campaign collection | Is the relationship a Category, a Square Online page, a merchandising presentation, or a pricing/discount rule? |
| Brand or manufacturer grouping | Does it belong to catalog classification, a custom attribute, searchable content, or an external Product information system? |
| Technical filter | Is the value used for comparison, search, reporting, or Product selection, and which Square object or connected system owns that use? |
| Product gallery and variation image | Which image belongs to the item family, and which image identifies a particular sellable variation? |
| Menu label and landing page | Does the record point to a Category, item, Square Online page, external URL, or campaign destination? |
This separation protects both commerce and content. A Category can remain authoritative for Product classification while a Square Online page controls how that group is introduced. A menu link can point to the appropriate destination without becoming the owner of the catalog relationship. Images can remain attached to the correct item or variation even when the online layout changes.
Locations and Inventory Form an Operational Relationship
Square inventory is not a single quantity copied onto an item. It is connected to the item variation and the location at which a stock state applies. Square also records inventory through physical counts and state transitions, which means a current quantity is the result of an inventory history rather than an isolated Product field.
A source Store, warehouse, branch, stock pool, or channel may not correspond one-to-one with a Square location. Translation should identify which source quantity belongs to which destination location and which sellable variation. Combining several source warehouses into one total may be appropriate only when the destination intentionally uses one stock pool. Splitting one source total across several locations requires an authoritative allocation rather than guesswork.
| Inventory signal | Destination relationship |
|---|---|
| Product-level stock with no variants | Quantity belongs to the sole item variation at the intended Square location. |
| Variant-level stock | Each source sellable combination maps to its Square variation before stock is attached. |
| Warehouse-specific quantity | Source warehouse or branch is reconciled with the Square location that owns the quantity. |
| Reserved, damaged, returned, or in-transit stock | State meaning is retained only when the destination or connected inventory system recognizes the same lifecycle. |
| External inventory authority | Variation ID and external stock key become more durable than a one-time imported quantity. |
| Historical inventory adjustment | The record remains separate from the current physical count unless it is needed by an inventory integration or audit system. |
The authoritative-system boundary is critical. If Square will own inventory after launch, destination quantities and variation relationships must be coherent inside Square. If an ERP, warehouse system, or marketplace hub remains authoritative, Square needs stable variation and location identifiers that allow the integration to maintain stock. The imported quantity is then only an opening state, not the permanent source of truth.
Customers, Groups, Segments, and Identity Relationships
Square Customer profiles can contain names, company information, email addresses, phone numbers, addresses, notes, reference IDs, group memberships, segment relationships, marketing preference data, and custom attributes. Customer IDs also connect Customers to Orders and other Square records. Those capabilities do not make a Square Customer profile equivalent to every source account model.
A source account may also contain passwords, buyer roles, organization hierarchies, tax exemptions, loyalty balances, memberships, subscriptions, saved payment instruments, portal access, or application-owned preferences. Some of those values may belong to Square Customer data, while others belong to a Square product area, a connected application, or an external system.
Identity matching should avoid both false merges and unnecessary duplicates. Email, phone, source Customer ID, external CRM ID, Order relationship, and company context can all contribute to the decision. A shared family email does not automatically mean two buyers are one person. A changed email does not necessarily mean the Customer is new. Guest Orders should retain buyer context without inventing a permanent account relationship that did not exist.
| Source identity pattern | Square meaning |
|---|---|
| Registered retail Customer | Customer profile connected to supported contact details, addresses, groups, segments, attributes, and Orders. |
| Guest buyer | Order-level Customer context, with a permanent profile only when the destination identity rules support it. |
| Company contact | Customer profile plus company/reference data or a connected B2B/CRM owner; not automatically a full organization hierarchy. |
| Loyalty member | Customer identity connected to the Square or external loyalty record that owns balances and activity. |
| Marketing subscriber | Customer preference or marketing-system record with consent meaning preserved independently from purchase history. |
| Duplicate source accounts | Consolidated only when identity evidence, consent, Order ownership, and external references support the merge. |
The durable objective is a Customer relationship that staff and connected systems can understand. A generic imported note is insufficient when the same value should be searchable as a reference ID, structured as a custom attribute, or owned by a CRM.
Orders Preserve Transaction Relationships, Not Future Configuration
Square Orders can contain line items, item variation references, modifiers, quantities, taxes, discounts, service charges, tips, fulfillment details, location, Order source, Customer links, totals, and payment or refund context. Those relationships make historical Orders useful for Customer service, reconciliation, and reporting, but they do not configure future transactions.
The line item should preserve the Product or variation that was purchased at the time, even when the current catalog later changes. Modifier selections and buyer instructions belong to the purchased line. Tax, discount, service-charge, and tip values explain how the historical total was formed. Fulfillment data explains whether the Order was picked up, shipped, delivered, cancelled, or otherwise handled. The source and location identify where the transaction originated.
| Historical value | Square Order meaning |
|---|---|
| Source Order number | Durable reference for support, finance, and cross-system tracing. |
| Product or variation line | Purchased sellable identity, quantity, price, and descriptive snapshot. |
| Modifier or customization | Sale-time choice attached to the correct line item. |
| Tax, discount, service charge, or tip | Component of the historical total rather than a current pricing rule. |
| Payment or tender reference | Evidence of the completed or attempted transaction, not reusable payment configuration. |
| Fulfillment and tracking | Historical delivery or pickup context, not a definition of current fulfillment methods. |
| Refund or adjustment | Financial history linked to the original Order and transaction. |
| Location and source | Operational origin of the Order and the Square or external channel relationship. |
Ad hoc historical line items also require care. A source Order may reference a Product that no longer exists or an application-generated charge with no current catalog equivalent. The Order can still preserve the historical description and amount, but the record should not create an artificial current catalog item unless the merchant intends to sell it again.
Square Online Content, URLs, and Site Ownership
Square Online adds a site layer around Square commerce data. Catalog items and Categories can participate in online selling, but pages, navigation, domains, URL paths, redirects, SEO fields, policy content, Blog Posts, media placement, and custom presentation have their own site-level meaning.
A source Product URL may change when the Product becomes a Square Online item page. A source Category landing page may need a Square Online destination rather than only a catalog Category. A CMS Page can become a site page, be consolidated into another page, or remain outside the commerce site. Blog Posts, editorial collections, downloadable resources, and campaign pages should retain their content relationships and intended destination even when the visual design is rebuilt.
| Source web asset | Destination owner |
|---|---|
| Product title, description, and Product media | Catalog item and its online presentation relationship. |
| Product or Category URL | Square Online route plus any required source-to-destination redirect relationship. |
| Policy or informational page | Square Online page or another defined content destination. |
| Blog Post or editorial archive | Supported publishing destination or a separately owned content system. |
| Menu item | Site navigation relationship pointing to an item, Category, page, or external URL. |
| Theme block, custom script, or application widget | Site presentation or integration configuration, not ordinary catalog content. |
| Domain and redirect | Site and routing configuration connected to the preserved content destination. |
The content model should therefore keep authoritative commerce data separate from the site components that render it. A Product remains a catalog item even when several Square Online pages link to it. A page remains content even when it contains Product references. A redirect remains a routing relationship rather than a replacement for the destination record.
Custom Attributes, Applications, and External Identifiers
Square supports custom attributes on several object types, while many merchants also use accounting, CRM, loyalty, delivery, restaurant, retail, scheduling, reporting, marketplace, and inventory applications. The existence of a custom field in both systems does not establish that the fields have the same owner or lifecycle.
Custom data should be classified by its parent object, business purpose, authoritative system, and continuing consumer. A variation-level warehouse key belongs with the variation and warehouse relationship. A Customer CRM ID belongs with the Customer and CRM relationship. An Order marketplace ID belongs with the Order and channel relationship. A site script setting belongs to site configuration rather than a Customer or Product record.
| Custom or external signal | Correct ownership definition |
|---|---|
| ERP Product key | Item or variation recognized by the ERP, according to the ERP’s own product grain. |
| Warehouse SKU | Inventory-bearing variation plus location or warehouse relationship. |
| CRM Customer ID | Customer profile plus the external CRM that treats the ID as authoritative. |
| Marketplace listing ID | Item/variation/channel relationship, not a generic Product note. |
| Loyalty balance or membership ID | Customer plus the loyalty system that owns the ledger and status. |
| Custom Order attribute | Order or line item plus the application that created and consumes the value. |
| Square Online widget data | Site or application configuration plus references to the underlying commerce records. |
| Unsupported source table | Explicit parent entity, key, lifecycle, and destination owner before any value is retained. |
This ownership model avoids two failures: forcing every source value into the nearest Square field and preserving custom data without knowing what it belongs to. A value is useful only when teams can tell which record owns it, which system recognizes it, and whether it describes a current entity, a historical transaction, or presentation behavior.
Translation Decisions Across Common Source Patterns
The final Square destination model should be expressed as relationships rather than a list of fields. Representative patterns make those relationships visible before large-scale mapping is defined.
| Source pattern | Square destination relationship |
|---|---|
| Configurable apparel Product | Item → item options → option values → item variations → variation images/SKUs → inventory by location. |
| Restaurant menu item with extras | Item/variation → modifier list → modifiers → Order-line selections → fulfillment context. |
| Multi-warehouse catalog | Item variation → Square location or external warehouse → inventory state → external stock key. |
| Retail Customer with loyalty | Customer → contact/reference data → Orders → loyalty record owned by Square or a connected system. |
| Marketplace Order | Order → source/channel reference → line-item variation or ad hoc snapshot → payment/fulfillment history → external marketplace ID. |
| SEO-sensitive Category page | Catalog Category → Square Online destination → navigation link → source URL redirect → referenced items. |
| Custom Product configurator | Catalog item/variation → application-owned configuration → Order-line output → external fulfillment identifiers. |
These relationship chains make migration scope explicit by identifying the destination owner, the dependent records, and the external behavior that continues outside the core catalog. They also expose where one source record must become several connected Square objects. A chain is complete only when staff and connected systems can follow the item, Customer, Order, content, or external identifier through the destination without relying on the source platform to explain it.
Conclusion
Square data-model translation depends on assigning each source value to the Square object that owns its commercial meaning. Items, item variations, options, modifiers, Categories, locations, inventory, Customers, Orders, Square Online content, custom attributes, and external identifiers are connected but not interchangeable.
A strong destination model preserves the parent-child and cross-system relationships behind the data. It keeps variation identity connected to stock and locations, Customer identity connected to Orders and external references, historical transactions separate from future configuration, and Square Online presentation separate from authoritative catalog records. That structure makes the migrated data understandable and usable rather than merely present.
Common Questions
What is the difference between a Square item variation and a modifier?
An item variation is a purchasable version of an item and can carry SKU, price, image, measurement, and inventory meaning. A modifier is usually a sale-time addition, removal, or preference. The correct destination depends on whether the choice creates a distinct sellable and stock-controlled identity.
Should every source Product option become a Square item option?
No. Item options are appropriate when option values define standardized variation choices. Personalization, optional extras, buyer instructions, or application-driven choices may belong to modifiers, Order-line data, custom attributes, or another owning system.
Why does Square location matter to inventory migration?
Square inventory is meaningful for a specific item variation and location. A quantity without the correct variation and location relationship can be numerically accurate while assigning stock to the wrong operational context.
Can Square Customer profiles reproduce every source account feature?
No. Customer profiles can preserve supported identity, contact, group, segment, preference, custom-attribute, and Order relationships. Passwords, B2B hierarchies, memberships, loyalty ledgers, subscriptions, and application-owned permissions may have different destination owners.
Do migrated Square Orders configure payments and fulfillment?
No. Orders preserve line items, adjustments, location, source, payment context, fulfillment history, and other transaction evidence. Current payment, tax, fulfillment, notification, and application behavior remains separate configuration.
How should custom fields and external IDs be represented in Square?
Attach each value to the item, variation, Customer, Order, line item, site record, application, or external system that owns it. The field should also retain the key needed by the system that consumes it; placing every custom value in a generic note loses relationship meaning.