Preparing for AmeriCommerce means making Store ownership and buyer rules visible before the destination catalog is designed. A shared Product can behave differently by Store, Customer Type or variant-inventory setting, so the evidence package must explain those differences as well as retain the records.
Start with the actual Source Store and the intended AmeriCommerce account. The destination may combine several storefronts, active catalogs, Customer Types, variants, Product Groups, kits, advanced pricing and custom fields. If the Source is another Platform, prepare equivalent relationships in its own records. If it is AmeriCommerce, preserve the native Store identifiers and rule evidence. An export can show what exists without explaining which Store, buyer rule or external system owns its meaning.
The preparation objective is to convert those relationships into controlled source evidence. Each major area should identify the action to complete, the owner of the answer, the evidence to provide, and the condition that makes the area ready. This keeps the source state explicit before migration configuration begins.
Establish Access and Define the AmeriCommerce Operating Boundary
Document the intended AmeriCommerce account, enabled capabilities and Stores, then map each in-scope Source storefront to that design. Record account access, identifiers, domains, currencies, languages, tax context, theme ownership and the people responsible for catalog, Customers, Orders, marketing and integrations. Where Stores share data or have different active catalogs, distinguish shared settings from Store-specific records.
When AmeriCommerce is the Source, record the export family, selected columns and Store filter where that export supports it. With another Source, retain its equivalent extraction criteria. Save the date and scope of each file; one combined export does not prove Store ownership or coverage of related records that require a different export or evidence source.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| List every Store and domain in scope | Commerce administrator | Store list, identifiers, domains, status, business purpose | Every included Store has a named role and owner. |
| Confirm the supported source access | Access owner | Administrative access record, export permissions, technical contact | Required records can be collected from the correct account. |
| Document shared and Store-specific behavior | Platform owner | Store comparison note covering catalogs, pricing, content, and settings | Shared data is distinguishable from Store-specific data. |
| Freeze export criteria | Data owner | Export name, Store scope or applicable filter, date, selected columns, file hash | Each source file can be reproduced and explained. |
| Start a source change log | Project owner | Dated log of catalog, Customer, Order, URL, and integration changes | Changes after evidence capture will not be missed. |
Prepare Products, Variants, Groups, Kits, and Pricing Relationships
AmeriCommerce Products can use variants, variant inventory, Product Groups, kits, advanced pricing, quantity rules, Customer Type pricing, and custom fields. These structures should not be flattened into a single Product row during preparation. The team must identify which records represent sellable choices, which represent grouped presentation, and which depend on a pricing or inventory relationship.
Build a Product inventory that includes Product ID, item number or SKU, status, Store visibility, active-catalog placement, Categories, manufacturer, base price, tax class, quantity, weight, images, content, variants, Product Group relationships, kit components, price rules, and external identifiers. Select examples from every materially different Product pattern.
| Source pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Product variants | Record Variant Groups, values, display order, required state, price effects, and Product assignment | Variant export and representative Product pages | Choice vocabulary and Product ownership are complete. |
| Variant inventory | Record combination-level SKU, quantity, price, image, weight, and status where used | Combination matrix and stock sample | Independently managed sellable combinations are visible. |
| Product Groups | Record parent/child Products, group type, sellability, pricing, inventory, and shipping behavior | Group relationship export and screenshots | Grouping is not mistaken for a simple variant. |
| Kits or assembled offers | Record component Products, quantities, price behavior, stock assumptions, and fulfillment notes | Kit list and component examples | Component meaning and operational ownership are documented. |
| Advanced or Customer Type pricing | Record buyer scope, quantity threshold, dates, formula or amount, and affected Products | Pricing rule matrix | Conditional prices are explicit rather than inferred from labels. |
| Product custom fields | Classify each field as descriptive, operational, integration-owned, or obsolete | Field dictionary with sample values | Business-critical fields have a disposition and owner. |
Record whether variant inventory is enabled for each relevant Product and which Variant Groups participate. Non-inventory choices do not create independently tracked stock combinations. Where variant inventory is enabled, distinguish combination quantities from the rolled-up base quantity so stock is not counted twice; retain combination overrides and inherited values where used. Product Groups and kits need their own group type and child pricing, sellability, inventory and shipping evidence. Do not merge similar labels unless their Store, buyer and operational meaning also agrees.
Document Storefronts, Active Catalogs, Categories, and Discovery
Active Catalog settings can define the visible Category boundary of a Store. Treat that as catalog-display evidence, rather than a general security guarantee. Customer Types can also change Product visibility, content, redirects, discounts and shipping. Prepare a buyer-by-Store visibility map alongside the Category tree, with examples from the actual enabled configuration.
Prepare the Category hierarchy with IDs, parents, status, Store association, active-catalog state, Product assignments, content, images, sort order, and important URLs. Record navigation menus, landing pages, manufacturer paths, attribute-driven discovery, and internal links separately from the Category records that support them.
| Discovery area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Active catalog by Store | Platform administrator | Store-specific active-catalog screenshots or export | The visible Category boundary for every Store is documented. |
| Category hierarchy | Catalog owner | Parent-child export and retained Category list | Every retained Category has a known parent and purpose. |
| Product placement | Merchandising owner | Product-to-Category and Store assignment evidence | Shared placement and Store restrictions are visible. |
| Customer Type visibility | B2B or account owner | Restricted Product and Category examples | Buyer access rules are attached to actual records. |
| Menus and landing pages | Storefront owner | Navigation map, screenshots, and linked routes | Presentation paths are separated from catalog structure. |
| Priority URLs | SEO owner | Product, Category, content, and campaign route list | High-value routes have a documented disposition. |
Prepare Customers, Customer Types, Accounts, and Addresses
AmeriCommerce Customer Types can influence pricing, discounts, login redirects, rewards, custom content, shipping methods, and hidden Products. A Customer Type should therefore be prepared as a business-rule relationship, not just a group name. Record which active Customers belong to each type and what the type changes.
Prepare Customers with IDs, names, email addresses, account state, addresses, company details, Customer Type, tax status, communication state, custom fields, account ownership and external keys. Identify duplicate emails, shared company addresses and obsolete type memberships. Include a signed-in buyer example for rules that depend on Customer recognition, then assign authentication handling separately: usable password continuity, reset or activation depends on the exact migration path and identity systems.
| Customer area | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Identity | Resolve or document duplicate and shared email patterns | Customer exception register | Identity exceptions have an owner and treatment. |
| Customer Types | Record membership and every pricing, visibility, redirect, shipping, or content rule affected | Customer Type rule matrix | Each type has documented business meaning. |
| Addresses | Separate reusable Customer addresses from Order-time snapshots | Customer and Order address examples | Current account data is not conflated with transaction history. |
| Tax and exemption context | Record status, evidence owner, and affected Customers | Tax-status sample list | Special tax treatment is not reduced to a label alone. |
| Custom fields and external IDs | Identify system owner and downstream use | Field dictionary and integration references | Operational identifiers remain traceable. |
Prepare Orders, Statuses, Totals, and Historical Context
Order preparation should preserve the evidence needed by customer service, finance, fulfillment, and account teams. Select Orders from each Store and include examples with variants, Product Groups or kits, Customer Type pricing, discounts, tax differences, split or unusual shipping, refunds, cancellations, manual adjustments, notes, and external references.
Save the Order export criteria and include the fields needed to interpret line items, addresses, statuses, payment and shipping labels, tax, discounts, fees, and totals. Historical labels should be documented as source context; they should not be treated as instructions for live target payment or shipping setup.
| Order area | Action | Evidence | Ready condition |
|---|---|---|---|
| Store ownership | Include Store identifier in the Order evidence | Cross-Store Order sample list | Every sample can be tied to the correct Store. |
| Status history | Record labels, sequence, staff meaning, and customer visibility | Status dictionary and representative Orders | Historical states can be interpreted consistently. |
| Line-item detail | Include selected variants, kit or group context, quantity, SKU, and price | Order-line samples | Purchased configuration remains understandable. |
| Totals and adjustments | Identify tax, shipping, discount, fee, credit, refund, and manual lines | Total-component inventory | Material adjustments have a known source meaning. |
| External references | Record ERP, accounting, CRM, fulfillment, or marketplace identifiers | Integration-sensitive Orders | Downstream lookup requirements are documented. |
Do not edit historical Orders merely to make them uniform. Record anomalies that explain the original transaction. Preserve completed payment and shipment references as history, and separately identify live subscriptions, payment tokens, fulfillment work and notifications that need implementation or controlled reconnection; an imported Order is not permission to replay those actions.
Inventory Content, Integrations, Automation, and Custom Data
Prepare content and dependencies as separate inventories. Content evidence should include pages, blog or educational content, forms, images, downloads, metadata, canonical expectations, internal links, and redirects. Dependency evidence should include ERP, accounting, CRM, tax, shipping, inventory, fulfillment, marketplace, analytics, email, and Product information systems.
For every integration or automated process, record the system owner, direction of data flow, schedule or trigger, identifiers used, fields read or written, and what should happen during the migration period. Custom fields or scripts should be classified by business purpose rather than collected without interpretation.
| Dependency | Owner | Evidence | Ready condition |
|---|---|---|---|
| ERP or accounting | Finance or systems owner | Item, Customer, Order, invoice, and tax identifiers | Required lookup keys are known. |
| Inventory or fulfillment | Operations owner | Warehouse codes, supplier IDs, stock authority, shipment references | Stock and fulfillment ownership are explicit. |
| CRM or sales workflow | Sales systems owner | Company, contact, account manager, and contract fields | Account relationships are documented. |
| Marketing and analytics | Marketing owner | Segments, campaign routes, tracking references, consent fields | Marketing data has a clear inclusion decision. |
| Custom source logic | Developer or agency | Scripts, custom fields, hidden tables, scheduled jobs, manual procedures | Non-standard behavior has a named owner and disposition. |
Prepare Exports, Media, Backups, and Change Control
Create a dated evidence archive with Product, Customer, Order, Category, content, pricing, custom-field and integration inputs, plus media, screenshots and extraction criteria. Keep originals unchanged and work from copies. For a hosted Source, available exports and media are evidence recovery assets, not a guarantee that the provider can restore the entire Store; record the recovery coverage, limitations and responsible contact.
| Evidence set | Required contents | Ready condition |
|---|---|---|
| Data exports | Source files, export criteria, Store scope or applicable filters, date, field mapping, checksum | Files are complete and attributable. |
| Media archive | Product, Category, content, document, and downloadable assets | Original files can be matched to source records. |
| Configuration evidence | Store, active-catalog, Customer Type, pricing, status, and tax screenshots or reports | Rules not represented in ordinary exports are documented. |
| Backup and recovery note | Available platform backups, downloaded exports, media archive, account contacts | Source evidence can be recovered if questions arise. |
| Change log | New or edited Products, Customers, Orders, URLs, rules, and integrations after capture | Later source changes can be reconciled. |
Select Representative Migration Test Records
Choose representative migration records deliberately. The sample should include ordinary records and the structures most likely to reveal a scope or mapping issue. For AmeriCommerce, this normally means records from different Stores, active catalogs, Customer Types, Product patterns, and integration contexts.
| Sample group | Include | Preparation purpose |
|---|---|---|
| Products | Simple Product, variant Product, variant-inventory Product, Product Group, kit, restricted Product, advanced-pricing Product | Expose distinct catalog and pricing relationships. |
| Customers | Default buyer, special Customer Type, tax-exempt account, company or managed account, duplicate-email exception | Represent identity and buyer-rule differences. |
| Orders | Different Stores, statuses, discounts, tax cases, refunds, grouped or kit line items, external references | Preserve historical operating context. |
| Content and URLs | Priority Product, Category, page, campaign, and redirect routes | Prepare route and content decisions. |
| Integrations | Product, Customer, and Order records containing external IDs | Confirm that required source evidence is included. |
For each sample, write a short source expectation describing the relationships, fields, linked files, and identifiers that make it representative.
Complete the AmeriCommerce Readiness Gate
Preparation is complete when evidence explains each Source Store and its intended AmeriCommerce destination, including active catalogs, Customer Types, Product structures, historical Orders, media, content and integrations. Confirm the destination capability and owner required for each material relationship. Resolve critical gaps, exclude the affected scope or hold it before execution; record the impact and owner of any explicitly accepted exception.
| Final gate | Ready condition |
|---|---|
| Store scope | Every included Store and shared-data boundary is documented. |
| Catalog | Product structures, pricing rules, visibility, and Categories are represented by evidence. |
| Customers | Customer Types, identity exceptions, addresses, tax context, and external IDs are understood. |
| Orders | Store ownership, statuses, line items, totals, and external references are interpretable. |
| Content and URLs | Priority pages, media, metadata, and route decisions are recorded. |
| Dependencies | Integrations, automation, and custom data have owners and dispositions. |
| Inputs | Exports, media, criteria, checksums, backups, and change log are available. |
| Samples | Representative migration records cover ordinary and complex source patterns. |
Conclusion
AmeriCommerce preparation should reveal how Stores, active catalogs, Customer Types, Product structures, pricing, Orders, content, and outside systems work together. The strongest preparation package is not the largest export. It is the evidence set that preserves ownership and meaning across those relationships.
When access, exports, business rules, representative samples, and change control are complete, migration configuration can proceed from documented source truth rather than assumptions.
Common Questions
Should AmeriCommerce exports be combined across all Stores?
Only when Store ownership remains explicit. Retain the Store identifier, selected columns and extraction criteria, including the Store filter where available. Confirm coverage of each included Store and related record family instead of assuming a combined file contains everything.
Why must Customer Types be documented separately from Customers?
Customer Types can affect pricing, discounts, content, redirects, shipping, and Product visibility. Membership alone does not explain the rule that the type controls.
Which Products should be prioritized for preparation?
Include simple Products, variants, variant-inventory Products, Product Groups, kits, restricted Products, advanced-pricing cases, and records with external identifiers.
Should old or inactive Products be deleted before migration?
Not automatically. Classify them as include, exclude, archive, or business-review items. Deleting first can remove evidence needed to understand historical Orders or integrations.
What should be preserved with historical Orders?
Keep Store ownership, line-item configuration, statuses, addresses, totals, discounts, taxes, payment and shipping labels, notes, and external references needed by operational teams.
How should source changes be handled after exports are created?
Maintain a dated change log and identify the owner of each changed area. The log should cover catalog, Customer, Order, URL, pricing, and integration changes that may alter the prepared evidence set.
Must every AmeriCommerce option be included in variant inventory?
No. Record which Variant Groups are inventory-bearing and whether variant inventory is enabled for the Product. Non-inventory choices may affect the offer without creating separate stock combinations. Preserve those choices and their effects, but distinguish them from independently stocked combinations and the base quantity rollup.
Does one Product export provide the complete preparation package?
No. Confirm the export’s Store scope, selected columns and related-record coverage. Customer Type rules, Product Groups, kits, content, media, pricing and integrations may need separate files, reports or configuration evidence. The ready condition is explainable coverage, rather than a particular file count.