Platform Data Models and Migration Boundaries

Platform Data Models and Migration Boundaries

Platform data-model differences can produce target structures that do not look identical to the source store. Classify each difference as an acceptable transformation, migration defect, target-store 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. Define the required browse and navigation outcome, Product membership, merchandising relationships, SEO value, and any nested presentation behavior before accepting the target representation.

Treat migrated Category or collection data separately from storefront navigation. A correct collection relationship does not automatically recreate source menus or visual nesting, so validate the approved Shopify structure against the project’s acceptance criteria.

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 Service 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 target review systems

Review data is meaningful only when the Target Store has an accepted representation for the review record and its Product or Customer relationships. A Product migration does not automatically recreate the source review system, review application, moderation state, storefront widget, or rating display.

Confirm the required review fields, relationships, target owner, and storefront behavior separately.

Magento website, store, and store-view scope

Magento can separate catalog and configuration context by website, store, and store view. When only a specific Magento scope should participate in migration, identify that scope explicitly and verify that the selected records, language/store-view data, and Target Store destination match the project requirement.

Do not infer store-scope filtering from a generic Magento connection alone.

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

A Product price can represent gross or net value depending on the Source Store, while the Target Store may calculate tax through its own tax configuration. Before changing price values during migration, define whether the stored target price should include or exclude tax and how the Target Store will calculate tax after launch.

Do not use a historical fixed tax percentage or an old platform-specific option as a universal rule. The accepted result must be defined for the project and Target Store configuration.

Magento version qualification

Treat Magento version questions as compatibility checks for the exact Source and Target environments, not as a permanent list copied from an old FAQ. Record the edition/version actually in use, the required migration direction, installed extensions that affect data, and the Target Store version that will receive the data.

Use the supported platform and connection guidance in this Documentation together with project evidence to confirm the path. If an exact version combination or extension dependency is not covered by the standard path, qualify it before purchase or through Custom Service.

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.

When the Target Platform represents a relationship differently, validate the accepted target representation rather than requiring source-database identity.

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 Service 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 Service 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 the available customer-facing taxonomy and 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 Service Requirements when the accepted outcome requires unsupported data or non-standard behavior.