Platform Data Models and Migration Boundaries

Platform Data Models and Migration Boundaries

Use this reference to classify an unexpected result as an acceptable transformation, migration defect, Target Store setup task, or non-standard requirement.

A migration translates supported data from the Source Platform model into the Target Platform model. It does not clone the source platform’s database, theme, application ecosystem, or operating rules. The correct result preserves the approved business meaning, relationships, and usable target behavior within the supported path and acceptance criteria.

Different does not automatically mean correct

Accept a platform-model difference only after confirming the source record, target representation, required relationships, operational consequence, and approved pass condition. An unexplained omission, incorrect relationship, or unusable result remains a defect even when the platforms differ.

Five boundaries to classify

Boundary	What it determines	Typical evidence
Source accessibility	Whether Next-Cart can read the required record, field, file, media asset, or relationship from the supported source connection	Source record, export or API availability, permissions, file completeness, stable identifier
Supported migration path	Whether the Source Platform → Target Platform path supports the data type, field, option, mapping, or relationship	Data selection, available controls, purchased scope, platform guide
Target data model	How the target stores and relates the migrated meaning	Target record structure, identifiers, grouping, status, field destinations, relationships
Target-store operation and presentation	Whether target settings, theme, navigation, channels, indexing, tax, shipping, payment, or applications make correct data usable and visible	Target admin record, storefront result, channel and application configuration
Non-standard requirement	Whether the expected outcome requires unsupported extraction, bespoke logic, a custom relationship, or a new target behavior	Testable requirement, source location, target destination, rules, examples, dependencies, acceptance criteria

Classify the boundary before changing configuration or starting another migration activity.

Common platform-model transformations

Categories, collections, and navigation

The Source Platform and Target Platform can use different taxonomy models. A source Category hierarchy can become a collection, grouping, flattened structure, root-category assignment, or another supported target representation.

Validate:

• Product membership and discoverability;
• required parent-child meaning where the target supports it;
• Root Category Mapping and related configuration;
• target navigation ownership separately from the migrated grouping data.

Menus, theme navigation, and merchandising presentation can require target-side setup even when Category or collection relationships are correct.

Shopify Categories and collection hierarchy

Shopify collections do not provide a guaranteed one-to-one representation of a source Category hierarchy. A source tree can carry several different kinds of meaning at once: Product membership, parent-child organization, storefront navigation, merchandising, and URL/SEO structure. Those outcomes must be evaluated separately on Shopify.

Before accepting the target representation, verify:

• which Products belong to each intended Shopify collection;
• whether a source parent-child Category relationship needs an explicit Shopify grouping or is instead represented through navigation;
• whether storefront menus reproduce the intended browse path when nested presentation is required;
• whether collection handles/URLs and required redirects preserve the approved SEO outcome;
• whether any automated collection rule or target-side merchandising logic changes membership after migration.

Treat migrated collection membership separately from storefront navigation. Correct Product-to-collection relationships do not automatically recreate source menus or visual nesting, and a visually nested menu does not by itself prove that the underlying collection relationships are correct.

Products, variants, options, and attributes

Platforms can represent Product structure through different combinations of parent Products, variants, options, attribute sets, Product types, custom fields, or separate records.

An approved transformation must preserve the required:

• Product identity and stable business identifiers;
• option labels and selectable combinations;
• variant-to-parent relationship;
• prices, inventory, images, and status where included;
• attributes needed for merchandising, filtering, integration, or operations.

A target limit or structural rule does not justify silently dropping a required combination or value. Record the accepted representation or define Custom Migration work when the supported model cannot meet the requirement.

Manufacturers and brand fields

A source Manufacturer can be represented as a target brand, vendor, Product field, taxonomy value, or another supported structure. Validate the target field and Product relationship required by merchandising, filtering, search, and downstream integrations.

Inventory locations and stock

The target can use a different inventory-location model. Stock can require location mapping, consolidation, or another supported target representation.

Validate both the migrated quantity and the location ownership expected by the target store. Do not treat correct Product data as sufficient when inventory is attached to the wrong location or channel.

Customers, groups, addresses, and access

Customer fields, address ownership, groups, statuses, and segmentation can differ between platforms. Customer Group Mapping must preserve the intended operational meaning rather than only the source label.

Password continuity is path dependent. Customer Password Plugin support is determined by the exact Source-to-Target pair, not by platform architecture alone. For an unsupported pair, the accepted outcome can require customer activation or a password-reset process. Never collect plaintext passwords as validation or support evidence.

Orders, statuses, fulfillment, and financial values

Order structures can differ in identifiers, Customer links, line items, payment statuses, fulfillment statuses, discounts, shipping, tax storage, refunds, and historical display.

Validate line-level composition and mapped meaning, not only the displayed total. Differences can result from:

• tax-inclusive versus tax-exclusive models;
• platform-specific rounding;
• historical values versus target recalculation or display rules;
• shipping and discount interactions;
• payment and fulfillment status models;
• target identifier constraints.

Acceptance criteria must define whether exact preservation or an approved equivalent is required. Migration of historical Order data does not replace configuration of the target store’s future tax, payment, shipping, refund, or fulfillment behavior.

Reviews and Coupons

Reviews can use different ownership, rating, moderation, and Product-association models. Coupons can use different rule engines, scopes, eligibility conditions, and promotion structures.

Confirm that the migrated target representation preserves the required association and business rule. A visible code or review record alone does not prove that the target behavior matches the accepted requirement.

CMS Pages and Blog Posts

CMS Pages and Blog Posts can migrate as supported content records while the target uses a different editor, page-builder model, theme, URL structure, author model, Category model, or media handling.

Validate:

• titles, body content, dates, authors, Categories, metadata, links, and media where supported;
• content ownership and editability in the target;
• accepted target URLs and redirect requirements;
• target theme or editor work separately from migrated content correctness.

Do not assume that source theme styling, page-builder components, widgets, scripts, embedded applications, or interactive behavior transfer merely because the underlying CMS Page or Blog Post is selected.

Identifiers, handles, URLs, and redirects

Targets can enforce their own identifier, handle, slug, sequence, or uniqueness rules. ID-preservation and SEO URL options are conditional on the migration path.

Keep these outcomes separate:

• preserving or recording a historical identifier;
• migrating a supported SEO URL value;
• generating a target-compatible URL;
• creating a 301 redirect from an old URL to the approved target destination.

A changed target URL is not automatically a migration failure when the accepted target model requires it. A required redirect is still an open launch issue until the approved source URL resolves to the correct target destination.

Images and media

Image correctness has several independent layers:

1. source asset existence and accessibility;
2. successful migration processing;
3. target format, size, filename, and storage acceptance;
4. association with the correct Product, variant, Category, CMS Page, or Blog Post;
5. target theme, crop, derivative, channel, cache, and storefront presentation.

Classify the failing layer before replacing assets or processing records again.

Product reviews and Shopify review import

Shopify review presentation is application-owned rather than a universal native Product field. For Shopify-bound Product reviews, Next-Cart can export the migrated review data to a CSV file for use with a compatible target review application.

Use this workflow:

1. migrate/export the supported review data through the approved migration scope;
2. choose the Shopify review application that will own reviews after launch;
3. confirm that the application accepts the exported fields and CSV structure, adapting the import through the applicable Custom Migration scope when necessary;
4. import the review data into that target application;
5. validate representative ratings, review text, authorship, dates, Product association, publication state, and storefront display.

Do not assume that installing a review application automatically imports historical reviews or that every review app uses the same schema. Review data imported from another system can also have application/channel-specific limitations after import, so validate every channel where the reviews must appear.

Magento website, store, and store-view scope

Next-Cart supports selecting Products from one or more stores in a Magento Source installation. Define the Source stores that belong to the migration scope before execution and verify that their Product/store relationships are represented correctly in the extracted data.

For a Magento Target installation, Products can be migrated to a specific store. Identify the exact Target store that should receive the Products and verify the resulting store assignment after migration.

Magento website, store, and store-view context can also carry language, catalog, configuration, and relationship meaning. Preserve the requested Source scope and Target destination explicitly rather than treating the Magento connection as one undifferentiated catalog.

Product prices with tax, gross and net semantics, and target rules

For supported price-migration paths, Configuration can expose Tax excluded and Tax included as Product-price choices.

• Tax excluded migrates the Product price without adding tax.
• Tax included adds tax to the Product price during migration.
• When Tax included is selected, the migration uses the first tax rate to calculate the tax added to Product prices.
• When Products use different tax rates, choose Tax excluded so the Target Store can apply the appropriate tax treatment to individual Products instead of forcing the first source rate across the catalog.

Validate representative prices after migration, including rounding and the expected tax meaning of the stored Product value.

Shopware gross and net Product prices

When migrating from Shopware to another shopping cart, Configuration can expose Gross price and Net price as the selectable Product-price type. Select the value that should become the migrated Product price and validate representative Products after migration.

Gross and Net values are two price representations with tax semantics. The selected value must match the intended Target Store price meaning rather than being treated as an arbitrary alternate field.

Shopify Product prices and tax adjustments

When migrating Products to Shopify, Next-Cart can add a specified tax percentage to Product prices during migration. If Shopify automatic taxes will be configured manually for the Target Store, skip the migration tax-adjustment option and configure the Shopify tax behavior separately.

Historical migrated Product values and the Target Store’s future tax calculation are separate concerns. Validate the migrated price values independently from tax behavior on new Shopify transactions.

Magento version qualification

The supported Magento version range spans Magento 1.x through Magento 2.4.9. All minor and patch releases within that range are supported, including security and patch releases.

Magento 1 Community Edition and Magento 1 Enterprise Edition are supported as migration Sources, and migration to Magento 1.9 remains supported. Magento 2.4.9 is within the supported Magento range.

The verified supported upper bound is Magento 2.4.9. Do not assume a later Magento release is supported until Next-Cart explicitly adds it to the supported range. Version support does not automatically make extension-owned data, custom database structures, bespoke modules, or third-party behavior part of Standard scope. Qualify those non-standard requirements separately when they affect the migration result.

Preserve record relationships as relationships

Migrating the participating records is necessary but does not by itself prove that every relationship will be recreated. Treat relationships such as Product-Category, Customer-Order, Order-Product, Product-Review, cross-sell, up-sell, parent-child, and extension-owned links as explicit validation targets.

Validate relationships from both directions where the business outcome depends on them. A migrated Order should reference the intended Customer and line-item Products; a Product should appear in the intended Categories or collections; a Review should remain associated with the correct Product; and a related-Product relationship should preserve the intended merchandising meaning rather than merely point to an existing record.

Use stable source and target identifiers to sample normal, missing, and edge-case relationships. When the Target Platform represents a relationship differently, validate the accepted target representation and resulting business behavior rather than requiring source-database identity. A correct record count is not sufficient when the links between records are wrong.

Data migration and target-store setup are separate

Do not treat a target-store setup gap as missing migrated data. Confirm these requirements independently when they are needed for launch:

• theme and storefront presentation;
• menus and navigation;
• sales channels and publication states;
• payment, tax, shipping, and email configuration;
• search indexing, cache, media derivatives, and URL routing;
• applications, plugins, modules, integrations, and external systems;
• scripts, widgets, page-builder behavior, and other platform functionality.

Selection of Products, Customers, Orders, Coupons, CMS Pages, Blog Posts, or another data type does not automatically configure these target capabilities.

Requirements that need separate confirmation

Do not assume the following are included unless the selected migration path and agreed scope explicitly establish them:

• data stored only in an app, plugin, module, custom table, unsupported file, unexposed API property, or external system;
• payment credentials or reusable payment tokens;
• source theme, page-builder layout, scripts, widgets, and application behavior;
• bespoke extraction, conditional logic, calculated values, or custom relationships;
• a target field, storage location, or operational behavior not supported by standard configuration or purchased Add-ons;
• existing integrations, automations, analytics, fulfillment, ERP, subscription, or marketplace behavior.

Use Add-ons, Customization, and Custom Migration Boundaries to identify the correct capability layer.

Classify an unexpected difference

Classification	Evidence pattern	Correct next action
Expected target transformation	The source and target structures differ, but required meaning, relationships, and pass conditions are preserved	Document the target representation and approve it as Pass or Pass with accepted limitations.
Configuration or mapping issue	The supported target structure is available, but selected options, Attribute Mapping, Add-on rules, or approved Customization produced the wrong result	Correct the responsible configuration and define the affected scope for revalidation.
Missing or incorrect migrated data	A required supported record, field, relationship, or value is absent, duplicated, corrupt, or attached to the wrong target record	Diagnose through Troubleshooting and preserve stable source and target identifiers.
Target-store setup or presentation issue	The target admin data is correct, but theme, channels, navigation, cache, indexing, application, or operational settings make it unusable or invisible	Correct the target-side condition and validate the existing record before considering further migration activity.
Unsupported or changed requirement	The required source location, target destination, logic, relationship, or behavior is outside the supported path or approved scope	Prepare or revise a Custom Migration requirement and obtain scope assessment.

Acceptance rule

A platform-model transformation is acceptable only when all applicable conditions are satisfied:

• the correct source record is represented in the target;
• required fields and relationships preserve their approved business meaning;
• the target result is usable for the intended operational task;
• documented limitations do not violate a must-pass acceptance criterion;
• target-side configuration work has a clear owner and completion requirement;
• the result is recorded as Pass, Pass with accepted limitations, or Fail with evidence.

Visual similarity alone is not the acceptance standard, and structural difference alone is not a reason to approve the result.

Related tasks

• Use Supported Data Types and Processing Order to confirm available data types and processing sequence.
• Use Select Data to select supported data types and review dependencies.
• Use Validate Products and Categories for catalog sampling and pass conditions.
• Use Validate Customers and Orders for customer access, relationships, statuses, and financial validation.
• Use Validate Content, URLs, and Redirects for content, metadata, URLs, and redirect evidence.
• Use Missing Data or Image Issues when the result is absent, hidden, incomplete, or incorrectly associated.
• Use Prepare Custom Migration Requirements when the accepted outcome requires unsupported data or non-standard behavior.