For a move into ShopWired, separate variation stock from Product Choices, linked extras and customization inputs before choosing the Next-Cart scope. Trade pricing also depends on deliberate SKU and account ownership. Define the required representation, then choose customer-led or expert-led execution of the agreed Migration Actions.
Choosing a ShopWired migration approach should be based on how the store must operate after launch. Record volume matters, but it should not be the only decision factor. A small source store can require careful handling if it depends on complex product options, B2B pricing, custom fields, integrations, or app-owned behavior. A larger store can still fit a simpler path when its data structures are supported and validation responsibility is clear.
Define supported migrated records, separately owned ShopWired setup, eligible Add-ons, tailored Custom Migration requirements and the evidence needed before Full Migration. Limited standard Demo reveals gaps; enhanced/custom output and live operation require agreed paid or target-side proof. These decisions make scope and acceptance explicit before execution.
For ShopWired, 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.
What the Approach Decision Should Control
A ShopWired migration approach should control execution responsibility, support level, scope assumptions, configuration needs, and validation depth. It should not be selected only from convenience or record count.
ShopWired variations can carry individual stock and selling values. Product Choices provide reusable selections and price additions but do not track their own stock. Product extras can link to a stand-alone Product for stock handling; they are not simply another variation. Confirm the active apps, configuration and intended selling unit before assessing supported migration, target setup or tailored scope.
| Decision area | What to evaluate | Why it matters |
|---|---|---|
| Supported data fit | Products, categories, brands, customers, orders, reviews, coupons, CMS Pages, and other eligible records. | Confirms whether ordinary migration scope is realistic. |
| Catalog complexity | Variations, choices, extras, bundles, digital products, pre-orders, subscriptions, stock, pricing, tax, and SEO fields. | Determines whether the catalog needs simple transfer, mapping, configuration, or custom review. |
| B2B and trade behavior | Customer groups, trade accounts, pricing, restricted products, quotes, account terms, and checkout behavior. | Decides whether target setup and special validation are needed. |
| App and integration dependency | Apps, custom fields, API connections, webhooks, feeds, ERP, POS, accounting, CRM, fulfillment, and marketplaces. | Identifies data that may not be standard store data. |
| Launch ownership | Who prepares, configures, reviews, performs available actions, and validates final results. | Prevents service-path confusion during Demo Migration and Full Migration. |
The practical approach is the lightest path that still protects the outcome. Choosing too little support can expose the merchant to preventable launch risk. Choosing too much support can slow the project without adding value.
Trade pricing bands require the Trade accounts app and unique Product or variation SKU codes. A Customer label or copied price does not establish the band assignment and live price the buyer receives. Identify SKU continuity, Customer-to-band relationships and target setup ownership; native availability does not automatically establish migration coverage.
When Standard Migration Can Be Enough
Standard Migration can be appropriate when the migration is within supported scope and the merchant can confidently prepare, review, configure, and validate the target store. For ShopWired, this usually means the catalog structure is clear, product options do not require unusual transformation, customer identity is clean, historical orders are readable, and target checkout settings can be configured by the merchant.
| Standard Migration fit signal | What it usually means |
|---|---|
| Products use straightforward structures. | Product names, descriptions, images, prices, stock, categories, brands, and SEO fields can be reviewed without special interpretation. |
| Variations are ordinary and within expected limits. | Option names, values, combinations, SKUs, stock, images, and prices can be validated from representative samples. |
| Customers are clean enough to review by email identity. | Duplicate, shared, or changed email scenarios are not central to operations. |
| Historical orders are needed for reference, not complex workflow continuation. | Payment, delivery, discount, refund, tax, and note fields can remain readable without advanced transformation. |
| Target setup is merchant-owned. | Payments, delivery, tax, emails, theme, apps, and account settings can be configured separately by the merchant. |
Standard Migration is not a low-quality path. It is the correct path when the scope is supported and the merchant can handle preparation and validation. It becomes risky only when unsupported behavior is treated as ordinary data or when the merchant expects the selected service to absorb decisions outside the accepted scope.
When Managed Migration Is the Safer Path
Managed Migration fits supported ShopWired scope when experts should execute the agreed Migration Actions. Varied variation families or many historical Orders can increase execution workload without changing capability. The customer supplies business meaning, retains manual access and verifies the final result.
| Managed Migration signal | Why extra coordination helps |
|---|---|
| Catalog records are supported but numerous or varied. | Experts execute agreed actions; customer owners accept catalog, stock and SEO meaning. |
| B2B or trade behavior is important but mostly target-side configuration. | Define supported Customer data and separately owned trade behavior before agreeing expert actions. |
| Demo Migration must test several risk categories. | Customer owners select and accept available standard samples; additional review coordination needs explicit scope. |
| Launch timing is tight. | Agree action timing, source-data windows and customer verification; broader launch management needs explicit scope. |
| The merchant has limited migration review capacity. | Expert execution reduces hands-on action workload; final verification remains customer-owned. |
Managed Migration does not extend supported data coverage or automatically include project management, validation services, target setup or launch coordination. Unsupported app records, bespoke interpretation or Custom Platform handling requires tailored Custom Migration scope. Include any broader assistance expressly rather than inferring it from expert execution.
When Add-ons Should Be Considered
Add-ons are useful when the migration remains within supported capability but needs data-type-specific record filtering, expression-based field-value transformation, or source-field remapping. They should not be treated as a catch-all for unsupported app data or bespoke logic.
Advanced Database Mapping is not available with ShopWired as Target. Exact Source eligibility or API access does not override this destination limit. Confirm a supported compatible field destination for a required value; unsupported extraction, bespoke relationships or migration logic requires tailored review.
| Add-on need | ShopWired example | Correct interpretation |
|---|---|---|
| Data Filter | Apply supported Product, Customer, Order, Coupon, Review, or CMS Page field conditions so only matching records migrate. | The merchant defines the entity, field, condition, and inclusion or exclusion rule. |
| Data Transformation | Apply expressions to transform supported field values during migration. | The expression, input values, and target-compatible outputs remain within supported capability. |
| Advanced Data Mapping | Remap supported source fields to compatible ShopWired target fields. | The source and destination meanings are clear and no unsupported behavior is implied. |
For ShopWired, Add-ons are especially useful when supported records need selective inclusion, field values need defined transformation, or source fields need different destinations. They are less appropriate when the issue is app-owned logic, external-system dependency, or unsupported Product behavior.
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.
When Custom Migration Should Be Reviewed
Custom Migration should be reviewed when the migration depends on unsupported structures, app-owned data, custom fields whose required handling exceeds supported mapping scope, external identifiers, bespoke transformation, Custom Platform handling, or custom migration logic adjustment. It is not simply a more expensive version of ordinary migration. It is a review path for requirements that need direct analysis.
| Custom Migration signal | Why standard handling may not be enough |
|---|---|
| Product options do not fit ordinary variations, choices, extras, or supported configuration. | The buying logic may need transformation or rebuild guidance. |
| Bundles, kits, subscriptions, pre-orders, or personalized products carry business-critical rules. | Standard product records may not preserve the operational behavior. |
| Customer, trade, or pricing rules depend on custom fields or external systems. | The data may need mapping, enrichment, or bespoke handling. |
| Orders contain external IDs, accounting references, fulfillment references, or marketplace workflow data. | Historical readability may depend on fields not handled as ordinary order data. |
| Apps create records or logic that the merchant expects to preserve. | App-owned data is not automatically the same as platform-native data. |
| A Custom Platform is involved. | Data structures must be inspected before scope and mapping can be trusted. |
Custom Migration decisions should be example-led. The merchant should provide representative products, customer records, orders, app exports, custom fields whose required handling exceeds supported mapping scope, external identifiers, and expected output. Without examples, the discussion remains too abstract to decide scope reliably.
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 ShopWired scope.
How Demo Migration Should Decide the Path
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed ShopWired 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.
| Demo Migration sample | Decision it should support |
|---|---|
| Simple product | Confirms baseline product, image, category, brand, price, stock, and SEO handling. |
| Variation-heavy product | Checks available standard variation values and relationships; live stock, tax and purchase behavior needs target-side acceptance. |
| Product with choices, extras, or personalization | Identifies the required choice, extra or input representation; enhanced/custom output needs paid proof and target behavior needs separate checks. |
| B2B or trade customer | Checks available Customer and history context; trade band assignment, account access and live pricing need separate acceptance. |
| Complex historical order | Confirms discounts, refunds, payment labels, delivery labels, taxes, notes, fulfillment, and external references remain readable. |
| Content or SEO page | Confirms CMS Pages, blog posts, metadata, menus, and redirect assumptions are realistic. |
| App or integration-dependent record | Identifies a supported destination or gap; tailored output needs agreed paid proof and live API/app relationships remain separately owned. |
Use the limited standard result to confirm supported handling or identify an enhancement, tailored requirement or target setup gap. Hold unresolved variation, extra-link or trade identity before Full Migration. Enhanced/custom output needs agreed paid proof; app operation, live stock, trade pricing and public routes need separately owned acceptance.
Entity Points and Scope Planning
Entity Points size eligible Products, Customers, Orders and Blog Posts on their first successful migration, once within the same purchased migration and fixed Source-to-Target path. Variation relationships, choices, extras, trade pricing and integrations still affect scope without becoming additional independently counted Data Types.
For ShopWired, Entity Points should be reviewed alongside structure and complexity.
| Scope signal | What Entity Points help estimate | What they do not prove |
|---|---|---|
| Product count | Potential eligible product volume. | Whether variations, choices, extras, bundles, images, stock, tax, and SEO meaning fit. |
| Customer count | Potential eligible customer volume. | Whether email identity, trade accounts, custom fields, and order relationships are clean. |
| Order count | Potential eligible order volume. | Whether payment, delivery, tax, refund, discount, note, and external-system context remains useful. |
| Blog Posts count | Potential eligible content volume when relevant. | Whether URLs, redirects, metadata, theme placement, and content presentation are launch-ready. |
A store with few records can need Custom Migration if its data is structurally unusual. A store with many records can use a supported path if the data is clean and validation is well prepared.
Migration Actions for ShopWired
After an initial paid migration has produced a result, continued Source Store activity may call for further work into ShopWired. The next action should follow the intended result and the validity of the recorded configuration. Demo findings should inform the first paid configuration rather than be treated as a paid continuation baseline. ShopWired Products, variations, choices, extras, trade Customers, Orders, Blog Posts, stock, content, and integration-linked identifiers remain important revalidation subjects.
| Migration Action | When it fits ShopWired | What must be revalidated |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid, including accepted variation and trade data handling; choose the source-data window separately. | New Products, variations, choices, extras, Customers, trade Customers, Orders, content, and a regression sample from earlier migrated data. |
| Continue the Migration with a New Configuration | Review of the earlier paid result or revised business requirements shows that filtering, supported field mapping, content scope, Customer handling, or Product configuration should change. | Every affected Product-selection structure, trade-pricing input, custom field, Customer type, Order field, URL, and content area influenced by the new configuration. |
| Perform a New Migration | Use for the first paid run or a distinct result on the same purchased path; agree target effects without assuming a reset or protected-data erasure. | The accepted data scope, protected target data, variation and extra relationships, Customer and agreed trade context, history, content, URLs and configuration boundaries. |
Entity Points should be checked before the action, but they should not be confused with ShopWired complexity.
A saved configuration requires acceptance of selected records and regression samples. A new configuration must prove its changed rule against combined earlier and later output. A distinct result requires broader acceptance of its defined target effect. Theme, payment, delivery, tax, trade configuration, apps and integrations retain their own implementation owners unless expressly agreed.
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 fixed. A different Source Platform or Target Platform 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.
ShopWired Service-Path Decision Gates
The final service path should be approved only after four ShopWired-specific gates are answered. First, the Product gate should prove that variations, choices, extras, bundles, stock, images, and pricing remain usable. Second, the Customer gate should distinguish ordinary buyers from trade Customers and confirm whether account, group, and pricing relationships are supported. Third, the operational gate should separate historical Orders from payment, delivery, tax, theme, app, and integration setup. Fourth, the ownership gate should identify who will configure the target, validate the migrated result, and restore external workflows.
| Decision gate | Standard or Managed evidence | Custom-scope warning |
|---|---|---|
| Product structure | Available standard record evidence and required paid proof preserve Product meaning; target purchase checks establish live sellability. | Source logic depends on unsupported builders, app-owned records, or bespoke transformation. |
| Trade commerce | Trade Customers and supported pricing inputs have clear target meaning. | Contract logic, account hierarchy, or custom pricing data has no supported destination. |
| Operations | Historical Orders are readable and target configuration is separately owned. | External identifiers or workflow records are required for fulfillment, accounting, or support. |
| Validation capacity | The merchant can approve representative samples and regression checks. | Acceptance needs customer business decisions or separately agreed analysis; Expert Handle executes agreed actions. |
These gates prevent Managed Migration from being used as a substitute for unclear scope and prevent Custom Migration from being selected merely because the store feels complicated. The practical path is the lightest service arrangement that can satisfy all four gates with evidence.
Choosing Between the Main Paths
The approach decision should be practical. It should protect the merchant from avoidable risk while avoiding unnecessary service weight. Use the following decision map as a final check.
| If the ShopWired migration looks like this | Stronger path to consider |
|---|---|
| Supported records, clean catalog, ordinary customers, readable order history, and merchant-led setup. | Standard Migration. |
| Supported records but higher coordination pressure, launch timing pressure, or limited validation capacity. | Managed Migration for agreed expert actions; broader review or launch work requires explicit scope. |
| Supported records need data-type-specific conditions, expression-based value changes, or compatible target-field destinations. | Data Filter, Data Transformation, or Advanced Data Mapping. |
| Unsupported, custom, app-owned, external-system, Custom Platform, or bespoke transformation requirements exist. | Custom Migration. |
| Scope is unclear because samples are weak. | Review available standard samples and assign enhanced/custom paid proof or target checks before Full Migration. |
A reliable choice can be summarized in four statements: which records will migrate, which ShopWired settings must be configured separately, which Add-ons or Custom Migration requirements are in scope, and which sample results must pass before Full Migration.
Signals That the Chosen Approach Is Too Light
A ShopWired migration approach is too light when it treats business logic as ordinary record movement. The warning signs usually appear in product options, B2B behavior, customer identity, app dependencies, external identifiers, or target setup.
| Warning signal | Likely response |
|---|---|
| Complex products were not included in Demo Migration. | Inspect available standard variation samples; assign enhanced/custom choices, extras or bundle proof to paid scope and live behavior to target checks. |
| B2B rules are described generally but not sampled. | Provide trade customers, pricing examples, account terms, restricted products, and related orders. |
| Custom fields are important but not classified. | Decide whether they are supported mapping, app-owned data, external references, or Custom Migration scope. |
| Payment, delivery, and tax setup is assumed to come from order history. | Separate historical readability from target configuration. |
| API, webhook, feed, ERP, POS, or marketplace dependencies are not documented. | Build an integration map and review external ID needs. |
| Entity Points are used as the only scope measure. | Review data meaning and structural complexity alongside volume. |
These signs should be handled before Full Migration. Launch is the wrong moment to discover that the chosen approach did not match the store's operating model.
Conclusion
Choose the ShopWired scope from variation identity, Product Choices, linked extras and trade SKU ownership. Standard Migration is customer-led supported execution; Managed Migration supplies expert execution of agreed actions. Eligible Add-ons refine supported output, while tailored requirements use Custom Migration with Self-Execute or Expert Handle.
Select the ShopWired representation from variation identity, choices, linked extras and trade SKU ownership, then confirm supported scope and execution. Use limited standard Demo to reveal gaps, paid scope to prove enhanced/custom output and target checks for live stock, commercial rules and integrations. Entity Points and later actions remain tied to the purchased path.
Common Questions
When is Standard Migration enough for a ShopWired migration?
Standard Migration may be enough when the migration stays within supported scope, product structures are clear, customer and order data are manageable, target settings can be configured by the merchant, and the merchant can validate results confidently.
When should Managed Migration be considered for a ShopWired migration?
Choose Managed Migration when experts should execute the agreed Migration Actions within supported ShopWired capability. The customer retains manual access, supplies variation and trade meaning and verifies the final result. Broader coordination, validation services, target setup or launch management requires explicit scope.
How are Add-ons different from Custom Migration in a ShopWired migration?
Supported Add-ons perform filtering, expression-based transformation and compatible mapping in their fixed sequence; mapping preserves the source or already transformed value. ShopWired does not support Advanced Database Mapping as Target. Tailored requirements outside supported controls use Custom Migration with Self-Execute or Expert Handle; app implementation remains separate.
How should Migration Actions affect the selected approach?
The first paid run uses Perform a New Migration. Either continuation needs an earlier paid migration and uses its saved configuration or an intentional new configuration. Choose the source-data window independently, distinguish newly added records from edits to existing records and verify combined output without assuming protected target data is erased.
Does migration configure ShopWired trade pricing, delivery, payments, and theme behavior?
Not automatically. Customer and Product records can be migrated within the agreed scope, but live trade settings, delivery rates, payment credentials, tax configuration, apps, and theme behavior remain target-side responsibilities unless explicitly included.
Can Product Choices preserve separate variation stock in ShopWired?
No. Choices do not track their own stock. Variations can carry separate stock and selling values, while extras can link to a stand-alone Product for stock handling. Select the required representation from the actual source selling unit and confirm supported handling; matching option text alone does not preserve inventory meaning.
Why do trade-pricing requirements change the SKU review?
ShopWired trade pricing bands use unique Product and variation SKUs and require the Trade accounts app. Duplicate or missing SKU identity can undermine the intended assignment even when names and prices look correct. Define SKU continuity, Customer-to-band relationships and target setup ownership, then confirm supported migration or agreed tailored handling.