A ShopWired choice can add a charge without owning stock, while an optional extra can link to a Product whose stock it consumes. Those are different relationships from a configured variation. For a prospective ShopWired Target Store, the key is to preserve the parent, sellable identity, and commercial owner behind each source value.
Migrating to ShopWired is not only a matter of moving Products, Customers, Orders, Categories, Reviews, Coupons, and CMS records into a new administration area. ShopWired has a specific commerce structure around products, categories, brands, variations, choices, extras, stock, customer identity, trade features, checkout configuration, VAT and sales tax settings, delivery rules, apps, API behavior, and theme-driven storefront presentation. A good migration plan must translate source data into that structure without losing the business meaning behind the records.
The central question is simple: when a source record lands in ShopWired, will the merchant still understand what it means and will the store still use it correctly? A product option that was previously a simple label may need to become a ShopWired variation, choice, extra, bundle, personalization field, or app-supported behavior. A customer segment may become a customer record, newsletter subscriber, trade customer, pricing group, or custom field. A historical order may be readable for service purposes, but it will not automatically configure checkout, delivery, payment, VAT, sales tax, or B2B behavior for future transactions.
ShopWired data meaning becomes clearer when record transfer is separated from operational reconstruction. Each value should be interpreted by the commercial or operational function it must continue to support: drive catalog browsing, control purchasable combinations, preserve customer history, support trade accounts, explain historical orders, maintain search visibility, connect external systems, or support ongoing merchandising.
ShopWired Data Translation Priorities
ShopWired data-model planning separates variation identity, optional choices, linked extras, buyer and trade relationships, transaction snapshots, discovery, and external-system ownership. These layers explain whether a source value describes an item, changes the purchase, controls a rule, or records what happened in an Order. A populated field cannot substitute for its missing parent or consumer.
| Source-store area | ShopWired interpretation | Migration planning question |
|---|---|---|
| Product variants and options | Variations, choices, extras, bundles, text/file inputs, or app behavior | Does the source option affect SKU, price, stock, delivery, tax, or only presentation? |
| Category and brand structure | Product discovery, navigation, filtering, SEO, and merchandising logic | Can customers still find priority products through the expected routes? |
| Customer records | Email-based customer identity, account state, order history, notes, custom fields, and trade separation | Do duplicate, guest, B2B, and registered customer records retain the right meaning? |
| Customer groups and trade accounts | B2B visibility, pricing, account behavior, and operational rules | Which rules are data, which are ShopWired configuration, and which need custom review? |
| Historical orders | Customer history, payment and delivery labels, tax values, order notes, fulfillment context, and external references | Are historical orders useful for service and reporting after migration? |
| Content and SEO assets | Pages, landing pages, blog posts, menus, redirects, metadata, and theme-controlled display | Which content affects search, trust, conversion, or B2B onboarding? |
| Apps and integrations | External data ownership, API/webhook behavior, stock feeds, accounting, fulfillment, email, marketplace, or CRM workflows | Which connected systems must be reconfigured, mapped, rebuilt, or excluded? |
This translation view prevents a common migration mistake: assuming that matching field names are enough. Field similarity does not guarantee operational similarity. For ShopWired, meaning depends on how the record participates in product selection, customer recognition, B2B selling, checkout, fulfillment, tax calculation, and storefront presentation. A useful ownership map therefore connects each value to its parent Product, variation, Customer, trade account, Quote, Order, content record, application, or external system before field-level mapping is defined.
Products, Categories, Brands, and Discovery Data
ShopWired Products are connected to Categories, brands, variations, choices, extras, stock, prices, images, search keywords, filters, URLs, and merchandising relationships. A source catalog may store these concerns in Products, collections, tags, attributes, manufacturers, page-builder blocks, or application records. The destination should assign each meaning to the ShopWired structure that actually owns it.
Categories provide hierarchical Product organization, while brands identify manufacturer or brand identity. Product filters can expose structured comparison values. Product search keywords influence discovery without becoming visible Categories. A theme can render these records, but presentation does not become the authoritative catalog owner.
| Source catalog concept | ShopWired owner | Translation consequence |
|---|---|---|
| Department or durable hierarchy | Category and parent-child structure | Preserve Product membership and enduring browsing meaning. |
| Manufacturer or brand | Brand relationship | Keep brand identity separate from a generic Category or specification. |
| Technical attribute used for narrowing | Product filter or structured field | Retain comparison value without creating artificial variants. |
| Internal search synonym | Product search keyword | Improve discovery without displaying the term as catalog content. |
| Campaign collection | Category, landing page, offer, or curated presentation relationship | Follow the commercial purpose rather than the source label. |
| Main image and gallery | Product/variation media relationship | Preserve image role and variation-specific media where the sellable combination changes. |
Product identity remains commercially useful only when teams can determine what is sold, where it appears, which brand or Category owns it, how it is found, and which stock and price record controls the sellable item.
Variations, Choices, Extras, and Product Configuration Meaning
ShopWired distinguishes variations, choices, extras, custom text, file uploads, bundles, pre-orders, subscriptions, and other Product behaviors. Source platforms often call all of these “options,” but the relationships are different.
An individually configured variation can carry separate SKU, price, stock, image, weight, and other supported commercial values. Blank variation price, SKU, or weight can retain base-Product settings rather than define an independent value. Choice sets do not hold individual SKU or stock, and their additional charges differ from variation prices. Product Extras are different again: an extra can optionally link to a base Product and consume that Product’s stock; it cannot link a specific variation. Customer text and file input, bundles, pre-orders, and subscriptions retain their own transaction or application relationships.
| Source behavior | ShopWired owner | Meaning to preserve |
|---|---|---|
| Size/color combination with its own SKU or stock | Variation | Sellable identity, price, inventory, image, weight, and external identifiers at combination level |
| Optional upgrade or gift wrap | Choice set or Product Extra | Optional selection and price effect; a linked extra can consume a separate base Product’s stock |
| Engraving text | Product custom text input and Order-line snapshot | Customer-entered value connected to the purchased line |
| Customer artwork or document | File-upload relationship and Order-line snapshot | Customer file ownership, security, and fulfillment visibility |
| Kit or multipack | Bundle or Product-to-Product relationship | Component identity, quantity, stock authority, and historical Order meaning |
| Pre-order or subscription Product | Product plus temporal/order relationship | Release, billing, renewal, or account context that is not contained in Product fields alone |
| Conditional configurator | Application-owned logic | Source selections and resulting Order data must be separated from the application that generated them |
This distinction prevents two opposite errors: creating stock units for ordinary choices, and flattening configured inventory-bearing combinations into text. Native Product and variation identity also differs from SKU and external keys. A warehouse reference must remain on the parent or combination recognized by that warehouse. An extra’s optional charge, linked base-Product identity, and stock effect are separately defined; it should not be treated as a stock-bearing variation merely because it has a visible selection.
Variation display and variation identity are not always equivalent. The “all variants” shorthand uses base settings and differs from individually configured combinations; the quotation system requires the latter representation for variation relationships. A Quote line therefore needs the appropriate configured combination, not simply the same displayed option labels. Platform capability remains separate from the relationships carried by the selected migration path.
Customer, Account, and Marketing Data
ShopWired separates Customer profiles, newsletter subscribers, trade Customers, reward points, referral relationships, Customer sources, and application-created Customer data. Email is an important identity key, but duplicate emails, guest Orders, legacy accounts, and trade relationships can make one-to-one matching unsafe.
A Customer record can own contact details, addresses, account state, Order history, notes, and configured custom values. Newsletter status represents a communication relationship; trade approval and pricing add commercial context. Rewards and referrals belong to enabled program records rather than generic notes. Application or CRM keys retain their actual owner. Matching by email can support identity decisions, but it does not establish consent, trade approval, or usable authentication.
| Source identity pattern | ShopWired relationship decision |
|---|---|
| Registered retail buyer | Customer profile linked to addresses and historical Orders |
| Guest buyer | Order-level identity and addresses without inventing a permanent account |
| Newsletter-only contact | Subscriber relationship, kept separate from a buyer account unless the records genuinely represent the same person |
| Approved trade buyer | Trade Customer plus the pricing, visibility, tax, and account relationships that give approval meaning |
| Duplicate source accounts | Consolidate only when identity, consent, addresses, and Order ownership support the decision |
| Reward or referral balance | Customer-linked program record rather than a generic Customer note |
| CRM or marketing ID | External identifier attached to the Customer or subscriber record recognized by the connected system |
The destination model should not infer consent, trade approval, or account ownership from a shared name. It should preserve the relationship that made the source record operationally meaningful.
Customer profile continuity does not establish password-verification continuity. That depends on the exact supported Source-to-Target path and applicable account setup; other paths need invitation, activation, reset, or first-login handling. Guest history and newsletter-only contact data should not be treated as proof of a registered buyer account.
B2B, Trade, Quote, and Pricing Data
ShopWired B2B structures include trade Customers, trade-only Categories and Products, trade pricing, pricing bands, individual trade prices, global discounts, Quotes, and related account behavior. These are connected records rather than attributes of one Customer row.
The buyer identity belongs to the Customer or trade Customer. Pricing bands, global discounts, Product-specific prices, and individual exceptions have separate rule and assignment owners. Individual trade prices can identify a Product or configured variation by its assigned SKU; a group name alone cannot establish the buyer-to-item price. Quote and Order amounts preserve negotiated or purchased outcomes, while active trade configuration defines future eligibility. Approval, price, visibility, and tax context remain distinct even when they refer to the same buyer.
| B2B source element | ShopWired owner | Relationship meaning |
|---|---|---|
| Approved business account | Trade Customer | Buyer identity and approved B2B status |
| Wholesale tier | Trade pricing band or global discount | Shared commercial treatment for a class of trade Customers |
| Contract price | Individual trade Customer pricing or another Product-Customer relationship | Account-specific exception at the correct Product or variation level |
| Trade-only assortment | Product/Category visibility relationship | Which approved buyers can discover and purchase the item |
| Quote | Quote record linked to Customer, Products, prices, notes, status, and later Order where applicable | Negotiated commercial snapshot rather than an ordinary cart |
| Purchase-order terms | Customer/Quote/Order context plus destination payment configuration | Historical terms and reference values kept separate from live checkout behavior |
| VAT status | Trade Customer and tax relationship | Buyer evidence and commercial treatment should not be reduced to a label |
A source Customer Group is therefore insufficient by itself. Its data-model meaning is the network of prices, Products, visibility rules, Quote history, terms, and tax treatment connected to that group.
Orders, Order Statuses, Quotes, and Transaction Context
A ShopWired Order records what happened in a transaction. Its relationships can include Customer or guest identity, Product and variation lines, choices, extras, personalization data, prices, vouchers, delivery, payment labels, VAT or sales tax, statuses, notes, refunds, returns, subscriptions, Quotes, and external-system references.
Historical Order values are snapshots. They should not be recalculated under current Product prices or tax settings. A payment or delivery label explains the past Order but does not configure the destination gateway or delivery zone. An Order custom field belongs to the transaction unless the same value is deliberately promoted to durable Customer or Product data.
| Order relationship | Historical meaning to preserve |
|---|---|
| Customer or guest assignment | Who placed the Order and which addresses were used |
| Product/variation line | Purchased identity, SKU, selected choices or extras, quantity, and line description |
| Customer-supplied text/file | Fulfillment instruction attached to the purchased line or Order |
| Price, discount, voucher, VAT/tax, and total | Financial snapshot recorded at purchase time |
| Payment and delivery label | Method context for service and reconciliation without implying live configuration |
| Status, refund, return, and timeline | Lifecycle evidence and changes to the original transaction |
| Quote or subscription reference | Relationship to the commercial process that preceded or followed the Order |
| External ID | Reconciliation key for ERP, accounting, fulfillment, marketplace, or CRM systems |
Orders remain usable when staff can interpret the transaction even if the current catalog, theme, application stack, or checkout configuration has changed.
Checkout, Delivery, Payment, VAT, and Sales Tax Data
ShopWired separates historical transaction data from the configuration that creates future Orders. Old Orders may contain delivery names, charges, payment labels, VAT or sales-tax values, exemptions, and custom checkout responses. ShopWired's current checkout, delivery zones and rates, collection methods, payment gateways, VAT zones, custom tax rates, trade rules, and checkout applications are separate configuration records.
| Historical source value | Data owner | Separate destination relationship |
|---|---|---|
| Payment method label and transaction reference | Order | Payment gateway and credential configuration for future transactions |
| Delivery method and charge | Order | Delivery zone, rate, restriction, collection, and carrier configuration |
| VAT or sales-tax amount | Order financial snapshot | Current VAT zones, tax rates, exemptions, and calculation settings |
| Customer exemption evidence | Customer/trade Customer or external compliance record | Destination rule that applies the treatment to future Orders |
| Checkout question answer | Order or Customer field according to purpose | Checkout field definition and visibility rule |
| Offline terms or purchase-order reference | Trade Customer, Quote, or Order | Current payment-term and approval configuration |
| Checkout application output | Application-owned Order data | Destination application configuration and supported data relationship |
This separation keeps historical data and future configuration in their correct roles: migrated records explain past transactions, while configuration records describe how ShopWired will create new ones. They are connected, but neither substitutes for the other. The same distinction applies to Customer exemptions and trade terms: the historical Order preserves what occurred, while the Customer or trade relationship records why similar treatment may apply in the future.
Content, SEO, Menus, and Theme-Dependent Data
ShopWired content can include website pages, landing pages, Blog Posts, Product and Category metadata, 301 redirects, menus and link lists, company information, images, files, featured Products, Product Q&A, and other storefront records. Themes render these records but do not become their authoritative owner.
A source page-builder block may combine text, images, Product references, forms, and application widgets in one visual object. The destination model should separate durable content from presentation configuration and dynamic commerce references.
| Source asset | ShopWired owner | Translation consequence |
|---|---|---|
| Policy, service, or B2B information page | Website page | Preserve body, metadata, links, media, and enduring URL meaning. |
| Campaign or editorial landing page | Landing page plus Product/content references | Separate reusable content from theme-specific layout. |
| Blog entry | Blog Post | Retain title, body, media, date/author context where relevant, metadata, and internal links. |
| Product or Category SEO data | Product/Category plus SEO fields | Keep canonical entity identity separate from redirects and menu placement. |
| Menu item | Menu/link-list relationship | Public navigation may point to a Product, Category, page, Blog Post, external URL, or campaign. |
| Redirect | 301 redirect relationship | Preserve source-to-destination route meaning without treating the old URL as page content. |
| Theme section or widget | Theme/application presentation | Recreate presentation separately from the content or Product data it renders. |
Content ownership matters across B2B and retail experiences. A trade onboarding page, Product specification library, policy page, or high-value landing page can carry business meaning even when its visual design is replaced.
Apps, API, Webhooks, and External-System Data
ShopWired exposes applications, API credentials, and webhooks, and its ecosystem includes accounting, fulfillment, stock, marketplace, marketing, tax, search, subscription, and B2B connections. Source application data does not become native ShopWired data merely because a destination application serves a similar purpose.
The destination model should identify the authoritative system for every operational value. Product and variation IDs may be recognized by an ERP. Customer IDs may belong to a CRM. Order and shipment references may belong to fulfillment or accounting. Subscriber consent may belong to a marketing platform. A webhook is configuration; the external identifier carried by its payload is data.
| Dependency | Authoritative relationship |
|---|---|
| ERP or accounting Product ID | Product or variation recognized by the external system |
| Stock feed key | Inventory-bearing Product/variation plus the system that owns available stock |
| Fulfillment reference | Order, shipment, or package relationship recognized by the carrier or warehouse |
| CRM Customer/company ID | Customer or trade Customer relationship at the correct account level |
| Marketplace listing ID | Product/variation/channel relationship, not a generic Product description |
| Marketing consent and tags | Subscriber/Customer plus the external marketing system that owns the status |
| Application custom field | Application-owned value with an explicit parent Product, Customer, Order, or Quote |
| API credential or webhook subscription | Secure destination configuration rather than publication or Customer data |
API pagination, authentication, and error handling affect how systems exchange records, but they do not change who owns the underlying data. The ownership map should therefore be stable even when the integration implementation is rebuilt.
Custom and External Data Ownership Boundaries
ShopWired custom and external data follows the parent record and continuing consumer. The enabled Custom Fields app can add typed values to supported entities, including Products, Customers, Orders, Quotes, pages, and Blog Posts. A definition and value are separate from the theme or application behavior that displays or uses them. An Order-specific answer should not become a durable Customer fact, and a Quote-only field should not be assigned to every later transaction.
| Data signal | Destination owner | Required relationship definition |
|---|---|---|
| Product specification used for filtering | Product/filter structure | Attribute name, value, Product membership, and storefront display role |
| Variation-level warehouse ID | Variation plus ERP/warehouse | Sellable combination and the external record that recognizes it |
| Trade Customer contract reference | Trade Customer plus CRM/accounting | Organization, contact, commercial account, and outside-system key |
| Quote-only custom field | Quote | Negotiation or approval context without making it a permanent Customer attribute |
| Application-created subscription or bundle record | Application plus Product/Order | Parent Product, billing or component relationships, and historical transaction references |
| Theme setting that chooses Products | Theme presentation | Product references remain authoritative in the catalog; the setting controls display only |
| Unsupported custom-source table | Defined parent entity or external system | Business purpose, parent key, lifecycle, and destination owner must be explicit |
A custom value is usable when its parent, definition, type, lifecycle, and consumer are known. Copies in several systems need one authoritative owner and a durable reconciliation relationship, with native target identity kept separate from a business code. API credentials and webhook subscriptions remain secure configuration; historical payment, download, or subscription references do not confer live action authority.
Conclusion
ShopWired data-model planning should focus on meaning, not field matching. The most important differences usually appear around product configuration, B2B and trade behavior, customer identity, order history, checkout context, content and SEO assets, apps, API workflows, external IDs, and custom fields. Each area should be interpreted by its continuing business use, not only by whether a record can be imported.
A strong ShopWired destination model assigns each source value to a Product, variation, Customer, trade relationship, Quote, Order, content record, application, presentation layer, or external system. That ownership map preserves commercial meaning without confusing historical data with future configuration.
Common Questions
Why do ShopWired product options need special review during migration?
Source options can mean configured variations, choice sets, linked extras, personalization, or application behavior. Variations can have independent commercial values or use base settings. Choice sets do not own individual SKU or stock, while a linked Product Extra can consume a base Product’s stock. Preserve the actual relationship rather than classify every selection as a variation.
Are customer records matched only by name in ShopWired?
No. Use native Customer identity and the available email, address, guest, account, and historical Order context together. Email similarity does not establish consent, registered-account access, trade approval, or password continuity. Those meanings depend on their own relationships and the exact supported Source-to-Target path.
Do migrated orders configure checkout in ShopWired?
No. Migrated orders can preserve historical payment, delivery, discount, tax, and fulfillment context where supported. Live checkout still depends on ShopWired payment, delivery, VAT or sales tax, customer-group, trade, and app configuration.
Can B2B pricing and trade rules be migrated as normal customer data?
Trade identity, approval, pricing bands, individual Product or variation prices, visibility, Quote context, and account terms are separate relationships. A Customer label cannot replace them. Individual pricing also needs the correct assigned SKU, while historical Quotes and Orders retain outcomes rather than establish future eligibility.
When does ShopWired custom data need a separate owner?
Identify the parent, definition, type, and consumer. The enabled Custom Fields app can extend supported records, but an application value, external key, Quote-only field, or theme setting has a different owner. A stored value does not recreate theme coding, executable rules, or the connection that uses it.
How should trade and B2B rules be translated in ShopWired?
Separate buyer identity and approval from item identity and pricing or access rules. Pricing bands, global discounts, and individual buyer-to-item prices have different relationships. A Quote’s variation reference also needs an individually configured combination; “all variants” shorthand is not the same model. Future tax, checkout, and connected-system behavior remain separately configured.
Do ShopWired choices and extras always have their own stock?
No. Individual choice-set selections have no separate SKU or stock. A Product Extra can optionally link a base Product and consume its stock, but it cannot link a specific variation; its stock restrictions and return behavior also differ from ordinary Product purchasing. Keep the choice, extra, linked Product, and configured variation owners distinct.