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 should begin with the areas that can change business meaning most directly: product configuration, customer identity, B2B behavior, order interpretation, storefront discovery, and external-system dependencies. These areas determine whether the migrated store is merely populated or genuinely usable.
| 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.
A variation represents a sellable combination and can carry SKU, price, stock, image, weight, GTIN, MPN, and VAT-related meaning. A choice or extra can add an optional selection or charge without creating the same inventory-bearing identity. Text and file inputs preserve Customer-supplied information. A bundle connects one offer to other Product records. Pre-order and subscription behavior adds time and transaction relationships beyond the static catalog.
| 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 or extra | Optional selection and price effect without false variant inventory |
| 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 variants for descriptive or optional data, and flattening inventory-bearing combinations into static text. External identifiers should remain attached to the Product or variation level recognized by warehouse, accounting, feed, and marketplace systems.
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 custom fields. Newsletter status represents a communication relationship rather than a substitute Customer identity. Trade status adds B2B pricing and access meaning. Reward points form a Customer-linked ledger. Application tags or CRM identifiers may remain owned by external systems.
| 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.
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. The commercial rule may belong to a pricing band, a Product-specific trade price, an individual exception, a global discount, a visibility relationship, or a Quote. Historical Quotes and Orders preserve negotiated outcomes; current trade configuration defines future buying behavior.
| 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 should be organized through ownership boundaries rather than through generic escalation labels. The core decision is whether the value belongs to a native ShopWired entity, a ShopWired application, presentation configuration, or an external system.
| 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 |
This model avoids two failures: forcing every source value into the nearest native field and preserving custom data without understanding its parent relationship. A value is usable only when teams know what record owns it, what system recognizes it, and whether it describes history, current commerce, or presentation. Ownership should also remain stable across exports and integrations. When a custom value is duplicated into several systems, one source of truth and one durable reconciliation key should be identified so later updates do not create conflicting versions of the same commercial fact.
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?
Because source Product options may represent different behaviors in ShopWired. Some become variations with SKU, price, stock, image, weight, or VAT meaning. Others belong to choices, extras, personalization fields, bundles, or application-owned structures.
Are customer records matched only by name in ShopWired?
No. Customer identity is strongly tied to email address. Duplicate emails, guest orders, registered accounts, trade accounts, and customer custom fields should be reviewed carefully so order history and account meaning remain usable.
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?
Not always. Trade accounts, pricing bands, individual prices, Quote relationships, Product visibility, account terms, and tax treatment are connected commercial records, not ordinary fields on a Customer profile.
When does ShopWired custom data need a separate owner?
A separate owner is needed when a value belongs to an application, external system, custom-source table, presentation layer, or relationship that does not fit an ordinary Product, Customer, Quote, Order, or content record.
How should trade and B2B rules be translated in ShopWired?
Separate the underlying buyer identity and Product data from the rule that changes price, visibility, tax treatment, quotation, or checkout behavior. Preserve the records that carry durable meaning, then document which target configuration or connected system will enforce the commercial rule.