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
Start by documenting the exact ShopWired account, primary domain, active theme, installed apps, staff roles, tax and currency context, Product and Order export capability, and external systems. Record who owns catalog, trade accounts, Orders, SEO, theme code, finance, fulfillment, and integrations.
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 Product variations, Product choices, and Product extras. Variations can carry their own price, SKU, stock quantity, image, weight, GTIN, MPN, tax treatment, and other attributes. Choices are reusable option sets applied to Products and can add cost, but they do not represent independently stocked variants. Extras are optional add-ons and can sometimes reference another Product for stock purposes. Customization fields and file uploads can capture buyer-specific input.
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 choice set, options, additional cost, Product assignment, required state, and conditional display | Choice-set inventory and assigned Products | Reusable buyer choices are not mistaken for variants. |
| Product extras | Record add-on purpose, price, linked Product where used, and stock assumption | 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 the labels look similar. Their stock, pricing, reuse, and Order behavior differ.
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 or payment context, internal notes, and external identifiers. Review duplicate or shared emails because email can be important to account and Order relationships.
| 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. It should not be used as a substitute for live payment, delivery, tax, email, or checkout setup in the new Store.
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 archive containing Product, Customer, trade Customer, Order, Category, brand, filter, content, and app-related exports together with media, screenshots, API or feed documentation, theme backup, and explanatory notes. Keep original exports unchanged and perform cleanup in working copies.
| 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 a source expectation, linked evidence, relevant identifiers, and a named reviewer.
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. |
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.
When access, source relationships, exports, assets, dependencies, and representative records are documented, migration configuration can proceed with a stable and testable understanding of the ShopWired source.
Common Questions
Why should variations, choices, and extras be inventoried separately?
They have different pricing, stock, reuse, and Order behavior. Treating them 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 any outside-system identifiers.
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.