AmeriCommerce preparation should make the source Store understandable before migration configuration is finalized. An installation may combine several storefronts, active-catalog restrictions, Customer Types, variants, Product Groups, kits, advanced pricing, custom fields, content, and outside systems. A record export can show what exists, but it does not explain which storefront owns a record, which buyer rule changes its behavior, or which identifier must remain available to another system.
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
Begin by documenting the exact AmeriCommerce account and every Store included in scope. Record administrative access, Store identifiers, active domains, currencies, languages, tax context, current theme ownership, and the staff responsible for catalog, Customers, Orders, marketing, and integrations. When several Stores share data or use different active catalogs, preparation must show which settings and records are global and which are Store-specific.
AmeriCommerce exports can be filtered by Store and configured with selected columns. Save the criteria used for every export so a later file can be traced to a specific Store, date, and field set. Do not assume that one combined export automatically preserves Store ownership.
| 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 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. |
Do not merge similar option names or price rules merely to simplify the source. Two labels that appear equivalent may differ by Store, Customer Type, stock ownership, or external-system usage.
Document Storefronts, Active Catalogs, Categories, and Discovery
AmeriCommerce can restrict the visible catalog by Store through active-catalog settings. Customer Types can also affect Product visibility, content, redirects, discounts, and shipping behavior. Preparation therefore needs more than a Category tree: it needs a visibility map showing which buyers can discover which Products in which Store.
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, login state, billing and shipping addresses, company details, Customer Type, tax status, newsletter or communication state, custom fields, sales or account ownership, and external identifiers. Identify duplicate emails, shared company addresses, inactive accounts, and records whose Customer Type no longer reflects current business use.
| 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 simply to make them uniform. Record anomalies separately when they explain the original transaction.
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 rather than a loose collection of files. Store Product, Customer, Order, Category, content, pricing, custom-field, and integration exports together with media files, screenshots, export criteria, and explanatory notes. Keep original files unchanged and perform any cleanup or analysis in working copies.
| Evidence set | Required contents | Ready condition |
|---|---|---|
| Data exports | Source files, export criteria, Store 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 the source evidence can answer the questions that control migration scope. The team should be able to identify each Store, explain active-catalog and Customer Type rules, distinguish Product structures, interpret historical Orders, locate media and content, and name the owner of every material integration.
| 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. Keep the Store filter, export criteria, and Store identifier with every file so shared and Store-specific records can still be distinguished.
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.