Missing Data

Missing Data

Identify whether an expected record is truly absent, outside the compared scope, represented differently by the target platform, or present but hidden by target-store conditions. Use this page when some migration results are available but particular Products, Categories, Customers, Orders, Reviews, Coupons, CMS Pages, Blog Posts, relationships, or required field values cannot be found.

When a completed Demo Migration produces no visible records at all, use No Data Appears After Demo instead. For partial absence, preserve the current evidence and diagnose the smallest affected scope before changing configuration or starting another migration activity.

Do not use counts alone or start another activity immediately

A lower target count does not prove that records failed to migrate. Source status, selected scope, filters, target data-model differences, and target admin views can change the comparison. Confirm representative records by stable identifier before choosing a correction.

Identify the observable problem

Observable result	What it usually means
The target count is lower than the source count, but sampled records can be found	The comparison may include different statuses, dates, stores, languages, archived records, deleted records, filters, or target representations.
Particular source records cannot be found in the target	The records may have been outside the selected scope, ineligible at processing time, filtered out, failed, skipped, or written under a different identifier or target structure.
Parent records exist but related records are absent	A required data type or dependency may not have been selected, processed successfully, or matched correctly.
A record exists but an expected field value is empty or in the wrong place	The field may be unsupported, mapped differently, transformed, redirected through Advanced Data Mapping or Advanced Database Mapping when applicable, or covered by approved Customization.
Records exist in the target admin but not in the expected list or storefront	Target filters, status, visibility, language, site, sales channel, permissions, cache, indexing, theme, or navigation can hide an otherwise present record.
Products or Categories appear under a different hierarchy or structure	The target data model may represent Categories, collections, variants, options, or attributes differently. Confirm the approved result before classifying it as missing.
Updated existing source records were not processed by a newly-added-only activity	Migrate only newly added entities reads records added after the last successful migration run. It does not include existing records that were only updated.
A source-file migration is missing a subset that was never included in the files	The source export or source file set may have been filtered, incomplete, or missing relationship data before migration began.

Prepare evidence before changing anything

Collect enough information to compare the same source and target scope:

• the purchased service and fixed Source Platform to Target Platform migration path;
• the exact migration activity and its date or History entry;
• the source-data window and target environment being reviewed;
• the affected data type and the approved migration scope;
• several affected source records with stable identifiers such as SKU, source ID, customer email, Order number, coupon code, Page title, or source URL;
• corresponding target searches and screenshots using masked personal data where possible;
• Success, Failed, and Skipped results for the affected data type;
• relevant Data, Additional Options, Attribute Mapping, Add-on, and Customization choices;
• the expected result and the actual target result;
• any source record status, archive state, deletion state, language, site, location, or date condition that could affect eligibility.

Diagnose the missing scope

1. Confirm the correct activity and target store

   Verify that you are reviewing the intended migration activity, target URL, store view, site, language, and environment. Do not compare a different Demo, Full Migration, continuation activity, or copied target store.

2. Compare the same source and target scope

   Align the comparison by data type, store or site, language, date range, status, and approved filters. Exclude source records that were archived, deleted, inactive, outside the selected scope, or created after the activity unless the acceptance criteria require them.

3. Review processing evidence

   Check Progress, Success, Failed, and Skipped results for the affected data type. Record the displayed reason for every relevant Failed or Skipped sample instead of assuming that all absent records share one cause.

4. Search the target by stable identifier

   Search the target admin by SKU, source ID, email, Order number, coupon code, title, URL, or another distinguishing value. Clear unintended admin filters and review inactive, draft, hidden, archived, and alternate-language views where applicable.

5. Confirm source eligibility and selected scope

   Verify that each affected source record existed and was accessible when the activity ran. Review the selected data types and any Data Filter rule. For source files, confirm that the record and required relationship fields were present in the source file set.

6. Check relationship dependencies

   Confirm that required parent and related records were selected or already existed in the target with reliable matching. Products can depend on Manufacturers, Categories, and Taxes; Orders can depend on Customers, Products, Taxes, Coupons, shipping, and other historical values; Reviews can depend on Products and Customers.

7. Review mappings, transformations, and target structure

   Check applicable Site, Language, Location, Attribute Set, Root Category, Customer Group, payment-status, and fulfillment-status mappings. Review Advanced Data Mapping, Advanced Database Mapping, Data Transformation, and approved Customization when a record exists but its values, status, destination, or relationship look missing.

8. Separate target visibility from migration absence

   Confirm whether the target record is hidden by publication status, sales-channel assignment, store view, language, permissions, menu configuration, theme behavior, cache, or indexing. Correct target presentation without starting another migration activity when the migrated data is already present.

9. Classify the cause and affected scope

   Document whether the issue is caused by the compared scope, source eligibility, selection, filtering, source input, processing, dependency, mapping, target-model transformation, target visibility, manual target changes, or an unexplained service result. Choose a correction only after this classification is complete.

Apply the safest corrective path

Confirmed cause	Safest corrective action
Wrong activity, target environment, site, or language	Stop the comparison and open the correct result. Do not change migration configuration.
Unsupported or unselected data type	Confirm the migration-path capability and approved scope. Select the data type only when supported and required, or document a Custom Service requirement.
Source record was inactive, archived, deleted, inaccessible, or outside the approved window	Correct the source state or update the accepted scope before deciding whether another migration activity is required.
Data Filter excluded the record	Correct the filter rule and test normal, boundary, and exception examples before processing the affected scope.
Source export or source files were incomplete	Create a complete, consistent export and verify required identifiers and relationship fields before replacing the source files.
Failed or Skipped result explains the absence	Correct the displayed cause, preserve the affected identifiers, and repeat validation only for the corrected scope.
Required dependency or relationship was not available	Restore or include the required parent data and verify relationship matching before processing dependent records.
Attribute Mapping placed the record in an unexpected site, language, group, status, or hierarchy	Correct the responsible mapping and retest the affected records and their operational meaning.
Advanced Data Mapping, Advanced Database Mapping, or Data Transformation used the wrong rule or destination	Correct the rule or target field and retest representative records, including boundary and exception cases.
Target data model uses an approved different representation	Record the transformation as an accepted result when it meets the acceptance criteria. Do not create a duplicate structure solely to imitate the source.
Target filters, visibility, theme, navigation, cache, or indexing hide the record	Correct the target-store condition and verify the existing record. Do not process the record again unnecessarily.
Target records were manually deleted or changed after migration	Preserve the current target state, identify who or what changed it, and prepare an approved recovery plan before further activity.
Success is reported but required records remain unexplained after all checks	Submit a ticket with activity, scope, identifiers, processing evidence, expected result, and privacy-safe source and target examples.

A transformed result is not automatically missing data

A target platform can represent Categories, collections, variants, options, attributes, Customer Groups, statuses, identifiers, or content structures differently. Accept the difference only when the required business meaning and approved pass condition remain intact.

Verify the correction

Repeat the affected checks against the same evidence set:

Verification area	Pass condition
Record presence	Every required sampled record can be found by a stable identifier or approved fallback identifier.
Compared scope	Source and target counts use the same data type, status, date, site, language, and filter scope.
Processing result	Relevant Failed or Skipped results are resolved or documented as accepted limitations.
Relationships	Required parent-child, Product-Category, Customer-Order, Order-line, Review-Product, and other supported relationships are intact.
Field destination	Required values appear in the approved standard or custom target field.
Operational meaning	Mapped status, group, location, taxonomy, and historical meaning meet the acceptance criteria.
Target visibility	Required records are available in the approved admin, storefront, site, language, or channel context.
Side effects	The correction did not create duplicate records, remove protected target data, or change unaffected scope.

Escalate when the cause cannot be corrected safely

Use Tickets when:

• a supported selected record shows Success but cannot be found in the intended target after identifier and visibility checks;
• repeated Failed or Skipped results remain after the confirmed cause is corrected;
• the target representation does not preserve a required business relationship or accepted meaning;
• the correction requires internal processing, platform-specific analysis, or Custom Service;
• another migration activity could remove, replace, or duplicate protected target records;
• the issue affects launch readiness and no safe target-side correction is available.

Include the service, migration path, activity date, affected data type, source and target identifiers, relevant configuration, Success/Failed/Skipped evidence, expected result, actual result, and minimal privacy-safe screenshots or files. Never include passwords, full secret keys, payment-card data, or an unnecessary customer export.

Prevent the same issue

• define the source-data window and acceptance scope before migration;
• compare source and target using the same statuses, sites, languages, dates, and filters;
• identify representative records and stable identifiers for every selected data type;
• keep required dependencies selected unless reliable target matching is confirmed;
• test filters, field and database mappings, transformations, and Customization with normal and edge-case records;
• verify source exports before upload;
• record approved target-model differences before sign-off;
• restrict manual target changes while validation is in progress.

Next step

After the correction, repeat the applicable validation page for the affected data type:

• Validate Products and Categories
• Validate Customers and Orders
• Validate Content, URLs, and Redirects

When the same source record appears more than once in the target, continue with Duplicate Data before making cleanup changes.