Supported Data Types and Processing Order
Determine what the selected path can process, why availability varies, how data relationships constrain selection, and the sequence Next-Cart uses for supported data.
Supported Data Types and Processing Order
Section titled “Supported Data Types and Processing Order”The selected migration path determines which customer-facing data types appear and the sequence in which Next-Cart processes them.
Selecting a data type includes that kind of supported source data in the migration scope. It does not set a record quantity, create a record-level filter, or guarantee that every source field and relationship has a direct target equivalent.
Customer-facing data types
Section titled “Customer-facing data types”The active migration path determines which of these data types can be selected. Only the documented Demo exclusions are marked below.
- Taxes
- Manufacturers
- Categories
- Products
- Customers
- Orders
- Reviews: unavailable in Demo Migration.
- Coupons: unavailable in Demo Migration.
- CMS Pages
- Blog Posts
Conditional availability
Section titled “Conditional availability”Data-type availability is determined by the supported migration path, not by a universal Next-Cart catalog.
| Situation | Operational meaning |
|---|---|
| A data type can be selected in Select Data | It is available for the selected migration path and active configuration. |
| A data type does not appear | The standard path does not expose it for selection. Confirm the platform guides and purchased scope before treating the absence as an interface defect. |
| A data type appears but a source field is not represented | The field can be unsupported, mapped to a different target structure, transformed through an approved rule, or require Custom Service assessment. |
| The source contains app, plugin, module, or external-system data | Do not assume that selecting a related standard data type includes that separate data source. Confirm the supported source location and agreed scope. |
| A purchased Add-on is available | The Add-on can filter, transform, or redirect supported data within its defined boundary; it does not create a new supported data type. |
Use Add-ons, Customization, and Custom Service Boundaries when the required source or target behavior extends beyond standard data-type support.
How to qualify a migration-capability question
Section titled “How to qualify a migration-capability question”A question such as “Can this be migrated?” often refers to more than the top-level data type. Qualify the exact requirement before treating a selected data type as proof of complete support.
| Requirement pattern | What to verify |
|---|---|
| Entire data type, such as Products, Customers, Orders, Reviews, or Blog Posts | The data type appears for the active migration path and is included in Select Data. |
| Product variants, options, attributes, Manufacturers, brands, multilingual values, or multi-store scope | The source structure is accessible, the selected path represents the required fields or structure, and the Target Platform has an approved representation that preserves the required meaning. |
| Relationship data, such as Product-Category, related Products, Customer-Order, Review-Product, or parent-child structures | Both required records and the relationship itself must be supported and validated. Migrating both record types does not by itself prove that every relationship is preserved. |
| Invoices, shipments, credit documents, subscriptions, gift cards, abandoned carts, downloadable assets, attachments, or other specialized structures | Do not infer support from Orders, Products, or another related top-level type. Confirm the exact source structure and agreed path or Custom scope. |
| App, plugin, module, custom-table, or external-system data | Confirm that the source location is exposed through the supported connection and included in the agreed scope. A related standard entity does not automatically include extension-owned data. |
| Images, video references, downloadable media, or other assets | Verify both the data reference and asset accessibility, then validate the Target Platform representation and association with the correct parent record. |
| Target notifications, email automation, storefront behavior, tax behavior, payment behavior, or application behavior | Treat this as target-store operation unless the migration scope explicitly owns the behavior. Migrating historical records does not automatically configure future target behavior. |
Use Platform Data Models and Migration Boundaries when the source and target represent the same business concept differently. Use Prepare Custom Service Requirements when the required data, relationship, extraction, or target behavior remains outside the verified standard path.
Relationship-dependent data
Section titled “Relationship-dependent data”Some selected records require parent or related records to preserve usable relationships. Next-Cart can select required dependencies automatically when the selected path establishes them.
Common relationship patterns include:
- Products can depend on Manufacturers, Categories, Taxes, attributes, options, and inventory structures;
- Orders can depend on Customers, Products, Taxes, Coupons, shipping values, and historical status information;
- Reviews can depend on Products and Customers;
- content media can depend on the parent Product, Category, CMS Page, or Blog Post record.
Platform-specific and specialized qualification
Section titled “Platform-specific and specialized qualification”The data types above are the customer-facing categories. Platform-specific structures still require qualification against the exact Source Platform, Target Platform, selected path, and target data model.
Shopify Products, variants, options, and attributes
Section titled “Shopify Products, variants, options, and attributes”Separate sellable variants from descriptive attributes and custom metadata. A source option may become a Shopify variant option, metafield, application-owned structure, or another approved representation. Do not assume that every source attribute should create a sellable variant.
For Shopify Category hierarchy and collection representation, use Platform Data Models and Migration Boundaries.
Shopify invoices are separate from Orders
Section titled “Shopify invoices are separate from Orders”Do not treat an invoice as interchangeable with the migrated Order record. If historical invoice documents or invoice-application data are required, identify the Shopify representation applicable to the Target Store and qualify that requirement separately from standard Order migration.
Magento invoices, shipments, and credit memos
Section titled “Magento invoices, shipments, and credit memos”Invoices, shipments, and credit memos are distinct Order-related records. Confirm that the active Magento path and project scope include the required record types and relationships. Migrating Orders alone is not proof that every related document or transaction record is included.
Product images and media storage
Section titled “Product images and media storage”Image URLs, stored image files, description-embedded images, and target-media records are different layers. Validate that required images are transferred or made accessible through the approved path and that the Target Store references the correct media after migration.
WooCommerce bundle, composite, and custom-option Products
Section titled “WooCommerce bundle, composite, and custom-option Products”WooCommerce bundle, composite, and custom-option behavior may be native to a specific Product structure or owned by an extension. Confirm the target representation before assuming that source Product relationships can be flattened into standard variations.
Product variations across platforms
Section titled “Product variations across platforms”A variation usually depends on a parent Product plus option/attribute combinations and target-specific variant rules. Confirm which source combinations should remain sellable variants and which values should become attributes, metadata, or another target structure.
WooCommerce manufacturer and brand data
Section titled “WooCommerce manufacturer and brand data”Manufacturer or brand data can map to a native brand/taxonomy feature, an extension-owned structure, a Product attribute, or another approved destination. Confirm the Target Store representation and relationship to Products before migration.
WooCommerce multilingual data
Section titled “WooCommerce multilingual data”Multilingual WooCommerce data is more than duplicate text. Confirm the language system or plugin that owns translations, the relationships between language variants, and how those relationships should exist on the Target Store. Do not infer support for one multilingual implementation from another.
Shopify multilingual data
Section titled “Shopify multilingual data”Confirm the languages enabled for the Target Store and the target representation for translated Product, collection, page, and other supported content. Migration of base content does not by itself prove that every translation relationship or storefront language behavior is configured.
BigCommerce variants and option combinations
Section titled “BigCommerce variants and option combinations”Do not hard-code a historical variant or option limit as permanent product truth. Qualify representative high-complexity Products against the BigCommerce model that applies when the migration is performed, including variant combinations, unavailable choices, inventory behavior, and accepted fallbacks.
OpenCart multi-store
Section titled “OpenCart multi-store”Multi-store migration requires explicit Source Store scope and Target Store representation. Confirm which store contexts, Products, Categories, Customers, Orders, languages, and store-specific relationships belong to the project. Do not infer complete multi-store behavior from a generic OpenCart connection.
PrestaShop multistore
Section titled “PrestaShop multistore”For PrestaShop multistore projects, identify the relevant shop/group context and the data that is global versus shop-specific. Confirm the accepted target representation before migration rather than assuming that every shop relationship transfers automatically.
CS-Cart Multi-Vendor
Section titled “CS-Cart Multi-Vendor”Multi-vendor data introduces vendor ownership, vendor-specific catalog relationships, and marketplace behavior beyond ordinary Product migration. Confirm the exact Source edition/setup and the Target Store representation. Treat vendor data or marketplace behavior outside the standard path as a separate qualification requirement.
Wix Blog content
Section titled “Wix Blog content”Blog Posts are a separate data type from Products and CMS Pages. Confirm whether the active path exposes Blog Posts for the Wix role involved and how the Target Store represents the content. If the required blog structure is not supported by the standard path, qualify it separately rather than assuming that Product or Page migration includes it.
Joomla commerce data
Section titled “Joomla commerce data”Joomla is a CMS; commerce data is normally owned by an e-commerce extension or component. Identify the exact extension that stores Products, Categories, Customers, Orders, and related data before selecting the migration approach. A generic Joomla label is not enough to prove commerce-data support.
Special characters and text encoding
Section titled “Special characters and text encoding”Preserve text as text, not as a visual approximation. Validate representative accented characters, non-Latin scripts, symbols, punctuation, and emoji through the complete source export/connection, migration, target storage, and storefront-rendering path. Encoding corruption is a data-quality defect even when the record count is correct.
Downloadable Products and files
Section titled “Downloadable Products and files”A downloadable Product can include both a Product record and one or more binary files plus access relationships. Confirm how the files will be transferred, where they will be stored on the Target Store, and how Customer or Order access will be represented. Large or externally stored files can require separate transfer work or Custom scope.
Product videos
Section titled “Product videos”Video handling depends on whether the source stores a file, URL, embed, external-media reference, or extension-owned object. Confirm the accepted Target Store representation and do not treat Product video as ordinary Product-image migration.
Shopify historical tax data
Section titled “Shopify historical tax data”Historical tax values stored on migrated Orders are separate from the Target Store’s future tax configuration. Validate the historical Order amounts that must be preserved, then configure Shopify tax behavior for new transactions through the settings applicable to the Target Store. Migration does not replace target tax setup.
Shopify related Products
Section titled “Shopify related Products”A source related-product, cross-sell, or up-sell relationship must be mapped to an accepted Shopify representation. Confirm whether the project uses native merchandising features, application-owned data, metafields, or another approved structure before treating the relationship as migrated.
Shopify Product and variant limits
Section titled “Shopify Product and variant limits”Do not use a historical numeric Product, variant, or option limit as permanent Documentation truth. Verify the Shopify model and limits that apply to the Target Store when the migration is planned, then test representative high-variation Products against that model. If the source structure exceeds the usable target representation, define an accepted transformation or Custom requirement before migration.
Product relationships by Target Platform
Section titled “Product relationships by Target Platform”For Magento, WooCommerce, BigCommerce, PrestaShop, OpenCart, Shopify, and other targets, qualify each relationship by its actual business meaning and target representation. Related, cross-sell, up-sell, accessory, parent-child, Category membership, and extension-owned relationships are not interchangeable.
Confirm that the required relationship is supported or explicitly scoped, then validate representative Products and their linked records on the Target Store.
Complete processing sequence
Section titled “Complete processing sequence”The customer-facing processing sequence is:
Taxes → Manufacturers → Categories → Products → Customers → Orders → Reviews → Coupons → CMS Pages → Blog Posts
The progress list contains only the data types included and available for the migration activity. A shorter visible list does not change the relative order of the data types that are processed.
How to interpret the sequence
Section titled “How to interpret the sequence”| Observation | Correct interpretation |
|---|---|
| An earlier data type is still processing | A later data type can remain pending because the activity has not reached it. |
| An earlier supporting data type is Failed or unexpectedly Skipped | Later records can exist but contain incomplete relationships. Classify the supporting failure before approving the result. |
| A data type reaches Success | Its processing completed successfully according to the activity result; validation is still required to confirm accuracy and usability. |
| A data type is Failed | Processing did not complete successfully for the affected scope. Review the activity evidence and correct the cause before relying on related results. |
| A data type is Skipped | Next-Cart did not process the affected scope. Determine whether the skip was expected from selection, filtering, source conditions, dependencies, or platform constraints. |
| A data type is absent from progress | It was unavailable, unselected, or not included in the migration activity. Confirm the configuration rather than assuming it completed silently. |
Processing completion is not migration-result approval. Use the Validation section to confirm record identity, values, relationships, target behavior, and accepted limitations.
Data selection, filtering, actions, and capacity
Section titled “Data selection, filtering, actions, and capacity”These controls answer different questions:
| Control | Question it answers |
|---|---|
| Select Data selection | Which supported data types are included? |
| Data Filter | Which supported records inside a selected data type meet the configured field-level conditions? |
| Migration action | Which configuration path and earlier-result treatment apply? |
| Source Platform Options | Does the activity resume interrupted processing or read only newly added source records, when available? |
| Entity Points Plan | How much counted-record capacity is available to the purchased migration service? |
Entity Points are calculated from eligible Products, Customers, Orders, and Blog Posts. The presence of Taxes, Manufacturers, Categories, Reviews, Coupons, or CMS Pages does not make those data types independently counted merely because they are processed.
When a required data type or field is unavailable
Section titled “When a required data type or field is unavailable”Use this decision sequence:
- Confirm the correct Source Platform, Target Platform, purchased service, and migration path.
- Confirm that the expected data type is not already represented under the approved customer-facing name.
- Review the platform-specific guide and source-access setup for required data exposure.
- Determine whether the requirement is a standard field, a different target-model representation, app or plugin data, a custom source field, or a non-standard relationship.
- Use standard mapping or a purchased Add-on only when the selected path supports the required source and target fields.
- Prepare a Custom Service requirement when the required data or behavior remains outside the supported path and is essential to the accepted result.
Do not start another migration activity merely because a data type is missing from the configuration. First determine whether the requirement is unsupported, inaccessible, incorrectly scoped, or attached to another source system.
Related tasks
Section titled “Related tasks”- Use Select Data to select available data types and review dependencies.
- Use Run a Full Migration to monitor the processing sequence and results.
- Use Entity Points to understand counted-record capacity and consumption.
- Use Platform Data Models and Migration Boundaries to classify expected target transformations and requirements outside data migration.
- Use Missing Data when a selected record or relationship is absent or cannot be found.