ShopWired migration problems usually appear when a source Store’s commercial behavior is compressed into basic Product, Customer, and Order fields. ShopWired separates variations, choices, extras, Categories, brands, filters, trade-only structures, apps, and API relationships. A Product can therefore be present while the shopper cannot select it correctly, a trade Customer can exist while seeing the wrong catalog, and an Order can be readable while choice or customization context is incomplete.
The pitfalls below preserve the required five-part structure while using supportive tables where comparison improves clarity. The goal is to make recurring failure patterns visible without replacing the reasoning, example, or pass condition with a table.
Pitfall 1: Treating ShopWired as a Simple Product Import Destination
What goes wrong
The migration is framed as a direct Product upload. Titles, prices, images, and stock arrive, so the catalog appears complete. The source Store may also depend on variations, choices, extras, customization fields, Categories, brands, filters, trade rules, apps, release dates, or integration-owned identifiers. When those relationships are not modeled, the Product record survives but the buying experience changes.
Early warning signs
| Warning sign | Likely consequence |
|---|---|
| The scope lists only Products, Customers, and Orders. | Platform-specific selling behavior remains undefined. |
| Simple Products are the only examples. | Option, trade, and integration risks stay hidden. |
| Theme output is reviewed without its source fields. | Visual components lose the data that powers them. |
| App-owned records are treated as ordinary Product fields. | Synchronization or storefront behavior breaks. |
Prevention
Classify every important source behavior by its ShopWired owner: native Product field, variation, choice, extra, customization field, Category, brand, filter, trade setting, app, API integration, theme configuration, or deliberate retirement. Use this classification before field mapping begins.
Recommendation example
Choose a Product family that includes variants, an optional extra, a personalized field, a Category and filter assignment, and an external identifier. Trace each behavior to its ShopWired owner rather than accepting a flat Product record.
Pass condition
Representative Products retain the commercial and operational behaviors required to sell, discover, price, fulfill, report, and synchronize them in ShopWired without undocumented manual workarounds.
Pitfall 2: Flattening Variations, Choices, Extras, and Customization Fields
What goes wrong
Different source option types are mapped into one ShopWired option structure. A stock-bearing variant may become a non-stocked choice. An optional extra may become a required variation. A customer-entered personalization may be lost or stored only as a note. The Product page can look plausible while price, stock, VAT, identifier, image, or Order detail behaves incorrectly.
ShopWired variations, choices, and extras have different purposes. Variations can carry attributes such as price, SKU, stock, image, weight, GTIN, MPN, and VAT treatment. Choices are reusable selectable options that can add cost but do not carry stock. Extras are optional additions and may link to another Product for stock tracking.
Early warning signs
| Source behavior | Wrong target signal |
|---|---|
| Size or color controls SKU and stock. | It becomes a Product choice. |
| Gift wrap adds a fee but has no stock. | It becomes a full variation. |
| Warranty or accessory stock matters. | It becomes plain text or an untracked choice. |
| Personalization must appear on the Order. | It is visible on the Product page but absent from Order detail. |
Prevention
Classify each option by required attributes and buyer behavior. Use variations for mandatory sellable combinations and attribute-level control. Use choices for reusable optional selections without inventory. Use extras for optional additions, including stock-linked additions where appropriate. Preserve customization inputs in a structure that appears in the resulting Order context.
Recommendation example
For a personalized apparel Product, use variations for size and color, a choice for gift packaging, an extra for a separately stocked accessory, and a customization field for embroidered text. Confirm the selected values and charges appear correctly in the Order.
Pass condition
Every representative option preserves its required selection behavior, price, stock, identifier, image, VAT, and Order-line meaning without being forced into the wrong ShopWired structure.
Pitfall 3: Rebuilding Categories Without Rebuilding Discovery
What goes wrong
Categories are imported by name, but the relationship among parent Categories, subcategories, Products, brands, filters, menus, and search changes. ShopWired Categories can organize nested structures, while brands and filters provide different discovery functions. Replacing all three with a deeper Category tree makes the storefront harder to browse and maintain.
Early warning signs
| Discovery signal | Risk |
|---|---|
| The source uses attribute-led filtering. | Filters are recreated as dozens of Categories. |
| Products belong to several commercial groupings. | Only one Category assignment survives. |
| Brand pages generate traffic. | Brand relationships are omitted or treated as text. |
| A Category contains both Products and subcategories in the source. | The target structure is recreated without checking ShopWired hierarchy behavior. |
| Search depends on SKU, GTIN, MPN, or custom keywords. | Product discovery is approved only by title search. |
Prevention
Separate navigation hierarchy from brand identity and filtering. Use Categories for major browse paths, brands for manufacturer or brand-led discovery, and filters for attributes that buyers use to narrow results. Rebuild search settings and index behavior according to the identifiers and data sources the Store relies on.
Recommendation example
For a footwear Store, preserve Categories for product type, brands for manufacturer discovery, and filters for size, color, style, and material. Confirm a buyer can find the same Product through each intended route.
Pass condition
Priority Products remain discoverable through the intended Category, brand, filter, menu, and search paths without an inflated or misleading Category hierarchy.
Pitfall 4: Treating Trade Customers as Ordinary Customer Accounts
What goes wrong
Trade Customers migrate as ordinary profiles, but trade status, trade-only Categories, Product visibility, price treatment, bulk discounts, payment expectations, delivery rules, or company information are disconnected. The Customer can log in yet sees the retail Store or cannot complete the intended trade purchase.
Early warning signs
| Trade dependency | Failure pattern |
|---|---|
| Trade-only Categories | The Customer sees the retail menu or no trade Products. |
| Bulk or negotiated pricing | Retail prices remain visible. |
| Company identity | Staff see only the contact name on Orders. |
| Payment or delivery rules | The account reaches checkout with the wrong methods. |
| Approval status | Unapproved visitors gain access or valid trade Customers remain blocked. |
Prevention
Build a trade-account relationship map covering Customer identity, company data, trade status, Category and Product access, pricing, discounts, payment, delivery, tax, and approval. Define which relationships migrate as data and which must be configured in ShopWired.
Recommendation example
Use one approved trade Customer, one pending account, and one retail Customer. Compare login behavior, menu visibility, Product access, prices, bulk discounts, company display, and checkout methods.
Pass condition
Representative trade Customers receive the intended catalog, pricing, account identity, payment, delivery, and approval behavior without exposing restricted Products to retail visitors.
Pitfall 5: Preserving Customers Without Preserving Consent and Account Context
What goes wrong
Customer names, emails, addresses, and passwords or activation status are handled, but consent, groups, company details, custom fields, account notes, and external IDs are omitted or merged incorrectly. The result can weaken support, marketing governance, B2B treatment, or integration matching.
Early warning signs
| Customer signal | Risk |
|---|---|
| Marketing consent is mixed with ordinary profile data. | Customers receive the wrong communication treatment. |
| Several source accounts share an email or company. | Records are merged without an approved identity rule. |
| CRM or accounting IDs are stored in custom fields. | External systems create duplicates after cutover. |
| Passwords cannot be transferred in a usable form. | Customers are surprised by login failure. |
Prevention
Separate identity, login state, consent, company information, custom fields, notes, groups, and external identifiers. Define a duplicate rule and a Customer communication plan for any required password reset or account activation. Preserve only consent evidence that can be interpreted and lawfully used.
Recommendation example
Review a retail Customer, a trade Customer, a Customer with marketing consent, and a likely duplicate. Confirm how each account will be recognized, activated, segmented, and synchronized.
Pass condition
Representative Customer accounts retain approved identity, consent, company, group, and integration context, with predictable login behavior and no unexplained merge or duplication.
Pitfall 6: Approving Historical Orders Without Choice, Tax, and Fulfillment Context
What goes wrong
Orders migrate with totals and Product names, but staff cannot see the selected variation, choice, extra, customization text, VAT treatment, discount, delivery method, tracking reference, refund, or status meaning. The Order is present but cannot reliably support service, accounting, or fulfillment history.
ShopWired’s Order context can include selected options and operational details, while API-created Orders have specific limitations. Assuming every source behavior can be recreated through an API or basic import can remove critical evidence.
Early warning signs
| Order detail | Warning sign |
|---|---|
| Product choice | The final charge exists but the selected choice is not readable. |
| Customization field | Customer instructions are missing or detached from the Product. |
| VAT or tax | The total is present but the basis cannot be explained. |
| Voucher or discount | A manual adjustment replaces the original rule without context. |
| Delivery or refund | Status and tracking evidence are incomplete. |
Prevention
Define the historical purpose of Orders and the evidence required for that purpose. Preserve Product identifiers, selected options, Customer links, totals, tax, discounts, delivery, status, tracking, refunds, and relevant notes. For API-created or integration-created Orders, document unsupported fields and the agreed representation.
Recommendation example
Review one ordinary Order, one personalized Order, one trade Order, one discounted Order, and one refunded or partially fulfilled Order. Staff should be able to explain each transaction without opening the source Store.
Pass condition
Representative Orders remain understandable for support and reconciliation, including option, customization, tax, discount, and fulfillment context, without being mistaken for active checkout configuration.
Pitfall 7: Importing Products Without Respecting Release, Preorder, or Product-Type Behavior
What goes wrong
Physical, digital, service, rental, subscription, preorder, and future-release Products are all treated as ordinary immediately available Products. The target Store may publish items too early, omit delivery behavior, or sell a Product without the app or configuration needed to fulfill it.
Early warning signs
| Product behavior | Risk |
|---|---|
| Future release date | The Product is purchasable or visible at the wrong time. |
| Preorder or ships-on messaging | The customer promise disappears. |
| Digital delivery | No download owner or delivery path exists. |
| Subscription or rental | Recurring or time-based behavior is reduced to a one-time Product. |
| Service Product | Fulfillment and customer instructions are unclear. |
Prevention
Classify Products by fulfillment and lifecycle behavior before import. Decide which behaviors ShopWired handles natively, which require an app or integration, and which must be rebuilt or retired. Preserve dates and customer-facing promises only when the target process can honor them.
Recommendation example
Select a standard physical Product, a preorder, a digital Product, and a subscription or service Product. Confirm publication timing, buyer messaging, checkout treatment, and delivery ownership for each.
Pass condition
Every special Product type has a working target fulfillment and lifecycle owner, and no Product is published with a promise the Store cannot fulfill.
Pitfall 8: Treating Apps and APIs as Invisible Background Infrastructure
What goes wrong
Apps, feeds, webhooks, and API integrations are assumed to reconnect automatically because the underlying Products, Customers, and Orders migrated. The target data may use different IDs, fields, pagination, or rate behavior. Integrations can then miss records, duplicate updates, or overwrite migrated values.
Early warning signs
| Integration signal | Failure pattern |
|---|---|
| Source IDs are not preserved or cross-referenced. | ERP, CRM, or fulfillment systems create duplicates. |
| API pagination is ignored. | Only the first part of a large dataset is processed. |
| Rate limits are not handled. | Synchronization fails intermittently. |
| Webhook ownership is unclear. | Changes are missed or processed twice. |
| API-created Orders depend on unsupported behavior. | Discounts, VAT, choices, or customization context is incomplete. |
Prevention
Create an integration ledger covering credentials, endpoints, object IDs, pagination, rate handling, webhook events, field ownership, and retry behavior. Establish a cross-reference between source and target identifiers where external systems need continuity.
Recommendation example
For an ERP integration, trace one Product variation, one Customer, and one Order through initial import, API lookup, webhook update, and retry behavior. Confirm which system can overwrite each field.
Pass condition
Every continuing integration can identify, read, and update the intended ShopWired records without silent truncation, duplicate creation, or ownership conflict.
Pitfall 9: Leaving SEO, Redirects, and Theme-Owned Content Until Launch
What goes wrong
Products and Categories are approved before priority URLs, metadata, landing pages, menus, theme sections, and redirects are resolved. The Store then launches with broken inbound paths or with pages that technically exist but no longer communicate the source buyer intent.
Early warning signs
| Content or route signal | Risk |
|---|---|
| Organic traffic depends on Product and Category URLs. | Changed paths are discovered too late. |
| Theme sections contain trust, trade, or delivery information. | Data migration does not recreate the content. |
| Landing pages curate Products manually. | The target page is empty or points to the wrong Products. |
| Redirect mapping starts after domain work. | Important paths lack relevant destinations. |
Prevention
Build a route and content inventory alongside catalog decisions. Classify important paths as preserved, redirected, rebuilt, consolidated, or retired. Identify theme-owned content and manual merchandising that must be recreated separately from record migration.
Recommendation example
Map one high-traffic Product, Category, brand page, trade landing page, and campaign page. Confirm the target page is published and relevant before the old URL redirects to it.
Pass condition
Priority URLs resolve to relevant published pages, and essential theme or landing-page content has a defined target owner rather than being assumed to follow the Product import.
Pitfall 10: Losing Multichannel Identifier and Stock Ownership
What goes wrong
Marketplace, feed, point-of-sale, dropshipping, or fulfillment integrations continue using source SKUs, GTINs, MPNs, Categories, and stock rules, while ShopWired receives different identifiers or becomes an unintended inventory owner. Products can publish incorrectly, stock can diverge, or Orders can no longer be matched across systems.
Early warning signs
| Multichannel dependency | Warning sign |
|---|---|
| Marketplace listing uses variation SKU or GTIN. | The identifier is stored only on the parent Product. |
| Supplier feed owns stock. | Migrated opening stock competes with the next feed update. |
| Channel Category mapping is external. | Target Categories are assumed to update the channel automatically. |
| Order routing depends on Product IDs. | New IDs are not cross-referenced. |
Prevention
Define the master system for Product identity, stock, price, and Order routing by channel. Preserve identifiers at the correct Product or variation level and document how channel mappings will be rebuilt. Establish whether migrated opening stock is authoritative, temporary, or intentionally omitted.
Recommendation example
For a Product sold on the ShopWired Store and a marketplace, compare the parent Product ID, variation SKU, GTIN, stock owner, channel Category, and returned Order identifier across both systems.
Pass condition
Representative multichannel Products and Orders retain stable identifiers, traceable channel mappings, and a single declared owner for stock, price, Order routing, and synchronization.
Cross-Pitfall Prevention Map
| Control area | Pitfalls controlled | Required outcome |
|---|---|---|
| Product behavior classification | 1, 2, 7 | Each Product and option type has the correct ShopWired owner. |
| Discovery architecture | 3, 9 | Categories, brands, filters, search, content, and routes support buyer discovery. |
| Customer and trade model | 4, 5 | Identity, consent, trade access, pricing, and checkout treatment remain connected. |
| Order evidence model | 6 | Historical Orders remain operationally readable. |
| Integration and channel ledger | 8, 10 | IDs, APIs, webhooks, feeds, and stock ownership remain governed. |
Conclusion
ShopWired migration quality depends on preserving the distinctions that drive real Store behavior. Variations are not choices, trade Customers are not ordinary retail profiles, Category records are not the whole discovery experience, and migrated Orders do not automatically recreate live integrations. When those differences are made explicit and supported with focused tables, recommendations, and pass conditions, the Store avoids the recurring failures that record-count reviews cannot detect.
Common Questions
What is the most common ShopWired migration pitfall?
The most common failure is treating ShopWired as a flat Product import destination. Products may appear while variations, choices, filters, trade access, and app-owned behavior remain incomplete.
When should a source option become a variation rather than a choice?
Use a variation when the selection needs attributes such as SKU, stock, price, image, weight, GTIN, MPN, or VAT treatment. A reusable optional selection without stock can fit a choice.
Why should trade Customers be reviewed separately?
Trade status can affect catalog visibility, pricing, bulk discounts, company identity, payment, delivery, tax, and approval. A migrated Customer profile alone does not preserve those relationships.
Can historical Orders prove that ShopWired checkout is ready?
No. Historical Orders can preserve transaction evidence, but live payment, tax, delivery, voucher, and checkout behavior requires separate ShopWired configuration.
How should image-only official source PDFs be used?
They can provide platform-specific reference context, but current official documentation should govern volatile facts. Publication text should include only verified, stable conclusions rather than source commentary.
Why are supportive tables important in Article 8?
They make warning signs, ownership boundaries, and prevention choices easier to compare. They remain supportive: the causal explanation, recommendation example, and pass condition must still be fully developed in prose.