ShopWired preparation starts with selling behavior: an independently stocked variation, a reusable buyer choice, and a linked extra need different evidence even when their labels look alike. Preserve their original identity, price meaning, stock effects, and historical selections before preparing the intended ShopWired account. Customer and trade continuity also require evidence beyond a profile export.
ShopWired preparation should distinguish between records that look similar in an export but behave differently in the Store. Product variations, Product choices, extras, customization fields, digital delivery, trade Customers, Categories, brands, filters, and app-owned data can all change what a Product or Customer record means. A flat Product list cannot explain those relationships by itself.
The preparation objective is to create a source evidence package that assigns an owner, artifact, and ready condition to each important area. That package should describe how Products are sold, how trade and ordinary Customers differ, how Orders preserve selected options, and which apps or outside systems own data beyond the normal ShopWired records.
Establish Account Access and Record the ShopWired Environment
Identify the actual Source account separately from the intended ShopWired account. Record the Source Platform, domain, accessible records, original identifiers, and evidence owners. For a ShopWired Source, include its theme, apps, staff roles, tax/currency context, exports, and external systems; for another Source, collect equivalent relationships without inventing ShopWired IDs. Record the destination plan, required roles, compatible enabled apps/theme consumers, and catalog, trade, Order, SEO, finance, fulfillment, and integration owners separately.
Prepare the supported access required for the selected migration path. Hosted-platform access, exports, and any authorized API or integration credentials should not be presented as interchangeable. The access owner should provide the method that applies to the current Store and remain available for permission or data-scope questions.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm account and domain | Store administrator | Account details, domain list, Store status | The correct source Store is unambiguous. |
| Inventory installed apps | Platform owner | App list, purpose, data created, current status | App-owned data can be separated from native records. |
| Record theme and code ownership | Theme owner or agency | Theme version, custom code note, repository or backup location | Presentation and code dependencies have a named owner. |
| Confirm source exports and access | Data or technical owner | Export permissions, API or feed details where applicable | Required source evidence can be collected. |
| Start a change log | Project owner | Dated catalog, Customer, Order, app, and URL changes | The evidence set will not silently become stale. |
Prepare Products by Selling Behavior
ShopWired separates variations, global choices, and extras. Variations can own price, SKU, stock, image, weight, GTIN, MPN, tax treatment, and other attributes; a variation price replaces the base price. Choices are reusable option sets whose price effects are additions, and they cannot track their own stock. Extras add to the Product and can link to a standalone Product with a SKU for stock deduction, but not to a specific variation. A linked extra does not provide the same availability or returned-stock behavior as a variation. Customization fields and uploads capture buyer-specific input under their actual implementation.
Prepare Products by behavior rather than by count. Include Product ID, title, SKU, status, price, sale price, tax treatment, stock, weight, Categories, brand, filters, images, content, SEO fields, variation structures, choices, extras, customization fields, digital-delivery references, and external identifiers.
| Product pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Variations | Record option names, values, combinations, publication state, variation attributes, and parent inheritance | Variation export and Product examples | Independently meaningful combinations are documented. |
| Product choices | Record global display/internal names, options, additional cost, Product assignment, and required/conditional behavior with its actual consumer | Choice-set inventory and assigned Products | Reusable buyer choices are not mistaken for variants. |
| Product extras | Record add-on purpose, price, linked standalone Product/SKU where used, enabled stock deduction, availability/return rules, and owner | Extra list and representative Products | Optional add-ons have clear ownership. |
| Customization or file input | Record field label, required state, accepted input, and Order-line display | Product and Order examples | Buyer-specific input remains tied to the purchase. |
| Digital or service Product | Record delivery method, file or access owner, and Product status | Product list and source assets | Non-physical delivery evidence is available. |
| Pre-order or scheduled Product | Record ships-on or release settings and operational owner | Product examples and date rules | Time-dependent selling behavior is documented. |
Do not convert choices or extras into variations merely because their labels look similar. Freeze original Product/variation IDs, SKUs, option keys, global choice display and internal names, assignments, media, stock modes, and external keys before normalization. Native choice import reuses a global set only when both names match; a changed name can create another set. Record approved changes separately. Choices are optional by default, so required or conditional behavior needs evidence from the actual theme/app consumer. For linked extras, record availability and return-stock handling: an out-of-stock extra can still be added to the basket, and returned stock is not restored automatically.
Prepare Categories, Brands, Filters, and Storefront Discovery
A Product can be complete as a record and still become difficult to find when Category, brand, filter, search, or navigation evidence is incomplete. Prepare the Category hierarchy, Product assignments, brands, filter-driving values, menus, landing pages, and important routes as separate but connected source structures.
| Discovery area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Categories | Catalog owner | Hierarchy, Product assignments, status, landing copy | Every retained Category has a known purpose. |
| Brands | Merchandising owner | Brand list, Product relationships, URLs, metadata | Brand discovery is separated from descriptive labels. |
| Filters | Catalog or search owner | Filter names, values, Product coverage, cleanup exceptions | Values used by shoppers are consistent enough to map. |
| Menus and landing pages | Storefront owner | Navigation map, screenshots, linked Categories and pages | Presentation paths are documented outside the Category export. |
| Priority URLs | SEO owner | Product, Category, brand, page, and campaign routes | High-value routes have a planned disposition. |
Record Products assigned to several Categories, hidden or seasonal Categories, trade-only areas, and campaign paths. These cases reveal discovery rules that a simple hierarchy cannot show.
Prepare Customers, Trade Accounts, and Address Evidence
ShopWired can support standard Customers and trade Customers with distinct account behavior. Trade functionality can include trade pricing, trade-only Products or Categories, credit accounts, restricted promotions, and account activation state. Preparation must show which Customers are ordinary accounts and which depend on trade relationships.
Prepare Customer ID, name, email, account state, addresses, marketing preferences, custom fields, trade state, credit/payment context, notes, and external identifiers. Preserve duplicate/shared-email cases before approving consolidation. Record the selected Source-to-Target verification decision or required reset, activation, SSO, or first-login handling, with identity and communication owners. Native Customer export/update does not contain the password field; a profile file cannot establish returning-Customer access. Native trade bulk import/export also omits additional address-book entries, so required addresses need separate evidence and an accepted owner.
| Customer pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Standard registered Customer | Record identity, addresses, account state, and Order relationship | Customer and Order examples | Account identity is clear. |
| Guest buyer | Record email, Order history, and any later account relationship | Guest Order samples | Guest history is not assumed to be a registered account. |
| Trade Customer | Record active state, trade pricing, restricted Products or Categories, credit context, and custom fields | Trade Customer register | B2B meaning is attached to actual Customers. |
| Duplicate or shared email | Identify records, business reason, and disposition | Identity exception list | Ambiguous identity has an owner. |
| External-system Customer | Record CRM, accounting, ERP, or support identifiers | Integration field dictionary | Downstream lookup keys remain available. |
Prepare Historical Orders and Selected Product Inputs
Historical Orders should preserve the information needed by customer service, finance, and operations. ShopWired Orders can include selected variations, choices, extras, customization text, uploaded-file references, trade pricing, delivery labels, tax context, discounts, refunds, and notes. Select Orders that expose each of these patterns.
| Order area | Action | Evidence | Ready condition |
|---|---|---|---|
| Product configuration | Include variation, choice, extra, and customization selections | Representative Order lines | The purchased configuration is interpretable. |
| Customer identity | Distinguish registered, guest, and trade Orders | Cross-scenario samples | Order ownership is clear. |
| Pricing and discounts | Include trade price, sale price, voucher, manual adjustment, and tax cases | Total-component samples | Historical commercial context is documented. |
| Delivery and fulfillment | Record delivery method, status, tracking, collection, and unusual handling | Order and shipment examples | Fulfillment history has a known meaning. |
| Refunds and cancellations | Include amount, status, notes, and related Order | Exception Order set | Financial and service history remains understandable. |
| External references | Record accounting, ERP, marketplace, fulfillment, or support identifiers | Integration-sensitive Orders | Required lookup values are identified. |
Historical Order evidence should describe what happened, preserving selected variations, choices, extras, buyer input, prices, tax, discounts, addresses, status meanings, and external references. It does not replace live payment, delivery, tax, email, digital-access, or checkout setup. Record notification, linked-extra stock, payment, fulfillment, file-delivery, and app events that the import plan must contain; history must not trigger another purchase or delivery effect.
Inventory Apps, APIs, Webhooks, Feeds, and Custom Code
Create a dependency register for every ShopWired app, Product feed, marketplace connection, accounting tool, CRM, ERP, fulfillment service, warehouse system, analytics integration, API workflow, webhook, and theme customization. Record whether the dependency creates data, reads data, modifies checkout or display, changes stock, or uses identifiers that must remain searchable.
| Dependency field | Required detail | Ready condition |
|---|---|---|
| Owner and purpose | Business owner, technical owner, workflow supported | Responsibility is explicit. |
| Data objects | Products, Customers, Orders, stock, Categories, content, or custom fields used | Affected records are known. |
| Direction and timing | Read, write, two-way, scheduled, event-driven, or manual | Source authority is documented. |
| Identifiers | SKU, Product ID, Customer email, Order number, external key | Lookup dependencies are preserved. |
| Transition decision | Reconnect, rebuild, retire, replace, or review | No dependency is assumed to continue automatically. |
Theme code should be included when it changes Product options, trade visibility, navigation, content display, or Order capture. Presentation-only code and data-bearing code should not be treated as the same risk.
Prepare Content, Media, URLs, and Theme Evidence
Prepare pages, blog or guide content, policies, forms, media, downloadable files, Product and Category descriptions, brand pages, metadata, internal links, canonical expectations, and redirects. Record which content is native, app-owned, or embedded in theme code.
| Content area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Product and Category content | Catalog or marketing owner | Exports, media paths, representative pages | Commercial content can be matched to records. |
| Pages and policies | Content owner | Page inventory, status, route, internal links | Retain, rebuild, merge, or exclude decisions are recorded. |
| Digital assets | Operations or content owner | Original files, Product relationship, access rules | Source files are available. |
| SEO routes | SEO owner | Priority URLs, metadata, redirects, campaign paths | Route continuity inputs are complete. |
| Theme-dependent content | Theme owner | Template locations, custom sections, screenshots | Content hidden in presentation code is identified. |
Prepare Exports, Backups, and Source Change Control
Create a dated protected archive of Product, Customer, trade, Order, Category, brand, filter, content, and app evidence, with media, screenshots, API/feed notes, theme records, and explanatory definitions. Keep original exports unchanged and clean working copies only after identities are frozen. Record selected export fields and actual coverage: choices or extras can be included when their fields are selected, while separate relationships or trade address-book gaps may still need evidence. Name the recovery location and owner and track changes after capture.
| Evidence set | Required contents | Ready condition |
|---|---|---|
| Core exports | Files, export date, field set, account context, checksum | Records are complete and attributable. |
| Option evidence | Variations, choices, extras, customization fields, Product assignments | Selling behavior is not lost in a Product-only export. |
| Theme and media | Theme backup or code record, images, downloads, uploaded assets | Presentation and source files can be located. |
| Dependency records | App list, feeds, API or webhook notes, external IDs | Integration ownership is documented. |
| Change log | New and edited Products, Customers, Orders, URLs, apps, and trade rules | Later source changes can be reconciled. |
Select Representative Migration Test Records
Select samples that reveal distinct ShopWired structures rather than only ordinary records. Each sample should have a short source expectation stating why it is included and which fields or relationships matter.
| Sample group | Include | Preparation purpose |
|---|---|---|
| Products | Simple Product, multi-variation Product, choice-heavy Product, extra, customization or upload Product, digital Product, trade-only Product | Expose different selling behaviors. |
| Customers | Registered, guest, trade, credit-context, duplicate-email exception, external-ID Customer | Represent identity and B2B differences. |
| Orders | Variation, choices, customization, trade price, discount, refund, unusual delivery, external reference | Preserve historical context. |
| Discovery | Priority Category, brand, filter set, menu path, landing page | Prepare storefront structure evidence. |
| Content and integrations | SEO-sensitive page, digital asset, app-owned field, feed or API record | Represent non-core dependencies. |
The sample package is ready when every selected record has original values, a source expectation, intended ShopWired representation, linked evidence, relevant identifiers, agreed exclusions, and a named reviewer. Use distinct examples for variation stock, reusable choices, linked extras, trade address books, account access, and digital delivery when one sample cannot represent them honestly.
Complete the ShopWired Readiness Gate
| Final gate | Ready condition |
|---|---|
| Access | Correct account, exports, apps, theme ownership, and technical contacts are confirmed. |
| Products | Variations, choices, extras, customization, digital delivery, trade visibility, and identifiers are documented. |
| Discovery | Categories, brands, filters, menus, and priority routes are prepared. |
| Customers | Standard, guest, trade, duplicate, address, and external-ID cases are understood. |
| Orders | Product selections, totals, delivery, refunds, notes, and external references are interpretable. |
| Dependencies | Apps, APIs, webhooks, feeds, theme code, and external systems have dispositions. |
| Inputs | Exports, assets, backups, checksums, and change log are available. |
| Samples | Representative migration records cover ordinary and complex source patterns. |
Preparation is complete when required evidence and destination prerequisites have accepted owners and treatment. Resolve required gaps, exclude them by agreement, or hold the affected scope before proceeding. A named owner and future deadline alone cannot make missing trade addresses, option identity, or stock behavior ready.
Conclusion
ShopWired preparation should preserve the difference between variations, choices, extras, customization, trade behavior, and app-owned data. Those distinctions determine whether a Product, Customer, or Order remains understandable outside the source Store.
With recoverable source evidence, accepted relationships, enabled destination consumers, and representative expectations, migration configuration can proceed from a stable understanding of the intended ShopWired representation. Later testing must verify that representation and its live behavior.
Common Questions
Why should variations, choices, and extras be inventoried separately?
They have different pricing, stock, reuse, and Order behavior. Variation prices replace the base price; choice and extra prices are additions. Choices cannot track stock, while linked extras deduct stock under their own availability and return rules. Treating these as one generic option structure can remove important commercial meaning.
Which ShopWired Products should be included in the sample set?
Include simple Products, variations, choices, extras, customization or file-upload Products, digital or service Products, trade-only Products, and records with external identifiers.
How should trade Customers be prepared?
Document active state, trade pricing, restricted Products or Categories, credit context, custom fields, addresses, Order history, and external identifiers. Native trade bulk import/export omits additional address-book entries, so preserve them separately when required. Keep profile evidence, authentication handling, and account communications as distinct decisions.
Should guest Orders be linked to registered Customers during cleanup?
Only when the business has approved the identity relationship. Shared or reused email addresses can make automatic consolidation unreliable.
What app information is needed before migration?
Record what the app does, which records it reads or creates, its identifiers, owner, integration timing, and whether it will be reconnected, rebuilt, retired, or replaced.
How should changes after the export date be controlled?
Maintain a dated change log for Products, Customers, Orders, URLs, apps, theme code, and trade rules so later changes can be reconciled with the prepared evidence.
Does the Customer export establish returning-Customer access?
No. It supplies profile evidence, and native export/update does not include the password field. Record the exact Source-to-Target verification decision or required reset, activation, SSO, or first-login handling for the intended account workflow, with identity and communication owners. Do not treat profile completeness as credential portability.
Can choice-set names be normalized before their reuse is recorded?
Preserve the original global display and internal names, definitions, and Product assignments first. Native import reuses a set only when both names match; a changed name can create another set. Record approved source-to-intended changes so reuse and historical selections remain traceable.
Does linking an extra to a Product establish complete stock control?
No. An extra can link to a standalone Product with a SKU for stock deduction, not to a specific variation. An out-of-stock linked extra can still be added to the basket, and returned stock is not restored automatically. Prepare the enabled deduction, availability and return rules, authority, and owner separately.