When evaluating Square as a prospective Target Platform, the migration approach should match the required Next-Cart Migration Service, supported Add-ons where applicable, responsibility level, scope, and validation burden.
The right Square migration approach depends on what the business expects Square to operate after launch. A simple source store can still need careful planning if Square will support POS, Square Online, inventory by location, historical order lookup, payment context, customer profiles, or connected systems. A large source store can still use a straightforward approach when the records are supported, the structure is clear, and the merchant can validate the result confidently.
Service-path selection should therefore start with Square-specific evidence rather than broad labels such as “simple” or “complex.” The approach should answer whether Standard Migration is enough, whether Managed Migration gives safer execution support, whether Add-ons can handle supported record filtering, field-value transformation, or field remapping needs, whether Custom Migration is required, and what Demo Migration should prove before Full Migration.
For Square, decide scope before execution: identify the supported records, eligible enhancements or tailored requirements, then choose who performs the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
Define the Square Migration Decision
A Square migration approach is a decision about scope, responsibility, support level, and validation depth. The merchant should not choose an approach only from record counts. Square scope also depends on whether products become usable item-library records, whether variations and modifiers make sense, whether inventory depends on locations, whether order history carries readable payment and fulfillment context, whether customers remain useful for lookup, and whether Square Online is part of launch.
Start with selling identity. A Square item has at least one variation, and a variation carries the SKU, price and stock identity. A modifier expresses a purchase customization, such as an engraving request or added ingredient; it should not replace a stock-bearing size or color variation. Inventory also needs an identified location and state. If the source uses one quantity for several independently stocked choices, scope must resolve that difference before execution is assigned. Catalog presence alone does not establish live POS or Square Online readiness.
A strong approach separates four kinds of work:
| Work type | Square example | Service-path implication |
|---|---|---|
| Supported migrated records | Products, categories, customers, orders, images, and supported related fields. | May fit Standard Migration or Managed Migration depending on execution and validation needs. |
| Supported adjustments | Record filtering, field-value transformation, or field-remapping changes within supported behavior. | May require Add-ons. |
| Custom or unsupported requirements | App-owned records, custom fields requiring non-standard interpretation beyond supported mapping, external identifiers requiring unsupported handling, bespoke product logic, or unsupported transformations. | Requires Custom Migration review. |
| Square-side setup | Payments, POS hardware, staff permissions, taxes, fulfillment, shipping, pickup, delivery, domains, online layout, and connected apps. | Must be prepared in Square and validated separately from migrated data. |
This separation prevents two common mistakes. The first is assuming that Standard Migration can handle every business requirement because the record type sounds familiar. The second is escalating everything to Custom Migration when the need is actually a supported data type condition, value expression, field destination, or merchant-side Square setup.
When Standard Migration May Be Enough
Standard Migration can be suitable for Square when the migration scope is supported, the data is clean enough for customer-led execution, and the merchant can validate the result without intensive coordination. It is strongest when the catalog structure is ordinary, inventory expectations are limited or clear, order history needs readable reference value, customer profiles are not heavily customized, and Square Online setup does not dominate launch risk.
Standard Migration is not a weak option. It can be the right option when the merchant has the internal ability to prepare inputs, run or manage required steps, review Demo Migration samples, configure Square-side settings, and approve Full Migration results. The important question is whether the merchant can responsibly own those tasks for Square’s connected operating environment.
| Standard Migration readiness signal | Square-specific reason |
|---|---|
| The selected path supports the required Square items, variations, categories, images and related fields; historical tax or discount context is qualified separately. | The item library can be validated without custom transformation. |
| Product choices are simple or clearly variation-based. | The merchant is unlikely to need special handling for modifier-like or bundle-like behavior. |
| Inventory is single-location or easy to map. | Stock validation remains manageable. |
| Historical orders need lookup rather than deep payment reconstruction. | Readability is the main outcome. |
| Customer profiles are clean and mostly standard. | Duplicate, membership, loyalty, or B2B-style assumptions are limited. |
| Square Online is simple, secondary, or configured mostly after migration. | Website presentation does not create heavy launch risk. |
Standard Migration becomes less suitable when the merchant cannot explain how migrated products, inventory, customers, orders, and Square Online content should be checked. Square needs customer-side validation even when the migration path is supported.
When Managed Migration May Be Safer
Managed Migration may be safer when supported Square scope is clear but the merchant wants expert-led execution of the agreed Migration Actions. Catalog review, inventory decisions, approval timing and coordination with POS or Square Online teams still need named customer-side owners. Expert execution reduces the burden of running the migration; it does not include project management, target setup or final business acceptance automatically.
This can happen when the merchant is launching Square Online and POS together, has many variations and images, needs location-sensitive inventory review, or lacks time to perform the agreed migration actions. Those circumstances make execution ownership important. The merchant still defines samples, interprets historical orders, coordinates launch dependencies and verifies the final output. Managed Migration does not expand the supported scope.
| Managed Migration fit | Square scenario |
|---|---|
| Supported scope with many review points | Products, categories, images, customers, and orders are supported, but the merchant wants expert execution of the agreed actions and assigns business review separately. |
| Square Online launch is sensitive | URLs, redirects, SEO fields, domains, and product visibility require careful validation. |
| Inventory or locations require coordination | The merchant defines stock and location meaning; agreed migration actions can be expert-executed. |
| Historical orders have business value | Orders need careful sample review for totals, taxes, discounts, payments, and refunds. |
| Internal team bandwidth is limited | The project needs included expert-led execution of requested migration actions while the merchant verifies the result. |
Choose Managed Migration for expert execution of supported Migration Actions. Coordination, sample interpretation and launch approval remain separate responsibilities. Unsupported app data, custom fields beyond compatible supported mapping, unusual transformations and external-system logic require Custom Migration review even when expert execution is also desired.
When Custom Migration Should Be Considered
Custom Migration should be considered when Square migration needs go beyond supported standard behavior. The trigger is not simply “the store is large.” The trigger is a requirement that needs custom evaluation, custom migration logic adjustment, bespoke transformation, unsupported record handling, Custom Platform handling, external-system interpretation, or migration of data that does not fit normal Square records.
Square custom needs often appear around catalog structure, integrations, external identifiers, payment/order interpretation, customer identity, and Square Online expectations. A product may depend on source app logic. An order may contain custom fulfillment or external accounting references. A customer may carry membership, loyalty, subscription, or CRM fields. A Square Online launch may require page-builder content, scripts, structured SEO logic, or custom presentation work that is not ordinary data migration.
| Custom Migration trigger | Why it changes the approach |
|---|---|
| Custom product fields or private metadata | Supported mapping may not preserve the business meaning without tailored handling. |
| App-, plugin-, or module-owned records | Standard migration may not include data created outside the core source platform. |
| External identifiers | First test an eligible compatible supported destination for ERP, accounting, CRM, loyalty, marketplace or inventory IDs. Custom preservation is needed only when extraction, relationships or logic exceed supported handling. |
| Complex modifiers, bundles, kits, or restaurant-like choices | Square catalog meaning may require bespoke interpretation. |
| Non-standard order or payment context | Refunds, tips, service charges, external references, or reporting needs may require deeper review. |
| Custom Platform source data | The source structure itself may need custom analysis before Square mapping can be trusted. |
Custom Migration should be scoped through examples. The merchant should provide representative products, orders, customers, custom fields whose required handling exceeds supported mapping scope, integration references, and expected outcomes. Without examples, Custom Migration discussion can become abstract and hard to estimate.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the standard included file workflow covers Products only. Other required data types must be agreed explicitly. This differs from a supported platform’s File Upload connection method, and a Product export alone does not establish the complete Square scope.
How Add-ons Fit into a Square Migration
Add-ons are appropriate when the need is specific, supported, and bounded. Data Filter can limit Square items, Customers, or Orders through conditions on fields within each data type. Data Transformation can apply an expression to a supported field value, while Advanced Data Mapping can remap a supported standard source field to a different supported Square target field while keeping the value unchanged. Unsupported records, external systems, and bespoke business logic remain outside this bounded layer.
For Square, the requirement should be written as an acceptance criterion that identifies the data type condition, transformation expression, or source-to-destination field map rather than asking vaguely for “more customization.”
Square does not support Advanced Database Mapping as the selected Target. A database-capable Source does not change that Target boundary. Use compatible supported fields and Advanced Data Mapping where available; unsupported extraction or bespoke behavior needs Custom Migration review.
When several Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Filtering selects records; transformation changes supported values; mapping routes the source value, or an already transformed value, without changing it during mapping. Combining supported Add-ons does not by itself require Custom Migration. Tax is excluded from both mapping Add-ons.
| Add-on need | Square example | Boundary check |
|---|---|---|
| Data Filter | Apply supported Product, Customer, Order, or Blog Post field conditions so only matching records migrate. | Filtering should not remove records needed for service, reporting, or SEO continuity. |
| Data Transformation | Apply expressions to transform supported field values into defined Square-compatible results. | The expression must remain within supported migration capability. |
| Advanced Data Mapping | Remap supported standard source fields to different supported Square target fields while keeping the values unchanged. | Mapping cannot create unsupported Square behavior or target structures. |
| Tailored or Custom Add-on need | A Standard Add-on function needs project-specific modification, or bespoke Add-on functionality is required. | This work is reviewed and quoted through Custom Migration rather than treated as Standard Add-on scope. |
A clear boundary protects the merchant from under-scoping. If the need is “move only selected records” or “map supported fields more carefully,” an Add-on may fit. If the need is “preserve app-specific subscription logic” or “rebuild custom checkout behavior,” Custom Migration or Square-side setup review is more appropriate.
What Demo Migration Should Decide
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Square approach. Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. Use the contexts below to identify standard sample checks and requirements needing separate proof. Validate enhanced or tailored output through the agreed paid scope, and assign storefront, extension and live-operation checks to target implementation.
A good Demo Migration for Square should test:
| Sample area | Decision it should support |
|---|---|
| Simple product | Whether baseline item-library mapping is clean. |
| Variation-heavy product | Whether sellable options remain usable in Square. |
| Modifier-like product | Whether sale-time choices require another handling path. |
| Location-sensitive inventory | Whether stock meaning survives Square location assumptions. |
| Customer with multiple orders | Whether customer-order association is useful. |
| Refunded, discounted, or tax-sensitive order | Whether historical order detail remains readable. |
| Square Online URL or page example | Whether online launch assumptions are being handled separately. |
| Custom field or integration-owned record | Identify whether standard extraction and placement are supported. Add-on or Custom Migration output requires agreed paid proof; missing support may require exclusion. |
The selected approach is too light if standard Demo samples lose required item or Order meaning, or if scope review exposes unresolved location stock, Square Online implementation or custom-data ownership. Correct the affected scope or configuration before broader execution. Where an Add-on or tailored requirement is needed, obtain proof through the agreed paid activity; increasing sample volume cannot establish unsupported behavior.
Entity Points and Square Scope Planning
Entity Points plan eligible Product, Customer, Order and Blog Posts capacity when those Data Types are supported in the selected Square path. Consumption occurs on the first successful migration of an eligible counted record within the same purchased migration and fixed Source-to-Target path. Previously counted records are not charged again merely because a later action processes them; newly eligible records consume capacity when first successful. Locations, modifiers, POS and integration complexity are separate scope decisions.
For Square, this means Entity Points should be reviewed alongside operational complexity. A small catalog can need Custom Migration if Products depend on modifiers, custom fields requiring non-standard interpretation beyond supported mapping, external IDs, or unusual selling logic. A large catalog can still fit Standard Migration or Managed Migration if the data is supported, clean, and easy to validate.
| Scope signal | What it helps estimate | What it does not prove |
|---|---|---|
| Product count | Catalog volume and possible Entity Points usage. | Whether items, variations, modifiers, images, taxes, discounts, and online visibility are correct. |
| Customer count | Buyer-record volume. | Whether profiles, duplicates, guest buyers, loyalty references, and account assumptions are usable. |
| Order count | Historical order volume. | Whether payment, refund, tax, fulfillment, and external-reference context remains meaningful. |
| Blog Posts count | Content volume when relevant. | Whether Square Online URLs, redirects, SEO fields, navigation, and media are launch-ready. |
Entity Points should support planning, not replace service-path evaluation. The approach should still be chosen from data structure, support boundaries, execution responsibility, and validation evidence.
Migration Actions for Square
After an initial paid migration has produced a result, continued Source Store activity may call for further work into Square. Choose the action according to whether the recorded filters and mappings remain correct, supported configuration must change, or the target result needs a fresh basis. Demo findings inform the first paid configuration, not a paid result to continue. Square item-library structure, locations, inventory, Customers, Orders, Square Online content, URLs, and integration-linked fields should determine the revalidation scope.
| Migration Action | When it fits Square | What must be revalidated |
|---|---|---|
| Continue the Migration with Last Saved Configuration | The accepted filters, mappings, and configuration remain correct, and the main need is to process newly eligible records or later source changes. | New items and variations, Customers, Orders, content, changed inventory context, and a regression sample from earlier migrated records. |
| Continue the Migration with a New Configuration | Review of the earlier paid result or revised target requirements shows that supported filtering, mapping, content scope, Customer handling, or data configuration should change. | Every affected item family, variation or modifier interpretation, Customer field, Order field, location-sensitive value, content record, and URL influenced by the change. |
| Perform a New Migration | The previous target result should not remain the working basis, the target environment has been reset, or the scope and target assumptions have changed materially. | The complete accepted scope, replacement behavior, item-library usability, inventory meaning, Customer and Order readability, Square Online content, URLs, and custom output. |
Execution responsibility should remain explicit. Under Standard Migration and Custom Migration with Self-Execute, the customer performs available migration actions and verifies the result. Under Managed Migration and Custom Migration with Expert Handle, execution of the agreed action is included according to the customer request and accepted scope, while the customer remains responsible for final verification and the migration outcome. Square-side setup for locations, payments, tax, fulfillment, Square Online presentation, apps, and external workflows remains separate unless explicitly included in the agreed scope.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration. These actions keep the purchased Source-to-Target path and actual Store identities fixed. A different Source Platform, Target Platform, actual Source Store or actual Target Store requires a separate purchased Migration Service.
Choose the source-data window separately from the action. “Migrate only newly added entities” selects records added after the last successful run, not edits to existing records. “Continue the previous migration” applies to the appropriate previous migration state. Neither option is implied by an action name. When configuration changes, check the combined earlier and later output; a new action does not automatically erase protected target data.
Signals That the Chosen Approach Is Too Light
A Square approach is too light when it treats operational complexity as ordinary record transfer. The risk may not appear immediately in record counts. It often appears in product usability, inventory trust, order readability, customer lookup, Square Online readiness, or custom-data expectations.
| Warning signal | Likely response |
|---|---|
| Product choices cannot be classified as variations, modifiers, setup, or custom scope. | Rework catalog scope before selecting the final path. |
| Inventory depends on multiple locations or external systems that are not mapped clearly. | Strengthen preparation or consider managed/custom handling. |
| Historical orders need payment, refund, service-charge, tip, or external-reference detail beyond normal readability. | Review whether supported scope is enough or Custom Migration is needed. |
| Square Online launch depends on many pages, URLs, redirects, SEO fields, domains, or content decisions. | Include online validation and target-side setup in the approach. |
| App-owned or custom fields whose required handling exceeds supported mapping scope are business-critical. | Do not rely on Add-ons unless the data remains supported; review Custom Migration. |
| The merchant cannot validate representative samples. | Managed Migration may help execution, but acceptance criteria still need to be defined. |
| The source store continues changing close to launch without a later-action plan. | Define timing, responsibility, and revalidation before Full Migration. |
These signals should be handled before Full Migration. Delaying the decision usually makes the launch review harder because the team must separate migration defects, Square setup gaps, and unrealistic source assumptions under time pressure.
Choosing the Practical Path
The practical Square path is the lightest approach that protects the business outcome. Use Standard Migration for supported scope and customer execution, or Managed Migration for expert execution of the same supported actions. Use Add-ons for bounded filtering, value expressions or compatible field destinations. Choose Custom Migration for requirements exceeding those capabilities, with Self-Execute or Expert Handle stated separately. Assign POS, stock operations, Square Online implementation and final verification to explicit owners.
The decision should be made from evidence, not preference. A strong approach can be summarized with four statements:
- which records are expected to migrate into Square;
- which settings or workflows must be configured directly in Square;
- which Add-ons or Custom Migration requirements are in scope;
- which Demo Migration samples must pass before Full Migration.
If those statements are clear, the Square approach is usually ready to proceed. If they are unclear, the merchant should refine scope before treating service-path selection as complete.
Conclusion
Square migration approach selection should be grounded in how the business expects to use Square after launch. Standard Migration, Managed Migration, Add-ons, and Custom Migration each have a useful role, but none should be chosen from record counts alone. The right path accounts for item-library structure, variations, modifiers, inventory and locations, customer profiles, historical orders, payment context, Square Online readiness, integrations, custom data, Entity Points, later migration actions, and Demo Migration evidence. A practical approach protects both migration execution and the merchant’s ability to validate the result.
Common Questions
When is Standard Migration enough for a Square migration?
Standard Migration may be enough when the Square scope is supported, catalog structure is ordinary, inventory expectations are clear, customer and order data are straightforward, Square Online setup is manageable, and the merchant can validate Demo Migration and Full Migration results responsibly.
When should Managed Migration be considered for Square?
Consider Managed Migration when the required Square records are supported but the merchant wants expert-led execution of agreed Migration Actions. The customer retains manual access, defines business meaning and verifies the final result. Sample interpretation, launch coordination and POS or Square Online setup remain separately owned.
How are Add-ons different from Custom Migration in a Square migration?
Add-ons apply supported filtering, value expressions and compatible field routing. Square does not support Advanced Database Mapping as Target. Custom Migration is appropriate when required extraction, relationships, app-owned data or bespoke logic exceed supported capability. An external identifier alone is not a Custom Migration trigger if an eligible compatible supported field can retain it.
What should Demo Migration prove for Square before Full Migration?
Demo examines a limited sample supported by the active path, such as item and variation meaning or readable Customer and Order relationships. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. Use paid activity to prove enhanced or tailored output and separate checks for live location stock, POS, payments and Square Online behavior.
Do Square locations, inventory rules, payments, and Square Online settings become operational automatically?
No. The migration approach can preserve supported records and relationships, but live location setup, inventory configuration, payment operation, shipping, taxes, and Square Online presentation must be configured and tested separately unless specifically agreed.
Can a Square modifier replace a stock-bearing variation?
A modifier can describe a sale customization, but a variation carries the independently sellable SKU, price and stock identity. A size with its own quantity therefore needs a deliberate variation representation. Decide that structure and confirm support first; expert execution cannot repair an unqualified catalog model.
Does a Product CSV establish the full Square migration scope?
No. Selecting CSV, XLS or XML as Source Platform requires Custom Migration, whose included standard file workflow covers Products only. Customer, Order or other required Data Types need an explicit agreement. A supported platform’s File Upload connection is a different setup. Product data also does not configure Square locations, POS or Square Online.