Choosing a migration approach for AmeriCommerce starts with the required selling model. A tracked variant combination, a Customer Type price or a product shared across storefronts can each need a different explanation of data and target behavior. A service name alone cannot establish that result.
Within Next-Cart Migration Services, separate four decisions:
- Capability: Which records, fields and relationships the exact migration path supports.
- Execution: Whether the customer or experts perform the agreed migration work.
- Tailored scope: Which required outcomes exceed supported handling and need feasibility review.
- Target implementation: Who configures the storefront, business rules and integrations around the transferred data.
Use the AmeriCommerce migration page to enter exact-path planning. Native platform features do not establish transfer coverage, and expert execution does not turn an unsupported requirement into supported capability.
Define the AmeriCommerce Result Before Selecting a Service
The scope should explain what the new store must do with the data. Product and customer totals matter, but a matching total can hide a wrong stock owner, buyer rule or storefront assignment.
AmeriCommerce-specific questions help expose that difference:
- Variants and stock: Which choices identify tracked combinations, and which only affect selection, price, weight or presentation? With variant inventory enabled, combinations can have their own SKU, quantity and price context; the base quantity can be an aggregate.
- Buyer treatment: Which Customer Types, prices, visibility and purchasing requirements must be represented? A label does not establish the rule. Product hiding by Customer Type is unavailable with Show All Catalog.
- Store boundaries: Which products and customers are shared, and which catalog, price or content differences must remain? A Microstore shares the main site's domain, theme and checkout; separate Multi-Store websites also use a shared backend.
- Operational use: Which order, invoice, content, URL or external references must remain useful for service, finance, warranty, fulfillment or buyer access?
For each concern, decide whether it is supported transfer, a supported adjustment, tailored data handling or target implementation. Identify obsolete data and workarounds deliberately, without discarding required history. The AmeriCommerce risk guide develops the consequences of leaving those relationships unresolved.
Choose Standard or Managed Execution for Supported Scope
Once the path can represent the required data, choose who should execute it. Standard Migration is customer-operated within supported scope. Managed Migration provides expert execution of agreed supported migration work. The capability boundary does not expand merely because execution changes hands.
| Approach | When it fits | What still needs ownership |
|---|---|---|
| Standard Migration | The required records and relationships are supported, and the customer can configure, execute and review the migration. | Scope, configuration, meaningful samples, exceptions, target setup and final acceptance. |
| Managed Migration | The supported work should be executed by experts, with agreed access, timing and review responsibilities. | Business meaning, buyer and store decisions, stakeholder approvals and final verification. Wider launch or implementation responsibilities need explicit agreement. |
A clean retail catalog may suit customer-led execution, but store size is not the deciding factor. A larger catalog with clear relationships can be more predictable than a small one with undocumented account prices or product logic. Conversely, several storefront owners or sensitive timing can justify expert execution even when the underlying data is standard.
Mixed data quality, Demo differences and price-sensitive samples need interpretation under either approach. Agree on cleanup, supported corrections and acceptable differences. Managed Migration does not automatically supply project management, rebuild Customer Type rules or deploy integrations. The customer retains access and responsibility for final verification.
Use Add-ons for a Defined Supported Adjustment
Do not assume that every custom field or complex store requires Custom Migration. First identify whether the requirement fits standard data selection, Additional Options, Attribute Mapping or a purchased Standard Add-on exposed for the active path.
| Add-on | Relevant requirement | Boundary to confirm |
|---|---|---|
| Data Filter | Include or exclude records within selected data types using supported field conditions. | Confirm the data type, field, condition and expected record set, including relevant dependencies. |
| Data Transformation | Change supported values before later mapping stages. | Confirm the available expression, input, expected output and exceptional cases. Unsupported extraction or bespoke multi-record logic needs review. |
| Advanced Data Mapping | Route a supported source or transformed value to a compatible AmeriCommerce field. | Confirm the actual field, complete value, destination meaning and consumer. Mapping changes the destination, not the received value. |
Advanced Database Mapping is unavailable with AmeriCommerce as Target. A supported Source setup cannot override that Target limitation. An essential database-level requirement therefore needs another confirmed supported approach or tailored review; do not force it into an unrelated field or infer support from the connection method.
The full Standard Add-on sequence is Data Filter → Data Transformation → Advanced Data Mapping → Advanced Database Mapping, where each stage is eligible. AmeriCommerce can use its supported stages without becoming custom simply because several are combined. Check their interaction: a filtered record or transformed value changes what later stages receive.
URL handling, description images and later migration timing are separate questions; they are not automatically Add-ons. Confirm the applicable standard options before escalating an unsupported requirement. Likewise, mapping a stored transaction value does not configure live tax calculation, checkout or an integration. Those target functions retain their own owners.
Escalate the Unsupported Portion to Custom Migration
Use a Custom Migration scope review when required handling exceeds the exact path's supported controls. Describe the business outcome, the available source data, the target representation and the evidence that would make it acceptable.
AmeriCommerce concerns that can warrant review include:
- Buyer or account rules that require bespoke relationships or cannot be represented by supported fields and target configuration.
- Product Groups, kits or stock identities that require non-standard splitting, merging or reconstruction.
- Contract prices, quote or invoice context, historical details or custom fields whose required handling exceeds supported scope.
- External identifiers or data owned by ERP, CRM, accounting, fulfillment or other systems that require tailored extraction or processing.
- A storefront or portal structure whose required data assignments have no confirmed supported destination.
These are review triggers, not automatic custom requirements. A company-related field, external ID or grouped product may still fit supported handling. The unsupported portion must be identified rather than classifying the entire project by its most complex label.
Custom Migration supports Self-Execute or Expert Handle for the agreed work. The operation mode changes execution responsibility; it does not remove customer access or final verification. A discussed requirement is not purchased scope until it is assessed and agreed. Themes, widgets, merge codes, Microstores, Customer Type rules, checkout, payment, shipping, tax and live integrations are not automatically implemented by a data migration.
Selecting CSV, XLS or XML as Source Platform requires Custom Migration. The included file workflow covers Products only; Customers, Orders and other data require explicitly approved additional scope. A native platform's File Upload connection is a separate question and does not inherit that generic file-selection rule merely because a file is used.
Apply the Decision to the Required Relationships
The same project can contain ordinary supported records and a narrowly tailored requirement. Record those layers in the agreed service scope, with execution and target implementation assigned separately.
| Concern | Supported route to assess | Escalation or separate responsibility |
|---|---|---|
| Variants, stock and Product Groups | Confirm supported identities, options, component relationships and quantities; choose customer or expert execution for that scope. | Review bespoke conversion or missing relationships. Assign the target purchasing and stock behavior separately. |
| Customer Types, buyer rules and prices | Review supported customer data, standard value alignment, compatible field mapping and relevant value changes. | Scope unrepresented entitlements or bespoke pricing relationships. Configure and approve buyer behavior in the target. |
| Multi-Store and Microstore assignments | Confirm the required shared identity and supported store or catalog assignments. | Review non-standard splitting or merging. Assign access, pricing, content and storefront settings. |
| Orders, content and URLs | Review supported transaction context, CMS records, useful pages and applicable URL or image handling. | Review unsupported history or content structures; assign archives, redirects and storefront presentation where needed. |
| Custom fields and external identifiers | Use supported compatible destinations where they preserve the required meaning. | Scope unsupported extraction or relationships. Assign APIs, webhooks, consumers and ongoing synchronization independently. |
The decision is complete only when each required result has a feasible route and an owner. “Experts will handle it” is insufficient for an undefined buyer rule, and “the field migrated” is insufficient for an integration that has no continuing consumer.
Use Demo Evidence Within Its Actual Limits
Demo Migration examines a limited supported standard sample. It cannot run Add-ons or Customization, and Reviews and Coupons are excluded. A successful Demo therefore cannot establish that a filtered dataset, transformed value, custom relationship or separately configured buyer rule has passed.
Select meaningful available examples and distinguish the question each can answer:
- Product and grouping: Inspect supported identity, choices and relationships; keep any untested combination-stock or component behavior explicit.
- Buyer and storefront: Inspect supported customer fields and assignments; confirm pricing, company context, access and shared-stock behavior separately where they depend on target rules or tailored scope.
- History and references: Inspect available order detail, buyer connections, totals, status, shipping, payment and external references against the defined use.
- Content and routes: Inspect available content and important destinations; keep merge-code presentation, unsupported structures and redirect implementation separate.
Use the findings to classify the gap. A supported configuration correction, a useful reason for expert execution, an eligible Add-on, a tailored requirement and a target-setup issue need different responses. Enhanced and custom outputs require evidence in their agreed paid scope; record counts alone do not establish commercial behavior.
Keep Capacity and Custom Pricing Separate from Complexity
Entity Points provide capacity for eligible Products, Customers, Orders and Blog Posts. They do not measure Customer Type logic, Microstore boundaries, kit relationships, price rules, APIs or integration complexity, and they do not select or filter the records to migrate.
Account terms, approvals, subscriptions and sales-representative workflows remain separate scope questions. Capacity does not certify their required data handling or target behavior.
Estimate the eligible records in the agreed scope, including expected new data before the final activity. Previously counted eligible records remain counted once within the same purchased migration and fixed actual-store path; a later supported action does not by itself consume them again. Required new eligible records can consume capacity when migrated successfully for the first time.
The Custom Migration starting amount uses the Standard Migration price for the selected Entity Points Plan as its floor. The final itemized quote includes approved tailored work, applicable Add-ons and other agreed costs, including Expert Handle when selected. It is not a fixed final project price. Confirm scope and the complete quote rather than using a volume plan as an estimate of engineering effort.
Choose Later Actions by Configuration and Target Intent
After a paid migration has run, the next action should reflect whether its configuration and target result remain useful. A Demo alone is not an earlier paid result to continue. First paid execution uses Perform a New Migration.
| Migration Action | Decision it expresses | What needs review |
|---|---|---|
| Continue the Migration with Last Saved Configuration | The earlier paid configuration remains the intended basis. It is reused unless deliberately edited before execution. | Confirm the loaded scope and intended later data, relationships to earlier records and any target changes. |
| Continue the Migration with a New Configuration | The earlier result remains useful, but supported selections, options, mappings, Add-ons or approved Customization need revision. | Review all affected buyer, store, product, price, history, content and identifier outputs, including previously migrated records where relevant. |
| Perform a New Migration | A fresh configuration and result are required rather than continuing on the earlier basis. | Confirm the complete intended scope, replacement or conflict behavior, target data to protect and all affected relationships. |
Continue the previous migration is a separate Additional Option. It carries the most recent migration state, treats records not transferred in that state as the new-data delta and preserves supported relationship context. Use its supported behavior for later records that must connect to earlier migrated data; choosing a Continue action alone does not establish new-data-only processing.
That option is not a general synchronization of edits to existing source prices, stock or buyer rules, and it is not the control for resuming a paused or stopped execution. Establish the supported approach for the actual change and review new output together with affected earlier records.
A new action does not automatically authorize destructive target clearing or implement payment, tax, shipping, storefront or integration settings. Confirm any intended replacement separately. Before changing the platform path or actual stores, confirm eligibility and purchase requirements; a migration action does not grant permission to substitute them.
Conclusion
Choose the AmeriCommerce approach by matching each required relationship to supported handling, a defined enhancement, tailored scope or target implementation. Then assign customer-led or expert-led execution. Use Demo for its standard sample, paid evidence for enhanced or custom results, and later actions according to the intended configuration and target basis.
The Next-Cart migration services overview provides the service entry points. Carry the actual buyer, stock, storefront and integration requirements into the final scope, along with acceptance owners and any unresolved decision.
Common Questions
Is Standard Migration enough for an AmeriCommerce migration?
It can be when the exact path supports the required data and relationships and the customer can operate and review it. Clean records help, but neither store size nor a familiar entity list establishes support. Confirm the required options, stock, buyer, history and content meaning before choosing customer-led execution.
When should Managed Migration be selected for AmeriCommerce?
When experts should execute agreed supported migration work. The merchant still explains buyer rules, shared-stock and storefront requirements, coordinates business approvals and verifies the result. Wider project management, launch planning, integrations or target implementation require explicit agreement.
When does AmeriCommerce migration need Custom Migration?
When required handling remains outside the exact path's supported configuration and applicable Add-ons, or when the selected Source setup requires it. Examples include bespoke relationship reconstruction or unsupported extraction and processing. Review feasibility and agree the specific scope; a custom field or native feature name alone does not determine the service.
Should Add-ons be selected before Demo Migration?
Identify an eligible Add-on during planning when its supported filter, value change or field destination addresses a defined need. Demo findings can reveal the need, but Demo cannot run Add-ons or Customization. Validate those outputs in the agreed paid scope and keep separate target behavior explicit.
How should the Custom Migration starting price be interpreted?
It starts from the Standard Migration price for the selected Entity Points Plan. The final quote also reflects approved tailored work, applicable purchased Add-ons and other agreed costs, including Expert Handle when selected. Treat the starting amount as a floor and review the complete itemized quote before purchase.
Does matching AmeriCommerce stock prove Customer Type pricing is correct?
No. Tracked combinations, shared storefront stock and configured buyer treatment are distinct relationships. A correct quantity does not establish the intended price or access. Require evidence for each required result and assign any unsupported data handling or target configuration separately.
Can Advanced Database Mapping write custom values into AmeriCommerce?
AmeriCommerce is not supported as a Target for Advanced Database Mapping. Source eligibility does not override that limitation. Assess Advanced Data Mapping only for supported compatible fields; use a scope review when the required handling remains outside supported controls.