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 evidence before changing configuration and diagnose the smallest affected scope before 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 File Upload Source is missing a subset that was never included in the uploaded 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 Data Transformation, Advanced Data Mapping, Advanced Database Mapping, 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.
CSV, XLS, or XML Source shows Product 0/0	Treat this as a template-recognition issue first. Open the exact CSV, XLS, or XML Product template guide and restore the expected filename and structure. Re-upload the file and confirm Source Product records are recognized before investigating Target visibility.
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.
Data Transformation, Advanced Data Mapping, or Advanced Database Mapping used the wrong rule, value, 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 target state before further activity, identify who or what changed it, and prepare an approved recovery plan.
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 Support 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.

Platform-specific diagnostic patterns

The following cases are common examples of data that can look missing even when the underlying cause is a target-model, mapping, or visibility difference. Use them after the general diagnostic sequence above so the investigation stays evidence-based.

Shopify variants or options are missing

First confirm that the parent Product migrated, then compare the source option structure with the variant and option structure represented by the active Shopify path. A missing variant can result from target product-model constraints, a source combination that does not have a compatible target representation, a mapping or transformation decision, or a Product that exists but is not displayed as expected.

Do not diagnose the issue from a fixed historical variant-limit number. Test representative high-variation Products against the Shopify model in use at migration time, compare the expected purchasable combinations with the target combinations, and record any combination that requires a different target representation or Custom scope.

Square Orders are not visible in the dashboard

Confirm the Order exists before classifying it as missing. Search by a stable Order identifier, review the mapped payment and fulfillment meaning, and check whether the active Square view or filters exclude the record. An Order that is present in the target data but absent from one dashboard view is a visibility issue, not automatically a migration failure.

If the Order cannot be found by identifier, return to processing evidence and mapping checks. Do not hard-code a historical rule about one Order status being hidden unless that behavior is verified in the target environment being validated.

Incorrect characters or encoding after migration

When a description, name, address, or other text contains replacement characters, mojibake, missing symbols, or corrupted punctuation, compare the exact source value, the migrated stored value, and the target-rendered value. Determine whether the problem originates in the source encoding, file export, database decoding, transformation, target storage, or storefront rendering.

Test representative ASCII, accented, non-Latin, symbol, and emoji values that matter to the store. Correct the narrowest confirmed layer and then revalidate the same samples before expanding the correction to a larger scope.

Magento Products exist in Admin but are missing from the storefront

If the Products exist in Magento Admin, do not assume the migration failed. Verify the Target Product status, website/store assignment, Category relationship, inventory or saleability state, and any Magento indexing or cache processes required by the Target Store.

A record can exist in the target database or Admin while storefront indexing, visibility, or assignment still prevents it from appearing to customers. Use a representative Product ID or SKU and compare its Admin state with the storefront result before rerunning migration data.

Square catalog items exist but are missing from Square Online

Square catalog presence does not by itself recreate Square Online presentation. Verify that the migrated item exists in the Square catalog, then inspect the Square Online channel/site configuration responsible for publication, navigation, media, and channel visibility.

Do not rerun catalog migration solely because an item is absent from the expected online page. First determine whether the problem is missing catalog data or Target Store channel configuration.

Next Steps

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.