ShopWired migration risk is driven by the separation among Product variations, Product Choices, Product Extras, customisation fields, bundles, trade pricing, quotations, inventory, checkout configuration, apps, themes, and integrations. Several of these structures can look like “options” in a source export while carrying very different SKU, stock, price, image, and Order consequences.
The platform is hosted, so source custom code and direct database structures do not transfer as implementation assets. Their business purpose must be translated into ShopWired records, apps, theme behavior, or external systems. Each major risk therefore begins with an assumption about what can be copied and ends with evidence that the intended commercial outcome has an owner in the target environment.
Variations Can Multiply Faster Than the Catalog Can Be Governed
ShopWired variations can combine up to three variation types, with separate records for valid combinations. Each configured combination can carry its own SKU, stock, price, sale price, weight, GTIN, MPN, image, and other values.
| Risk-chain element | ShopWired-specific interpretation |
|---|---|
| Assumption | Every source option dimension can be converted into a ShopWired variation without changing catalog administration. |
| Platform constraint | Variation types are limited, and every generated combination can create a separately managed commercial record. |
| Migration consequence | Complex source configurators exceed the available variation structure or create a large set of invalid and hard-to-maintain combinations. |
| Operational impact | Staff cannot govern prices and stock reliably, buyers encounter unavailable combinations, and imports or feeds become difficult to reconcile. |
| Mitigation cue | Keep only SKU-, stock-, price-, weight-, or image-defining dimensions in the variation grid and move other choices to the appropriate ShopWired structure. |
| Affected owners | Catalog operations, inventory, merchandising, fulfillment, and marketplace teams. |
| Control signal | Every generated combination is commercially valid, uniquely identifiable, maintainable, and connected to the correct stock, price, image, and fulfillment meaning. |
The limit is not only technical. Even within the supported structure, a large Cartesian combination set can create an operational burden that did not exist in the source Store.
Product Choices Can Be Confused With Stock-Bearing Variations
ShopWired Product Choices are reusable sets assigned to Products. They can add a price to the base Product but do not carry their own SKU, stock quantity, weight, or image. They are an alternative to variations, not a second name for the same record.
| Risk-chain element | ShopWired-specific interpretation |
|---|---|
| Assumption | Product Choices can replace any source variant or combination because they present selectable values to the buyer. |
| Platform constraint | Choices do not own SKU, stock, weight, or images and add cost rather than defining a replacement sellable-unit price. |
| Migration consequence | Inventory-bearing variants are represented as reusable choices, or descriptive choices are expanded into unnecessary variation combinations. |
| Operational impact | Stock cannot be controlled by selection, Order lines lose SKU precision, delivery weights are wrong, and pricing produces unexpected totals. |
| Mitigation cue | Assign a source value to Product Choices only when it is reusable, non-stock-bearing, non-image-bearing, and compatible with additive pricing. |
| Affected owners | Catalog administration, pricing, inventory, fulfillment, and Customer service. |
| Control signal | Every Product Choice behaves as an additive, non-inventory selection, while every true sellable combination remains a variation. |
A source attribute table can contain both structures. The field name alone does not determine the correct ShopWired destination.
Product Extras, Bundles, and Customisation Fields Have Different Stock Consequences
Product Extras can add optional items and may link to a base Product SKU, but not to a specific Product variation. Bundle Products connect constituent Products and quantities, while customisation fields collect buyer-entered text or files for an Order.
| Risk-chain element | ShopWired-specific interpretation |
|---|---|
| Assumption | Optional items, bundle components, and personalisation can all be represented as additional variation values. |
| Platform constraint | Extras, bundles, customisation fields, and variations have different Product-link, stock, Order, and compatibility behavior. |
| Migration consequence | A linked extra points to the wrong inventory record, a bundle loses component quantities, or buyer-entered information becomes reusable catalog data. |
| Operational impact | Stock deductions are inaccurate, returned extras do not restore stock as expected, digital delivery or fulfillment misses components, and personalised Orders lose instructions. |
| Mitigation cue | Identify whether the source relationship is an optional linked item, a required component set, a buyer input, or a sellable variant, then preserve its specific stock and Order behavior. |
| Affected owners | Inventory, fulfillment, merchandising, Customer service, digital delivery, and returns teams. |
| Control signal | Extras, bundles, and customisation values create the intended Order evidence and stock effects without being attached to an unsupported variation relationship. |
These differences are especially important for Products that combine bundles and options because ShopWired can impose compatibility boundaries between those structures.
Trade Accounts and Pricing Can Depend on More Than Customer Classification
ShopWired trade operations can use global percentage discounts, Customer-specific Product prices, pricing bands, hidden prices, quote workflows, and other account rules. A Customer marked as trade does not automatically inherit the complete commercial treatment.
| Risk-chain element | ShopWired-specific interpretation |
|---|---|
| Assumption | Migrating a trade-account flag or Customer group preserves B2B pricing and access. |
| Platform constraint | Trade pricing can be global, Product-specific, or band-based, while visibility and quote behavior can depend on separate theme or app settings. |
| Migration consequence | Accounts arrive without the price source, band assignment, hidden-price rule, or quote relationship that controlled their buying experience. |
| Operational impact | Trade Customers see retail prices, confidential prices become public, sales teams lose negotiated context, and quotations cannot be converted consistently. |
| Mitigation cue | Map each trade account to its pricing mechanism, visibility rule, quote state, tax treatment, payment expectations, and external account identifier. |
| Affected owners | B2B sales, finance, Customer service, account management, and storefront administration. |
| Control signal | Representative trade accounts receive the intended prices and visibility and can follow the required quote or direct-order path without manual correction. |
The source may contain several trade models at once. A single percentage field cannot represent Customer-specific price overrides and pricing-band relationships together.
Quotation Compatibility Can Depend on How Variations Were Created
ShopWired quotations can include existing Customers, Products, delivery, VAT treatment, status, and comments. Products created through the simplified “all variants” approach are not compatible with quotations unless their variation combinations are configured individually.
| Risk-chain element | ShopWired-specific interpretation |
|---|---|
| Assumption | Any Product visible in the Store can be inserted into a quote using the same Product and option data. |
| Platform constraint | Quote compatibility depends on individually configured variation combinations rather than the simplified all-variants representation. |
| Migration consequence | Products look correct in the catalog but cannot be quoted or resolve to an ambiguous combination in the sales workflow. |
| Operational impact | Sales teams cannot prepare accurate quotes, stock checks are unreliable, and paid quotes convert into Orders with incomplete Product identity. |
| Mitigation cue | Identify Products used in quotation workflows and ensure each relevant combination has an explicit record compatible with quote selection. |
| Affected owners | B2B sales, account management, inventory, finance, and Customer service. |
| Control signal | Representative quotes can select the intended Product combinations, show correct stock and tax context, and retain comments and pricing through conversion. |
This risk is easy to miss when the catalog is reviewed separately from the quotation process. The same Product can pass storefront inspection while remaining unusable to the sales team.
Inventory Can Depend on SKU, Variation, Bundle, Extra, and External Ownership
ShopWired stock can be managed at the base Product or configured variation level. Stock entry depends on SKU presence, and bundles, linked extras, feeds, and external systems can introduce additional ownership relationships.
| Risk-chain element | ShopWired-specific interpretation |
|---|---|
| Assumption | One opening quantity per Product is enough to preserve availability. |
| Platform constraint | Quantity may belong to a variation, linked Product, bundle component, or external stock authority, and some features apply stock rules differently. |
| Migration consequence | Stock is placed on the parent Product, duplicated across variations, or updated simultaneously by ShopWired and an external system. |
| Operational impact | Overselling occurs, bundle availability is misleading, returns do not restore expected quantities, and integration updates overwrite correct values. |
| Mitigation cue | Declare the inventory owner for every Product family and preserve SKU-to-variation, bundle-component, extra-link, and external-location relationships. |
| Affected owners | Warehouse, purchasing, fulfillment, returns, marketplaces, and integration teams. |
| Control signal | Each sellable item receives quantity from one authoritative source, and every Order, bundle, extra, return, and synchronization event affects the intended stock record. |
Opening inventory and historical Orders need separate controls. Importing old Orders should not replay stock events against the target opening state.
Checkout, Delivery, Payment, VAT, and Sales Tax Are Configuration Risks
Historical Orders can preserve old payment, delivery, and tax labels, but those records do not configure the ShopWired checkout. Live behavior depends on active payment methods, delivery zones and rates, collection rules, checkout fields, VAT settings, sales-tax settings, trade rules, and installed apps.
| Risk-chain element | ShopWired-specific interpretation |
|---|---|
| Assumption | Migrating historical checkout data recreates the rules needed for new Orders. |
| Platform constraint | Current checkout behavior is controlled by target configuration and applications rather than historical Order labels. |
| Migration consequence | Old Orders remain readable while new baskets calculate tax, delivery, payment availability, or required fields differently from the intended business rules. |
| Operational impact | Customers are overcharged or undercharged, valid regions cannot order, trade accounts lose expected methods, and fulfillment receives incomplete information. |
| Mitigation cue | Separate historical evidence from live checkout ownership and define the target rule for each region, Product type, Customer class, payment method, and delivery path. |
| Affected owners | Finance, tax, checkout operations, fulfillment, B2B sales, and Customer service. |
| Control signal | Representative retail and trade baskets produce the intended tax, delivery, payment, collection, and checkout-field behavior under current target configuration. |
This is a structural boundary rather than a record-count issue. A complete Order archive can coexist with an incorrectly configured checkout.
Apps, APIs, Webhooks, Themes, and External Systems Can Leave Orphaned Behavior
ShopWired exposes Products, variations, choices, extras, customisation fields, Categories, brands, tags, stock, Customers, Orders, and shipping resources through its API. Apps, webhooks, themes, accounting, fulfillment, marketplaces, and marketing platforms can own additional behavior and identifiers.
| Risk-chain element | ShopWired-specific interpretation |
|---|---|
| Assumption | Similar target features will automatically resume the source Store’s apps, feeds, webhooks, theme logic, and external workflows. |
| Platform constraint | Application records, authentication, event subscriptions, theme code, field definitions, and external identifiers are separate from ordinary Product and Order records. |
| Migration consequence | Core data arrives but subscriptions, feeds, fulfillment events, accounting links, custom display rules, or marketing segments remain disconnected. |
| Operational impact | Orders stop reaching external systems, stock and prices become stale, theme-dependent sales information disappears, and reconciliation loses traceability. |
| Mitigation cue | Assign each app or integration an owner, target capability, credential, event or API dependency, durable identifier, theme dependency, and exception process. |
| Affected owners | Integration engineering, finance, fulfillment, marketing, storefront development, security, and data governance. |
| Control signal | Every continuing workflow can identify the correct target record, receive or send the required event, and recover from failed synchronization without manual ambiguity. |
A hosted target changes the implementation boundary. Source code should be interpreted as evidence of business behavior, not assumed to be a portable asset.
Conclusion
ShopWired migration risk is concentrated where similar-looking choice structures have different commercial ownership. Variations, Product Choices, Extras, bundles, customisation fields, trade prices, quotes, stock, checkout rules, apps, and external systems cannot be collapsed into one Product-and-option model.
Risk is controlled when each source behavior has a deliberate ShopWired owner and an observable control signal. That preserves sellable identity, trade-account treatment, quotation usability, inventory authority, checkout accuracy, historical meaning, and integration continuity without reproducing unsupported source mechanisms.
Common Questions
What is the biggest ShopWired Product-structure risk?
The biggest risk is treating variations, Product Choices, Extras, bundles, and customisation fields as interchangeable options. They differ in SKU, stock, price, image, component, and Order behavior.
When should a source option become a ShopWired variation?
It should become a variation when the choice identifies a real sellable combination with its own SKU, stock, price, weight, GTIN, image, or fulfillment meaning. Reusable non-stock selections may fit Product Choices instead.
Why can trade accounts remain incomplete after Customer migration?
Trade treatment can depend on global discounts, Customer-specific prices, pricing bands, hidden-price rules, quotes, tax context, and account identifiers. The account flag alone does not preserve those relationships.
Why can a Product work in the Store but fail in quotations?
Products created through the simplified all-variants approach are not compatible with ShopWired quotations. Quote-used combinations need explicit variation records that the quotation system can select.
Do historical Orders prove that checkout is correctly configured?
No. Historical Orders preserve past labels and totals. Current payment, delivery, tax, collection, trade, and checkout-field behavior depends on active ShopWired settings and apps.
How should source custom code be treated in a ShopWired migration?
Treat it as evidence of required business behavior. The behavior needs an owner in ShopWired configuration, an app, the theme, an external system, or a deliberate retirement decision; the source implementation itself is not portable.