Shift4Shop preparation should document how the Source Store will be represented through Products, ordinary options, Advanced Options, Product extra fields, Categories, SmartCategories, Customer Groups, Price Levels, Customers, Orders, content, modules, and external systems. Established Stores may also contain 3dcart-era labels, exports, custom fields, and integrations whose current meaning is not obvious from the field name.
The preparation package should combine access, evidence, ownership, and ready conditions. Its purpose is to make the source logic explicit before the representative migration sample set is created.
Record the Shift4Shop Target Assumptions
Start with the target operating assumptions that change data preparation.
| Area | Decision to record | Evidence |
|---|---|---|
| Product identity | Which source records become base Products and which option combinations need independent commercial identity | Product-family matrix |
| Option behavior | Which choices remain ordinary options and which require Advanced Options or another owner | Option and combination examples |
| Catalog discovery | Which source Categories are static, dynamic, navigational, searchable, or obsolete | Category and SmartCategory classification |
| Customer treatment | Which Customer Groups, Price Levels, access rules, and custom fields remain | Group and pricing inventory |
| Historical Orders | Which line details, statuses, discounts, rewards, affiliate, and external references staff need | Representative Order packet |
| Legacy and custom records | Which 3dcart-era fields, modules, apps, or external IDs remain active | Lineage and dependency register |
A source Product option should not be assigned to Advanced Options merely because it has several values. The preparation decision should be based on whether the combination owns SKU, stock, GTIN, weight, price, image, availability, or another independently managed value. Record this at Product-family level so similar Products follow one controlled rule rather than being interpreted differently during migration.
Prepare Access, Exports, and a Source Snapshot
Collect the access and evidence required to understand the Source Store and prepare Shift4Shop.
Include:
- source administrator access and Shift4Shop administrator access with appropriate permissions;
- Product, option, Customer, Order, Category, content, and redirect exports where available;
- media and file archives when source links are protected or temporary;
- Customer Group and Price Level definitions;
- Product extra-field definitions and examples;
- SmartCategory rules and ordinary Category assignments;
- module, app, affiliate, rewards, CRM, waiting-list, and review records when in scope;
- external IDs used by ERP, accounting, fulfillment, marketplace, or CRM systems;
- dated source backups and a record of data likely to change before the migration window.
| Evidence item | Ready condition |
|---|---|
| Access log | Required administrative areas are reachable and responsible contacts are known |
| Export archive | Files open, include expected records, and have a clear export date |
| Field and module dictionary | Important custom or legacy values have a purpose and owner |
| Product sample list | Ordinary and exceptional option structures are represented |
| Order sample list | Historical statuses, adjustments, and external references are represented |
Prepare Products, Options, and Advanced Options
Shift4Shop ordinary options can change buyer selections and price or weight adjustments, while Advanced Options can give specific combinations their own commercial fields. Prepare Product examples that make this distinction visible.
Include:
- simple Products;
- Products with ordinary dropdown, radio, image, text, or other option behavior;
- Products with Advanced Options and combination-level code, GTIN, stock, weight, price, image, or availability;
- Products using Category-level option inheritance;
- Products with extra fields, manufacturer IDs, search keywords, or specialized Product metadata;
- kits, bundles, digital Products, waiting-list behavior, subscriptions, or application-owned configuration;
- Products whose price or visibility differs by Customer Group or Price Level;
- Products synchronized with an external inventory or catalog system.
| Source behavior | Shift4Shop preparation decision | Required evidence |
|---|---|---|
| Option changes selection but not independent stock | Ordinary Product option | Option type, values, price/weight effect, and Order-line example |
| Combination has independent SKU, stock, GTIN, weight, or image | Advanced Option | Combination matrix and source identifiers |
| Value describes the Product | Extra field, description, search field, or external metadata | Field purpose, data type, and consumer |
| Choice is entered once by the buyer | Text or custom input relationship | Storefront example and Order-line evidence |
| Logic is created by an app or custom code | Application or external owner | Rule description, related records, and external IDs |
Normalize option names, Product codes, manufacturer IDs, and extra-field meaning before migration. A 3dcart-era export label should be tied to the actual current workflow rather than retained solely because it exists.
Prepare Categories, SmartCategories, Search, and URLs
Shift4Shop ordinary Categories contain assigned Products, while SmartCategories can populate dynamically from rules such as sale state, release timing, shipping treatment, or keywords. Prepare them as separate structures.
| Source grouping | Destination question | Ready evidence |
|---|---|---|
| Stable Category | Should the Product membership be retained directly? | Category hierarchy and Product assignments |
| Dynamic collection | Is a SmartCategory or another merchandising rule appropriate? | Source rule and intended ownership |
| Brand or manufacturer grouping | Should it remain a Category, manufacturer field, filter, or page? | Brand examples and discovery purpose |
| Search-only value | Should it remain a keyword, extra field, Product code, or other searchable field? | Search-term and field inventory |
| Menu-only link | Which Category, page, Product, or external route does it reference? | Navigation outline |
| Legacy URL | Which Product, Category, or page is the intended destination? | Priority redirect inventory |
Prepare Product, Category, extra page, Blog or content, manufacturer, campaign, and policy URLs. Record source path, intended destination, content owner, metadata, internal links, and redirect requirement. For SmartCategories, retain the rule that creates membership as separate evidence from the public Category URL; a dynamic group cannot be reconstructed reliably from a one-time Product list alone.
Prepare Customer Groups, Price Levels, and Customer Records
Shift4Shop Customer Groups can connect Customers to Price Levels, minimum-order expectations, Product or Category visibility, and available payment or shipping methods. Prepare the group and its related rules together.
Collect:
- Customer Group names and purpose;
- Price Level assignments and Product-level prices;
- Product or Category visibility restrictions;
- minimum-order requirements;
- Customer custom fields and addresses;
- tax-exempt, wholesale, affiliate, rewards, CRM, review, waiting-list, or marketing relationships;
- external account IDs and company references;
- duplicate Customer and guest-checkout examples.
| Preparation question | Evidence | Ready condition |
|---|---|---|
| Which groups remain commercially active? | Group list and owner | Obsolete groups are excluded or archived |
| Which Price Levels belong to each group? | Product and group examples | Product, Price Level, and Customer Group relationships are explicit |
| Which access rules depend on groups? | Restricted Product/Category examples | Visibility rules have a target owner |
| Which app records belong to Customers? | Rewards, affiliate, CRM, or review samples | Continuing app or external-system owner is documented |
| How are duplicate Customers handled? | Matching-key examples | Merge and retain-separate rules are defined |
Prepare Historical Orders and Operational References
Prepare Orders that expose the historical record structure rather than only common paid Orders.
Include:
- Orders with ordinary options and Advanced Options;
- Customer Group or Price Level context;
- coupons, promotions, gift certificates, rewards, affiliate attribution, taxes, and shipping charges;
- pending, canceled, refunded, partially refunded, shipped, and partially fulfilled Orders;
- CRM tickets, waiting-list context, reviews, notes, and manual adjustments where relevant;
- ERP, accounting, marketplace, fulfillment, or payment references;
- legacy status labels that staff still use.
For each sample, explain which line, total, status, or external reference supports Customer service, finance, fulfillment, or reporting. Current payment, shipping, tax, and notification configuration should be documented separately from historical Order evidence.
Inventory Modules, Apps, Custom Fields, and Legacy Records
Create a dependency register for Shift4Shop modules, optional apps, custom fields, scripts, integrations, and legacy 3dcart-era records.
For each item, record:
- business purpose;
- source owner;
- related Products, Customers, Orders, Categories, or pages;
- sample records;
- export or API evidence;
- external identifiers;
- whether the function will continue, be replaced, or be retired;
- which data must remain for historical or reconciliation purposes.
Pay special attention to search, Advanced Options pricing, rewards, affiliate, CRM, reviews, waiting lists, subscriptions, digital Products, marketplaces, ERP, accounting, tax, shipping, and payment records. The register is ready when every active non-core field has a parent record, business owner, export path, external identifier, and continuation or retirement decision.
Select Shift4Shop Representative Migration Test Samples
| Sample | Preparation purpose |
|---|---|
| Simple Product | Establish ordinary Product, Category, media, price, and inventory handling |
| Product with ordinary options | Expose option values and Order-line meaning without independent stock |
| Product with Advanced Options | Expose combination-level code, stock, GTIN, weight, image, and price |
| Product with extra fields or searchable metadata | Expose descriptive and integration-owned fields |
| Product in a SmartCategory | Expose dynamic grouping versus direct Category assignment |
| Customer in a commercial group | Expose Customer Group, Price Level, access, and custom-field relationships |
| Complex historical Order | Expose options, totals, statuses, rewards, refunds, and external references |
| Priority content route | Expose extra page, Product, Category, metadata, and redirect decisions |
| Legacy or app-owned record | Expose current ownership of 3dcart-era or extension-created data |
Attach source IDs, business purpose, expected destination owner, related external IDs, and known exclusions. The sample ledger should explain why each record was chosen and which source relationship it represents, without defining later pass or launch criteria. Use separate records for ordinary options, Advanced Options, SmartCategories, Customer Group pricing, and legacy app data when one sample cannot represent those structures accurately.
Complete the Shift4Shop Readiness Gate
| Readiness question | Required evidence | Ready condition |
|---|---|---|
| Is required access available? | Access log | Required source and destination areas are reachable |
| Are ordinary and Advanced Options distinguished? | Product-family matrix | Each important option pattern has a documented owner |
| Are Categories and SmartCategories classified? | Category inventory | Static and dynamic membership are not confused |
| Are Customer Group and Price Level rules documented? | Commercial relationship matrix | Groups, Products, prices, and restrictions are connected |
| Are historical Orders represented? | Order sample packet | Important statuses, adjustments, and external references are explained |
| Are modules and legacy fields owned? | Dependency register | Every active custom record has a continuing owner |
| Are backups and exports current? | Dated source archive | Evidence can be recovered independently of the live Store |
| Are representative migration samples selected? | Sample ledger | Ordinary and exceptional structures are covered |
The preparation gate is complete when no critical Product, Customer, Order, Category, or integration decision depends on an unexplained legacy label or undocumented module. Every unresolved item should identify the responsible business owner, the evidence still needed, and the target structure or system that will own the final decision.
Conclusion
Shift4Shop preparation should expose the relationships behind Products, ordinary options, Advanced Options, Categories, SmartCategories, Customer Groups, Price Levels, Orders, content, and legacy records. The most important preparation work is distinguishing native structures from module-owned and 3dcart-era data while preserving the identifiers that staff and external systems still use.
A documented evidence package gives representative migration testing a representative sample set with clear source expectations and ownership.
Common Questions
What is the first Shift4Shop catalog decision to prepare?
Determine which source choices are ordinary Product options and which combinations need Advanced Option identity. That distinction affects SKU, stock, GTIN, weight, price, images, and Order-line meaning.
Should every source Category become a Shift4Shop Category?
No. Some source groups are dynamic campaigns, search collections, manufacturer views, menu links, or internal classifications. Prepare the intended discovery purpose before assigning the destination.
Why must Customer Groups and Price Levels be prepared together?
The group identifies the Customer context, while the Price Level and related restrictions define the commercial behavior. A group name without its Product prices or access rules is incomplete.
Which Orders belong in the representative migration sample set?
Include Orders with ordinary options, Advanced Options, discounts, taxes, shipping, multiple statuses, refunds, rewards or affiliate context, and external-system references.
What evidence should be collected for legacy 3dcart fields?
Trace each field to its current business purpose and consumer. Retain it only when a Shift4Shop structure, active module, or external system still owns the value.
When is Shift4Shop preparation complete?
It is complete when access and exports are ready, Product option patterns are classified, commercial groups and prices are documented, priority routes are mapped, dependencies are owned, and representative samples are selected.