Customer and order data is the part of a Magento 1 to Magento 2 migration that has the lowest tolerance for failure. A theme can ship with rough edges and be polished post-launch. A custom module can launch with deferred features and be completed in subsequent sprints. Customer records and order history have to be right at cutover, because they touch the relationship the retailer has with every existing customer and they affect operations downstream of the storefront: customer service, accounting, fulfillment, marketing.
This article describes how customer and order data migration actually works on serious Magento 1 to Magento 2 migrations: which patterns produce clean migrations, where the failure modes hide, how password rehashing has to be handled, what the trial-run cadence should look like, and which decisions belong in the audit phase versus the cutover phase. The framing here reflects how Bemeir’s M1-to-M2 migration practice executes these migrations for mid-market and enterprise retailers.
What “customer and order data” actually includes
The data scope is broader than it sounds. A complete customer and order migration on a mid-market Adobe Commerce site includes:
- Customer accounts (email, name, password hash, customer group, custom attributes, registration date)
- Customer addresses (billing and shipping, including default flags)
- Customer wishlists and saved cart contents
- Customer-specific pricing tiers (for B2B)
- Order history (orders, invoices, shipments, credit memos, with line item detail)
- Order custom attributes (loyalty points, custom fields, source tracking)
- Customer reviews and ratings
- Customer communication preferences and subscription state
- Loyalty and referral program data (when stored in Magento)
- Customer-specific catalog permissions (for B2B with restricted catalogs)
Each category has its own migration pattern, its own validation criteria, and its own potential failure modes. The audit phase’s job is to catalog which of these categories exist on the source M1 site, in what volumes, with what custom attributes, and map them to the target Magento 2 schema.
The Data Migration Tool foundation
Adobe Commerce provides the Data Migration Tool, an officially supported open-source utility that handles a substantial portion of the standard M1-to-M2 data migration. The tool reads from the M1 database, applies configured mappings, and writes to the M2 database. It handles the standard customer, address, and order schema mappings well, and it provides a framework for layering custom mapping configurations on top of the defaults.
The tool’s primary value is the framework, not the out-of-the-box mappings. Most mid-market M1 sites have accumulated enough custom attributes, custom EAV entities, and non-standard data structures that the default mappings cover roughly 60-75% of the actual data scope. The remaining 25-40% requires custom mapping work, module mapping files, attribute mapping files, and sometimes custom PHP adapters for genuinely non-standard structures.
Retailers who try to migrate data without the tool, by writing one-off scripts, almost always end up with a more brittle migration. The tool’s framework includes validation passes, incremental migration support (which is essential for cutover orchestration), and a known-good pattern for handling the trickier migration categories. Working with the tool, rather than around it, is the higher-leverage path.
Password rehashing, the silent failure mode
The single most overlooked technical detail in M1-to-M2 customer migrations is password handling. Magento 1 and Magento 2 use different password hashing algorithms and different salt formats. The customer record in M2 must store the hash in a format that the M2 authentication system can validate, but the M2 authentication system cannot validate an M1-format hash directly.
The standard pattern is to migrate the M1 password hashes verbatim into M2 customer records, with a flag indicating “M1-format hash.” On the customer’s first login post-migration, the M2 authentication system detects the M1-format hash, validates the password against the M1 algorithm, and if the password is correct, immediately rehashes it in M2 format and updates the customer record. The customer’s experience is identical to a normal login; the rehashing is transparent.
This pattern requires custom code on the M2 side, the Data Migration Tool does not handle it natively. Migrations that skip this pattern force every existing customer to reset their password on first login, which produces measurable customer-experience damage and an avoidable surge in customer service tickets in the first weeks after launch.
| Migration aspect | Standard pattern | Common mistake |
|---|---|---|
| Password hashes | Migrate M1 format, rehash on first login | Force password reset for all customers |
| Customer attributes | Map every custom attribute explicitly | Drop attributes the tool doesn’t recognize |
| Address normalization | Validate and standardize during migration | Migrate raw, deal with cleanup later |
| Order line items | Migrate full line-item detail with pricing | Migrate order header only |
| Customer-specific pricing | Recreate tier pricing rules explicitly | Lose B2B pricing tiers |
| Wishlist and saved carts | Migrate to corresponding M2 entities | Drop, with notification to customer |
| Custom EAV entities | Custom mapping per entity type | Drop or ignore |
| Order custom attributes | Map to M2 custom attributes explicitly | Lost in migration |
Order history retention decisions
A frequent question in M1-to-M2 migration scoping is how far back to migrate order history. Options range from “everything” to “last 24 months” to “last 12 months.” The decision has cost implications (older orders are messier and require more cleanup work), legal implications (some retailers have regulatory retention requirements), and customer experience implications (B2B customers expect to see their full order history regardless of how old).
The right answer depends on the retailer’s business model. For consumer DTC retailers with mostly transactional relationships, migrating the last 12-24 months of order history is usually sufficient, with the older history archived to a separate system for occasional reference. For B2B retailers, especially distributors with long sales cycles and replenishment patterns, full order history migration is usually necessary because the order history is operationally relevant to current selling.
The cost difference can be meaningful. A full historical migration on a mid-market retailer with 8-10 years of M1 data can add $15K-$40K to the migration scope versus a 24-month migration. The business case has to support it. According to the Adobe Commerce documentation on Data Migration Tool order migration, the migration approach should be decided in the audit phase and committed before development begins, because the testing scope and the cutover sequence both depend on it.
The trial-run cadence
The discipline that separates successful customer and order data migrations from failed ones is the trial-run cadence. A serious migration runs three to five complete data migration trials against representative M1 production snapshots before the actual cutover. Each trial produces a delta report: which records migrated cleanly, which produced warnings, which produced errors. The remediation between trials closes the error rate progressively until the final pre-cutover trial produces zero errors and a small, expected set of warnings.
The cadence typically runs:
- Trial 1 (8-12 weeks before cutover). Initial full migration against the most recent production snapshot. Expect 5-15% of records to produce warnings or errors. This trial’s primary purpose is to surface the categories of issues.
- Trial 2 (6-8 weeks before cutover). Second migration with mapping corrections from Trial 1. Error rate should drop to 1-3%.
- Trial 3 (3-4 weeks before cutover). Third migration with refined mappings and the operational handoff plan exercised. Error rate should drop to under 1%.
- Final dry run (3-7 days before cutover). Full migration plus full operational verification: customer login tests, order lookup tests, B2B pricing tests, customer service workflow tests. The retailer’s operations team participates.
- Cutover migration. The actual migration during the cutover window, with incremental mode enabled to capture any orders or customer updates that occurred since the last full snapshot.
This cadence is non-negotiable for any non-trivial M1-to-M2 migration. Compressing the cadence, running only one or two trials, is the single most reliable way to produce a launch-day data crisis. Bemeir’s Adobe Commerce migration team treats the trial-run cadence as part of the engagement scope, not as a flexible variable.
Validation criteria
Each trial run produces validation reports against a defined set of criteria. The validation is statistical for high-volume entities (customer accounts, order records) and per-record for low-volume entities (B2B customer groups, custom pricing tiers).
For customer accounts, the validation includes: total count match, email uniqueness preserved, customer group assignment correct, address count match per customer, default address flags preserved, custom attribute population complete, password hash format flag set correctly.
For orders, the validation includes: total count match, total revenue match (a key reconciliation check), order status mapping correct, line item count match per order, line item pricing reconciliation, invoice and shipment relationships preserved, credit memo relationships preserved.
For B2B-specific data, validation includes: customer group hierarchy correct, customer-specific catalog permissions preserved, customer-specific pricing tier rules functioning, customer-specific shipping rules preserved.
The validation reports are reviewed at trial-run review meetings with the retailer’s operations team. The team that owns the customer relationship and the order operations has to sign off on the validation results before the cutover trial is approved. This sign-off discipline is part of what makes the migration land cleanly on launch day.
What good looks like at cutover
The signal that a customer and order data migration has gone well is operational: customer service tickets in the first week after launch are at or below the previous baseline, B2B customers can place orders without intervention, customer logins succeed at the expected rate, and the finance team’s order reconciliation shows the expected revenue match against the M1 source.
Reaching this state is methodical, not magical. The audit work catalogs the scope. The Data Migration Tool framework handles the standard mappings. Custom mapping work handles the non-standard data. The trial-run cadence surfaces and remediates issues. The validation discipline confirms readiness. The cutover migration runs the same way the trials ran, with confidence built from repetition.
The retailers who underestimate this work tend to learn the hard way. The retailers who treat customer and order data as the highest-priority migration workstream, scoped seriously and executed methodically, land their migrations cleanly. The discipline pays for itself in customer-service tickets that never get filed and in customer relationships that never get damaged in the migration window.
