The Magento 1 to Adobe Commerce data migration looks straightforward at a presentation level: same database structure family, same EAV pattern, same module organization. The surface similarity is misleading. The actual schema differences are extensive enough that Adobe ships an entire Data Migration Tool to handle them, and even with the tool, several categories of difference reliably surprise migration teams who have not planned for them. The surprises do not break the migration; they extend it.
This piece walks through the schema differences that consistently catch merchants and agencies during Magento 1 to Adobe Commerce migrations. Bemeir’s Magento team has run enough of these migrations to recognize where the surprise costs live; the patterns below are the ones worth budgeting for in advance.
Why the schemas diverged
Adobe Commerce was a major architectural reset over Magento 1, not an incremental release. The framework changes (dependency injection, modular composer-based loading, the Service Contracts pattern) drove corresponding database changes. The catalog model, order model, and EAV implementation all carry forward conceptually but with different table structures, different relationships, and different supporting tables.
The Data Migration Tool handles most of the mechanical translation. The places it does not handle, or handles in ways that surprise teams, are the ones below.
Surprise 1: Catalog attribute transformation
Magento 1 stored some catalog attributes in ways that Adobe Commerce treats differently. Specifically:
Attribute scope. M1 supported attribute scope at the website/store/store-view level with specific semantics. Adobe Commerce supports the same scopes but the migration tool sometimes promotes M1 store-view values to store-level values, which can confuse merchants who expected per-store-view overrides to be preserved as such.
Custom attribute types. Some M1 custom attribute types (particularly text editors, complex multi-select configurations, and vendor-specific types) do not have direct Adobe Commerce equivalents. The Data Migration Tool either drops these or migrates them as plain text, losing the rich behavior.
Product type variations. Adobe Commerce’s product types (simple, configurable, bundle, grouped, virtual, downloadable, gift card) match M1 conceptually but with stricter validation. M1 stores that had loosely-configured products often fail validation during migration and need cleanup.
Stock and inventory model. Adobe Commerce introduces the Multi-Source Inventory (MSI) module which represents stock differently from M1’s per-website stock model. The migration tool’s default behavior creates a single source and a single stock; merchants who want multi-warehouse inventory need to set up MSI properly and migrate stock data with awareness of the new model.
Surprise 2: Customer data complexities
Customer migration is largely clean, but four categories surprise:
Password rehashing. Adobe Commerce uses a different password hashing scheme. The Data Migration Tool preserves the hashes in a way that allows existing customers to log in once and re-hash transparently. The catch: any customer who does not log in within the first months may need a password reset later, and stores migrating older inactive customers should plan a re-engagement email campaign.
Customer attribute scope. Like catalog attributes, customer attribute scope can shift during migration. The default Data Migration Tool behavior may convert per-website customer attribute values to global values.
Address validation differences. Adobe Commerce has stricter validation on phone, postal code, and country combinations than M1 in some configurations. Customer records that were valid on M1 sometimes fail validation on Adobe Commerce and need cleanup or import-time tolerance.
Customer group references. Customer group IDs are renumbered in some migration paths. If your custom modules reference customer group IDs by hardcoded numbers (which they should not, but they often do), the references break post-migration.
Surprise 3: Order data preservation
Order migration is necessary for compliance and for customer-facing order history, but several patterns cause issues:
Order item references. Order items reference products by SKU and ID. If the catalog migration renumbers product IDs (which it usually does), the order item references need to map to the new IDs. The Data Migration Tool handles this, but the mapping needs to be reviewed for accuracy.
Custom order attributes. Many M1 stores added custom attributes to orders for tracking shipping methods, custom fields, or B2B-specific data. Adobe Commerce supports the same patterns but the attribute definitions need to be migrated as well as the values.
Order status workflows. M1 stores often added custom order statuses and custom status transition logic. Adobe Commerce supports custom statuses but the workflow logic does not migrate automatically; it needs to be reimplemented in the new module structure.
Invoice and shipment records. Linked to orders but stored separately. The migration tool handles these; the merchant should verify the linkage is intact after migration, especially for partial invoices and partial shipments.
Surprise 4: URL rewrites and SEO history
URL preservation is critical for SEO continuity and a frequent source of post-migration trouble:
URL rewrite table. M1’s url_rewrite table maps every URL to the product, category, or CMS entity it represents. Adobe Commerce has the same concept but the table structure differs slightly. Migration moves the records but the merchant should verify that every M1 URL still resolves correctly after migration.
Multiple URL rewrites per entity. M1 sometimes accumulated multiple rewrites per product (from historic SKU changes, category moves, etc.). The Data Migration Tool typically picks one canonical mapping; the others may not be preserved. This is the source of 301-vs-404 regression after migration.
Custom URL schemes. Stores that customized M1’s URL generation (e.g., to remove .html suffixes, to flatten category paths, to add custom prefixes) need to replicate the customization in Adobe Commerce. The customization itself does not migrate.
404 redirect maps. Pre-migration, run a full crawl of the M1 site. Post-migration, verify each URL still resolves correctly. The delta is the redirect map that needs to be configured in Adobe Commerce or at the CDN level.
Surprise 5: Reviews, ratings, and user-generated content
User-generated content is treated as a Category B (extension) issue but the data lives in core tables that need attention:
Review and rating tables. M1’s review tables migrate to Adobe Commerce’s review tables. The schema is similar but the linkage to product IDs needs to be remapped (because product IDs change).
Wishlist data. Customer wishlists migrate but the linkage to products and to customers needs to remap correctly.
Recently-viewed product history. Stored in customer-related tables. May or may not migrate depending on the Data Migration Tool configuration.
Surprise 6: Sales rules and cart price rules
The discount engine surfaces several migration issues:
Rule conditions. M1 sales rules use a serialized conditions structure that Adobe Commerce also uses but with slightly different field names and value types. The Data Migration Tool handles most cases; complex rules with custom conditions sometimes need post-migration review.
Coupon codes. Coupon code data migrates cleanly, but custom coupon types (one-time use codes, customer-specific codes) need verification.
Reward points and customer loyalty. Adobe Commerce reward points functionality differs from M1 reward extensions. If the M1 store used a reward extension, the data migration is custom work; the extension’s data tables need to be mapped to Adobe Commerce equivalents.
The migration checklist for schema fidelity
A practical post-migration validation checklist:
| Check | What to verify | Acceptance criteria |
|---|---|---|
| Product count and SKU integrity | Total product count matches, no duplicate SKUs | 100% match |
| Customer count and login | Customer count matches, sample logins work | 100% match |
| Order count and accessibility | Order count matches, sample orders display correctly | 100% match |
| URL preservation | M1 URLs resolve to correct Adobe Commerce URLs | 95%+ direct match, balance via 301 redirects |
| Category structure | Category tree depth and product-category links | 100% match |
| Attribute fidelity | Custom attributes present with correct values | 100% for in-use attributes |
| Image migration | Product images, category images, CMS images | 100% present, correct paths |
| Sales rules | Active sales rules and coupons work as intended | 100% functional |
| Customer group integrity | Customer group memberships preserved | 100% match |
| Tax rate and zone migration | Tax rules and zones preserved | 100% match |
Pre-migration data hygiene
The migration goes more smoothly when the M1 data is clean going in. Three categories of cleanup that pay off:
Remove products that have not sold in 3+ years. They migrate, they add load to every catalog operation, and they almost never come back to life. Archive them before migration.
Resolve duplicate customer accounts. Email-based duplicates often exist on M1 stores. Resolving them pre-migration is cleaner than resolving them post-migration.
Audit and prune unused attributes. Custom attributes that were created and never used add complexity. The migration is the natural moment to remove them.
Clean up URL rewrite cruft. Multiple rewrites per product, dead rewrites, and orphaned rewrites can be pruned pre-migration to reduce the URL preservation work.
What the tool does and does not handle
Adobe’s Data Migration Tool handles the structured tables that come with core Magento. It handles many third-party extension tables through its extension-specific configuration files. It does not handle custom modules that did not exist when the tool was last updated.
For each custom M1 module with database tables, a decision is needed: does the data come over (and if so, written by what code), or does the data stay on M1 (and if so, archived where)? This decision is part of the extension mapping work, but the database side of it needs explicit handling.
Bemeir’s migration team treats the data layer as a parallel workstream to the application layer, with its own validation checklist and its own sign-off criteria. The migrations that go smoothly are the ones where this discipline is in place from week one. The migrations that go badly are the ones where data fidelity is treated as a downstream consequence of application work, which it never is. The schema differences are real, the surprises are predictable, and the work is well-understood; what remains is the patience to do it carefully.
