Prepare an AmeriCommerce migration by documenting what each source record means, where it belongs and who will make the intended target behavior work. A Product export alone cannot explain buyer-specific prices, tracked combinations or the system that controls stock.
Keep two preparation tasks distinct:
- Actual Source: collect accessible records, relationships, configuration evidence and recoverable originals under its own data model.
- Intended AmeriCommerce destination: identify the stores, catalog rules, account behavior and integrations required for the agreed scope, with a responsible owner for each.
Use only the cases your business has. A single retail storefront needs a complete ordinary buying path; it does not need invented wholesale or Multi-Store requirements. Native AmeriCommerce capabilities also do not establish what a particular migration path will transfer.
The AmeriCommerce migration page is an entry point for reviewing transfer directions. Use the checklist below to prepare the evidence behind that review.
Define Source Access and the Intended Store Boundary
Record the Source platform and account, included storefronts and their intended AmeriCommerce destinations. Keep identifiers, domains, status, business purpose, currencies, languages and tax context alongside the owner of each area. Separate shared catalog or customer data from store-specific settings, pricing, content and theme work.
| Area | Evidence and owner | Ready condition |
|---|---|---|
| Source access | Access owner: required connection or agreed exports, permissions, restrictions and technical contact. | The selected path can reach the intended account and required records; access success is not final data approval. |
| Destination setup | AmeriCommerce administrator: intended stores, enabled capabilities, access roles, domains and target prerequisites. | The target design and setup responsibilities are explicit, independently of source recovery. |
| Shared and store-specific scope | Commerce owner: source-to-target store map, catalog boundaries, prices, content and configuration differences. | Every included store has a purpose; shared data is distinguishable from per-store behavior. |
| Extraction record | Data owner: export family, selected columns, field meanings, date, applicable criteria, store scope and checksum. | Each file is attributable and reproducible; related-record coverage is checked separately. |
If AmeriCommerce is the Source, its export tools provide different data families and configurable columns; the Order export documents a Store criterion where applicable. Record the controls actually used rather than assuming every export has the same filters. For another Source, retain its equivalent extraction evidence.
Keep credentials outside planning files. For connection procedures, use Prepare Source and Target Store Access.
Prepare Products, Stock Relationships and Prices
Start with a catalog inventory tied to original IDs. Group the required fields by their purpose:
- Identity and placement: Product ID, item number or SKU, status, store visibility, Active Catalog placement, Categories and manufacturer.
- Commercial and physical values: base price, tax class, quantity, weight, conditional prices and external identifiers.
- Presentation and relationships: images, content, variants, Product Groups, kit components and custom fields.
Select examples from each materially different pattern actually used. Similar names are insufficient grounds for merging records with different store, buyer, stock or fulfillment meanings.
| Pattern | Evidence to collect | Ready condition |
|---|---|---|
| Variants and Variant Groups | Catalog owner: values, display order, required selections, Product assignments, price or weight effects and representative pages. | Selectable choices and their effects remain identifiable. |
| Variant inventory | Inventory owner: enabled state, participating groups and combination-level identifiers, quantities, prices, images, weight, status and applicable overrides. | Tracked combinations are separate from non-inventory choices; inherited values and the base quantity rollup are understood. |
| Product Groups and kits | Catalog and fulfillment owners: group type, parent/child Products, component quantities, sellability, prices, inventory and shipping treatment. | The actual group model is documented rather than treated as an ordinary variant. |
| Conditional pricing | Pricing owner: affected Products or combinations, store, Customer Type, quantity thresholds, dates, formula or amount and overlapping rules. | The expected price is explainable for a named buyer, Product and quantity. |
| Custom fields | Data owner: descriptive, operational, integration-owned or obsolete classification, sample values and intended consumer. | Every business-critical value has a destination decision and responsible owner. |
AmeriCommerce variant inventory tracks combinations of participating groups. Non-inventory choices remain separate, and the base quantity can be the sum of combination quantities. Capture that relationship so preparation does not double-count stock. Record any source-specific pattern that needs a different target representation.
For a non-standard relationship that remains unresolved after supported-path review, prepare examples for a Custom Migration feasibility review. That review does not itself promise transfer or target implementation.
Map Catalog Visibility and Buyer Rules
Active Catalog settings determine the available Category selection for a store. Prepare the Category tree and the buyer-by-store visibility rules separately from menus and landing pages.
The catalog owner should retain:
- Category records: IDs, parents, status, store association, Active Catalog state, assignments, content, images, sort order and important URLs.
- Discovery paths: menus, landing pages, manufacturer routes, attribute-driven discovery, search expectations and internal links.
- Buyer boundaries: restricted Products, affected Customer Types, intended audience and examples of allowed and excluded access.
Customer Type product hiding is unavailable when the store uses Show All Catalog. An Active Catalog screenshot therefore does not establish every access rule. The administrator and account owner should document the actual setting, record assignment and expected buyer outcome.
Where Microstores are used, record their intended catalog, prices, content and buyer routing. They share the main site's domain, theme and checkout. Treat separate Multi-Store websites and Microstores according to their actual configuration rather than assuming either provides an isolated customer database.
Prepare Customer Identity and Historical Orders
Customers and account rules
Customer Types can influence prices, discounts, content, login redirects, rewards and shipping as well as Product visibility. Record membership and each configured effect. A type called “Wholesale” does not prove an approval workflow, tax exemption or payment entitlement.
The account owner should prepare:
- Identity: Customer IDs, names, email, account state, company details, ownership, duplicate-email exceptions and obsolete memberships.
- Addresses and tax context: reusable account addresses, exemption evidence and responsible reviewer, kept distinct from Order-time snapshots.
- Continuing use: communication state, custom fields, external keys and a signed-in sample for identity-dependent rules.
Assign authentication handling separately. Password continuity, resets or activation depend on the exact migration path and identity systems; do not infer them from a present Customer record.
Orders and transaction meaning
Finance, customer service and fulfillment owners should retain interpretable history. Collect store ownership, Customer and line-item references, purchased variants or components, quantity, SKU, price, addresses, statuses, notes and external IDs.
Include the relevant exceptions: Customer Type prices, discounts, tax differences, unusual or split shipping, cancellations, refunds and manual adjustments. Record the original meaning of tax, shipping, discount, fee, credit and refund amounts; do not edit old transactions simply to make them uniform.
Keep two outputs distinct:
- Historical evidence: status sequence, staff meaning, customer visibility, payment and shipment labels, totals and references needed for later lookup.
- Live implementation: subscriptions, payment tokens, open fulfillment, notifications and connected systems requiring their own setup or controlled reconnection.
Importing an Order is not authorization to replay a charge, shipment or notification.
Inventory Content, URLs and External Dependencies
The content and SEO owners should inventory pages, blog or educational content, forms, images, downloads, metadata, canonical expectations, internal links and redirects. Give priority Products, Categories, service pages and campaign routes a documented destination, retention or retirement decision.
Record outside systems by the evidence their owners must provide:
- Finance and operations: ERP or accounting item, Customer, Order, invoice and tax identifiers; warehouse codes, suppliers, stock authority and shipment references.
- Sales and marketing: CRM company/contact relationships, account managers, contract fields, segments, campaign routes, tracking and consent values.
- Other dependencies: tax, shipping, marketplace, analytics, email and Product information systems, with their identifiers and required fields.
- Custom behavior: scripts, custom fields, hidden tables, scheduled jobs and manual procedures, with an inclusion, replacement or retirement decision.
For each integration, name its owner, data-flow direction, schedule or trigger, fields read or written and intended migration-period behavior. Retaining a field does not reconnect its consumer. Keep unsupported extraction, custom-data handling and live implementation as separate scope questions.
Preserve Inputs and Track Source Changes
Create a dated evidence archive. Keep originals unchanged and work from copies, retaining the link between source IDs, prepared inputs and any approved cleanup.
| Evidence set | Contents and readiness |
|---|---|
| Data and extraction criteria | Product, Customer, Order, Category, pricing, content, custom-field and integration inputs with dates, store scope, applicable filters, selected columns, mapping notes and checksums. |
| Media and configuration | Original Product, Category, page, document and download files linked to records; screenshots or reports for store, catalog, Customer Type, pricing, status and tax rules. |
| Recovery coverage | Available platform backups, exports, media and responsible account/provider contacts, with tested access and known restoration limits. A hosted-source export is not a promise of full-store restoration. |
| Change log | New, edited or deleted Products, Customers, Orders, URLs, prices, rules and integrations after capture, with date and owner. Record how each change affects the prepared inputs. |
When AmeriCommerce is the Source, its backup guide separates common data exports from theme export. Verify that required related records, assets and configuration are actually recoverable; a familiar backup label is insufficient evidence.
Choose Representative Samples and Close the Readiness Gate
Write an expected outcome beside each sample's source IDs, relationships, linked files and external keys. Choose ordinary records first, then include relevant exceptions:
- Products: variants, tracked combinations, groups, kits, restricted Products and conditional pricing where used.
- Customers: default buyers, distinct Customer Types, exemption or company contexts and identity exceptions that exist.
- Orders: included stores, meaningful statuses, discounts, taxes, refunds, component lines and external references.
- Content and dependencies: priority Product, Category, page, campaign and redirect routes, plus integration-sensitive records.
A standard Demo provides limited representative evidence. It does not test Add-ons or Customization, and Reviews and Coupons are unavailable as standalone Demo data types. Plan separate purchased-scope evidence where required; do not discard a valid requirement because it cannot appear in that sample.
| Gate | Ready condition |
|---|---|
| Scope and catalog | Access works; source-to-target store boundaries, Product structures, prices, visibility and Categories have evidence and owners. |
| Customers and history | Identity exceptions, Customer Types, addresses, tax context, Order ownership, statuses, lines, totals and external keys are interpretable. |
| Content and dependencies | Priority routes, media and metadata have decisions; integrations, automation and custom values have consumers and responsible owners. |
| Inputs and samples | Recoverable originals, extraction criteria and change log are available; representative samples cover the actual business patterns. |
| Required gaps | Target capabilities and implementation owners are confirmed. Critical gaps are resolved, formally excluded with their impact understood, or held before execution. |
Preparation approval means the intended work can start from documented evidence. It does not certify a completed target store. Use AmeriCommerce validation priorities to define the proof that must follow execution.
Conclusion
An AmeriCommerce preparation package should explain relationships, preserve recoverable inputs and make target responsibilities explicit. Close each required gap before it becomes an unexplained migration result.
If capability or execution responsibility remains unclear, use Selecting the Right Migration Approach for AmeriCommerce to frame the scope decision. Then hand the agreed samples and expected outcomes to the validation owners.
Common Questions
Should AmeriCommerce exports be combined across all Stores?
Combine them only when ownership and coverage remain traceable. Keep store identifiers, selected columns, export family, date and extraction criteria, including the Store filter where available. Check related records separately; one file does not establish complete coverage.
Why document Customer Types separately from Customers?
Membership identifies the buyer classification; the rule record explains its pricing, discount, content, redirect, rewards, shipping or visibility effect. Record the actual configuration, including the catalog-setting dependency for Product hiding.
Which Products should be prioritized for preparation?
Prepare ordinary Products and each materially different pattern used by the business: variants, tracked combinations, groups, kits, restricted Products, conditional prices and external identifiers. The sample should expose relationships rather than satisfy a fixed complexity checklist.
Should old or inactive Products be deleted before migration?
Classify them as include, exclude, archive or business-review items before cleanup. Preserve evidence needed by historical Orders and integrations, with original identifiers linked to any approved changes.
What should be preserved with historical Orders?
Retain store ownership, purchased configuration, Customer and address context, statuses, totals and adjustments, payment/shipping labels, notes and external references needed for interpretation. Record live payment, subscription and fulfillment requirements separately.
How should source changes be handled after exports are created?
Keep a dated change log with an owner for new, edited or deleted catalog, Customer, Order, URL, price, rule and integration data. Reconcile those changes with the prepared inputs and chosen later-run scope; a saved configuration is not an automatic synchronization of edits.
Must every AmeriCommerce option be included in variant inventory?
Record which Variant Groups participate and whether inventory tracking is enabled for the Product. Non-inventory choices can affect the offer without creating stocked combinations. Keep their effects separate from combination quantities, overrides and the base quantity rollup.
Does one Product export provide the complete preparation package?
Check selected fields, store scope and related-record coverage. Pricing, variants, inventory combinations, groups, Customer Type rules, content, media and integration evidence may require separate inputs. Readiness depends on explainable coverage and recoverable originals.