Square validation must prove that migrated records work inside Square’s catalog, location, inventory, Customer, Order, and online-site relationships. A matching item count is useful for reconciliation, but it does not prove that the correct variation can be sold, inventory belongs to the intended location, modifiers remain distinct from variants, Customers can be found, historical Orders remain understandable, or Square Online presents the intended catalog and routes.
The proof model should separate migrated data from live Square configuration. Historical Orders can preserve line items, adjustments, fulfillment context, and payment references without configuring current payments or fulfillment. Catalog records can be complete while Square Online navigation, pickup, delivery, shipping, domains, or page presentation still require target-side work. Launch approval depends on both the migrated evidence and an assigned owner for every unresolved configuration or implementation item.
Define the Square Validation Evidence Set
Square validation should begin with representative records that expose the platform’s relationship model. Easy examples confirm baseline transfer, while difficult examples reveal whether the migration preserved the structures that staff, inventory processes, Customer support, and connected systems actually use.
The representative test evidence set should include, where relevant:
- a simple catalog item with one sellable variation;
- an item with several option-defined variations;
- an item that uses modifiers rather than inventory-bearing variations;
- a variation with location-specific inventory;
- a Category-sensitive or image-heavy item;
- a Customer with several Orders or group/custom-attribute context;
- a guest or weakly identified buyer;
- an Order with discounts, taxes, service charges, tips, fulfillment, refund, or external references;
- a high-value Square Online item or Category route;
- an application-owned or external-system identifier.
| Evidence type | representative migration test proof | broader migration execution proof |
|---|---|---|
| Catalog | Representative items, variations, options, modifiers, Categories, images, taxes, and discounts retain the intended roles. | The complete catalog follows the approved item and variation structure without unexplained exceptions. |
| Inventory | Selected variations show the intended quantity, state, and location relationship. | All in-scope variation-location quantities reconcile with the approved opening inventory model. |
| Customers and Orders | Difficult Customer and Order examples remain linked and readable. | Complete historical scope, exclusions, duplicates, and relationship exceptions are reconciled. |
| Square Online | Priority item, Category, content, domain, and route examples reach the intended destinations. | All priority routes and in-scope content have an approved outcome and owner. |
| Integrations | External IDs and application-owned records have defined owners and testable consumers. | Every included integration key and custom output reconciles across the complete scope. |
Representative testing should expose assumptions before broader migration execution. It should not be approved merely because simple Products and recent Orders look correct.
Validate Items, Variations, Options, and Modifiers
Square’s item library distinguishes the general item from the item variation that is sold. Item options can standardize variation attributes such as size or color. Modifiers represent sale-time additions or preferences and do not automatically create a separate stock-controlled identity. Validation must prove that the migrated structure reflects those distinctions.
| Catalog relationship | Pass evidence | Watch signal | Block signal |
|---|---|---|---|
| Item and variation | Parent item and sellable variation remain linked; SKU, price, image, measurement, and identifiers belong to the intended variation. | Minor naming or display-order cleanup remains. | Variation identity is collapsed, duplicated, or linked to the wrong item. |
| Item options | Option values generate or describe the intended variation combinations consistently. | Labels or ordering need target-side normalization. | Buyers cannot select the correct sellable combination. |
| Modifiers | Optional additions and preferences remain separate from inventory-bearing variations. | Display or grouping needs configuration. | A modifier became a false SKU, or a true variation became a non-stocked modifier. |
| Categories and images | Items appear in the correct Categories and retain primary, gallery, or variation-specific image meaning. | Low-priority media ordering needs adjustment. | Priority Products are hidden, misclassified, or missing essential images. |
| Taxes and discounts | Included catalog relationships attach to the intended items and historical Orders remain financially understandable. | Current rule configuration is still assigned to a target owner. | Migrated values produce incorrect visible prices or make historical totals unintelligible. |
Validation should also check editability. Staff must be able to identify the correct Item and variation, understand which values are shared and which are variation-specific, and update the intended record without creating duplicate commercial identities. Include at least one Product where modifiers and options coexist, because the storefront may look correct even when staff cannot tell which selection changes inventory, price, or only the sale-time preference.
Validate Inventory by Variation and Location
Square inventory is tracked for item variations and can be location-specific. A Product-level quantity is therefore insufficient when the source Store used child SKUs, branches, warehouses, or separate stock pools. The proof must connect the quantity to both the sellable variation and the intended Square location.
For representative stock-bearing records, confirm:
- the correct item variation is stockable;
- SKU and external inventory keys identify the same sellable unit;
- the quantity appears at the intended active location;
- unlimited, untracked, zero, reserved, damaged, returned, or other source states have an approved Square meaning;
- a sale or return would affect the intended variation and location rather than a parent item or another branch;
- an ERP, warehouse, or channel integration can still identify the destination variation when that system remains authoritative.
| Finding | Launch interpretation |
|---|---|
| Quantity differs only because the approved opening-inventory timestamp changed | Watch, provided the difference is explained and the final cutover rule is owned. |
| Quantity is correct but assigned to the wrong location | Block, because operational availability and fulfillment ownership are wrong. |
| Parent total matches but variation quantities do not | Block, because the sellable units cannot be trusted. |
| External stock key is present but no longer recognized by the inventory authority | Block until the key or integration mapping is corrected. |
| A non-stocked service is intentionally not inventory-tracked | Pass when the intended availability behavior is documented. |
Inventory validation should not trigger duplicate stock changes from historical Orders. The imported Order is evidence of past commerce; the approved opening inventory is the current operational state.
Validate Square Online, Categories, Search, and Routes
Square catalog validation and Square Online validation are related but separate. An item can exist in the item library while remaining unpublished, difficult to find, assigned to the wrong Category, or disconnected from the intended online route. Square Online pages, navigation, domains, URLs, redirects, pickup, delivery, shipping presentation, and site publication therefore require their own evidence when they are part of the target scope.
Use a priority-route register covering revenue Products, important Categories, campaign destinations, policy pages, content pages, and externally linked URLs. For each route, record the expected Square Online destination and classify the result as direct resolution, single relevant redirect, approved retirement, or unresolved failure.
Pass evidence includes:
- priority items and Categories are visible in the intended online context;
- Category membership and navigation lead to the expected Product set;
- search or browsing exposes representative items through the intended labels and options;
- images, descriptions, pricing, availability, and fulfillment presentation are coherent;
- domains and publication state point shoppers to the intended site;
- priority old URLs resolve to a relevant destination without loops or unrelated redirects.
A missing menu link is not automatically a migration defect, and a migrated Category does not automatically recreate site navigation. The launch record should distinguish migrated data corrections from Square Online configuration and design work.
Validate Customers and Historical Orders
Square Customer profiles can hold contact information, group relationships, reference IDs, custom attributes, and links to Orders. Validation should prove identity continuity without creating false merges or unnecessary duplicates. Email and phone are useful evidence, but guest purchases, shared contact details, changed addresses, and external CRM IDs can require additional matching context.
Customer proof should cover:
- registered and guest buyers;
- duplicate or near-duplicate identities;
- addresses and company information;
- group, segment, consent, loyalty, or custom-attribute context where included;
- external Customer IDs used by a CRM, accounting system, loyalty service, or support workflow;
- links from Customers to representative historical Orders.
Historical Order proof should include line items, variation references or snapshots, modifiers, quantities, prices, discounts, service charges, tips, taxes, Customer links, addresses, source, location, fulfillment, refunds, and external IDs where they are in scope. Staff should be able to answer who bought what, at which location, under which Order, with what financial and fulfillment context.
| Evidence result | Status |
|---|---|
| Order totals reconcile and line-item meaning is clear, while current gateway configuration remains separate | Pass |
| Payment label is readable but an external transaction reference needs owner confirmation | Watch |
| Orders exist but line items point to the wrong variations or Customers | Block |
| Historical fulfillment is present but live pickup or delivery configuration is incomplete | Watch or Block according to launch dependency, owned by target implementation rather than migration correction |
| Refund or adjustment history materially changes the financial outcome but is missing or misleading | Block |
Historical Orders do not prove that current checkout, payments, taxes, fulfillment, notifications, or inventory behavior is ready. Those live workflows require separate target-side evidence.
Validate Content, Custom Attributes, Apps, and External Systems
Square migrations can include custom attributes, reference IDs, application-owned fields, loyalty or gift-card references, accounting keys, delivery records, marketplace identifiers, or other external data. Each included value needs a defined parent entity and a continuing consumer.
Use a traceable record for every nonstandard requirement:
| Required field | Evidence |
|---|---|
| Source owner and example ID | Identifies the exact source record and system. |
| Square destination | Names the item, variation, Customer, Order, line item, site record, or application object that owns the value. |
| Transformation | Explains any normalization, combination, or restructuring. |
| Continuing consumer | Identifies the staff workflow, API, app, ERP, CRM, warehouse, or report that uses the result. |
| Pass condition | Defines the result that proves the value remains usable. |
Approved migration outputs should be checked against the purchased filtering, mapping, or configuration request. non-standard migration outputs should be checked against the agreed custom specification. Validation must not expand the accepted scope into unrelated Square implementation, application installation, design, or integration deployment unless those deliverables were expressly included.
When an integration remains active, verify the identifiers and relationships through the connected workflow. The presence of an ERP key in Square is not sufficient if the ERP can no longer find the variation; an Order reference is not sufficient if accounting cannot reconcile it; a loyalty ID is not sufficient if the loyalty account is disconnected from the Customer.
Revalidate After Later Migration Actions
A previously approved result does not automatically cover later source activity or configuration changes. Revalidation should follow the exact action used:
| Migration action | Required revalidation focus |
|---|---|
| continue under the accepted configuration | Prove that newly eligible records follow the previously approved filters, mappings, item/variation model, location ownership, and integration keys. |
| continue under revised configuration | Revalidate every area affected by changed filters, mappings, data type selection, or supported configuration, including previously approved assumptions that no longer apply. |
| produce a distinct new migration result | Treat the new migrated result as a separate evidence set; rerun catalog, inventory, Customer, Order, content, integration, and launch-decision checks. |
For each action, compare affected records with the previous approved result and confirm that unchanged records remain stable. Record the changed Items, variations, option sets, modifiers, location assignments, Customers, Orders, routes, custom attributes, and external app references, then repeat the buyer, staff, and integration scenarios that depend on them. Focused sampling is acceptable only when the last-used configuration and Square object relationships remain unchanged. A new configuration or distinct migration result requires a broader evidence baseline. Newly migrated Products, Customers, Orders, and Blog Posts should be reconciled with their relationships rather than checked only as additional counts.
Apply Pass, Watch, and Block Launch Decisions
The final decision should be evidence-based and owned. Every material finding should identify the affected record or workflow, the responsible owner, the required correction, and the recheck condition.
| Decision | Square interpretation |
|---|---|
| Pass | The migrated result is correct and usable for its intended Square purpose. |
| Watch | A nonblocking correction, configuration item, or owner decision remains, with a recorded due date and recheck. |
| Block | The issue would materially affect selling, variation identity, inventory, Customer continuity, historical Orders, financial context, priority routes, fulfillment, compliance, or agreed custom output. |
Square is ready for launch only when all Blocks are closed, Watch items have accountable owners, due dates, and defined rechecks, and the evidence covers both migrated records and required target-side behavior. The decision record should name the exact Item, variation, option set, modifier, location, Customer, Order, route, and external workflow tested. It must also distinguish historical Order evidence from current catalog publishing, location inventory, payment, tax, fulfillment, Square Online presentation, and app configuration. A catalog count, successful login, or clean storefront screenshot cannot replace this decision record.
Conclusion
Square validation must prove connected commerce behavior across catalog items, variations, modifiers, location inventory, Customers, historical Orders, Square Online, and external systems. representative testing should expose difficult relationships; Broader migration execution should reconcile the complete approved scope and its exceptions.
The launch decision is credible when migrated data and target-side configuration are separated, supported and tailored outputs are tested against agreed requirements, later migration actions receive proportionate revalidation, and every finding resolves to Pass, Watch, or Block with an accountable owner.
Common Questions
What should be validated first after Square Representative Testing?
Start with the records that expose Square’s relationship model: an item with several variations, a modifier-based item, location-specific inventory, a Customer with linked Orders, an Order with financial or fulfillment adjustments, a priority Square Online route, and an external identifier used by a continuing system.
Are matching item and Order counts enough to approve a Square migration?
No. Counts can reveal missing records, but they do not prove correct item–variation structure, location inventory, Customer links, Order-line meaning, Square Online visibility, or integration continuity.
How should Square inventory be validated?
Validate quantity and state at the item-variation and location level. Confirm that the same variation is recognized by staff and any continuing ERP, warehouse, channel, or reporting system.
Do migrated Orders prove that Square payments and fulfillment are ready?
No. Historical Orders preserve transaction evidence. Current payment, tax, pickup, delivery, shipping, notification, and fulfillment behavior requires separate target-side configuration and proof.
How should Agreed Adjustment or Tailored Migration outputs be approved?
Check approved migration adjustments against the purchased bounded filtering, mapping, or configuration result, and check non-standard handling against the agreed custom specification. Do not approve either against an undefined expectation of complete Square implementation.
What must be revalidated after a later Square migration action?
Revalidate the records and relationships affected by the selected action. A new configuration requires focused checks on every changed mapping or filter, while a new migration requires a new end-to-end evidence set.