The catalog migration is the part everyone plans for. The customer data migration is the part that quietly breaks things in production months after launch. Login failures because the password hash format does not match. Compliance violations because consent records did not carry over. GDPR data subject requests that cannot be served because the address book schema changed. These are the issues that show up in the support queue, not in the migration test plan, and the root cause is almost always shortcuts taken on the customer data side of the cutover.
This piece is the checklist Bemeir uses to make sure the customer side of a Magento 1 to Adobe Commerce migration is as buttoned up as the catalog side. The work is largely invisible if done right and very visible if done wrong, which is the worst kind of operational work.
What “customer data” actually includes
Customer data on a Magento 1 storefront is broader than the customer_entity table. It includes the customer record itself, every address in the address book, every order, every wishlist, every newsletter subscription, every loyalty point balance, every B2B company association, every consent record for marketing communications, every password hash, every saved payment token reference, and every customer attribute that has been added over the years.
Most migration projects scope only the obvious bits. The address book and order history get migrated. The newsletter subscriptions and consent records get forgotten. The loyalty balances either get migrated wrong or get manually reconciled in a slow and error-prone process. The wishlist becomes a quiet point of customer complaints because everyone is surprised when their saved items disappear after the cutover.
Build the full inventory before you build the migration plan. The list is usually 20 to 30 entities across the schema. The Adobe Commerce data model documentation is the reference for what the target schema looks like. The mapping from Magento 1 schemas to Adobe Commerce schemas is the work.
The password problem
The single most operationally painful issue in customer data migration is password hash compatibility. Magento 1 stored passwords in formats that have evolved over the platform’s life. The earliest version was md5 with a salt. Later versions used sha256 with a longer salt. Adobe Commerce uses Argon2id by default in current versions, with sha256 as a legacy fallback for migrated accounts.
The right approach is to migrate the existing hashes intact and let Adobe Commerce rehash on first login. The customer’s plaintext password is not stored anywhere, so there is no way to convert hash formats without the customer logging in. The migration script needs to preserve the original hash format, including the salt and the version flag, and the Adobe Commerce side needs to be configured to validate against the legacy format and rehash to Argon2id on successful login.
Implementing this requires three changes on the Adobe Commerce side. First, the encryption module needs to recognize the legacy hash format. Second, the customer authentication flow needs to detect a successful legacy login and trigger a rehash. Third, the password reset flow needs to handle the case where a customer has not logged in since the migration and asks for a password reset. The reset flow should work normally because it does not require the old hash.
The OWASP Password Storage Cheat Sheet is the reference point for what good looks like. The Magento-specific implementation lives in the encryption module, and the test plan must cover every legacy hash format the original store accumulated.
Consent records and marketing compliance
Marketing consent is the most legally consequential surface and the most commonly forgotten. Magento 1 stored newsletter subscription state in the newsletter_subscriber table. It may have stored GDPR-specific consent in custom attributes or in third-party modules. CCPA opt-out preferences may have been stored separately.
The migration must preserve all of these intact. Specifically:
The newsletter subscription state, including the subscription date, the status, the unsubscribe history if available, and any double-opt-in confirmation timestamps. The GDPR consent records, including what consent was granted, when, and for what purpose. The CCPA opt-out preferences for California residents. The SMS marketing consent if the store does SMS campaigns. Any other regulatory consent records the business has been keeping.
If any of these is lost in migration, the business is exposed to a regulatory issue the next time it sends a marketing communication. The GDPR Article 7 requirements on consent are explicit about the need to demonstrate when and how consent was obtained. A consent record without a timestamp is not a consent record under GDPR. The same applies under CCPA and increasingly under state-level US privacy laws.
Bemeir’s Adobe Commerce migration practice treats consent record preservation as a launch-blocking issue. The cost of doing this work properly is small. The cost of not doing it properly is potentially much larger.
PII handling during the migration window
The migration window itself is a PII handling exercise. Customer data is in motion. Database dumps are being moved between environments. Test environments are being populated with real or scrubbed customer data. Engineers are accessing customer records to validate the migration.
The discipline here is to treat the migration as a regulated event. Three controls.
First, every environment that receives a copy of customer data must have access controls equivalent to production. No customer data on developer laptops. No customer data in unencrypted backups. No customer data in shared cloud storage that the broader team can access. The NIST guide to protecting PII covers what reasonable controls look like.
Second, test environments should use scrubbed customer data wherever possible. A scrubbed dataset preserves the shape and volume of the real data but replaces the actual values with synthetic equivalents. Names, emails, phone numbers, and addresses get randomized while preserving the relationships between records. This is the standard for any non-production environment where the full team has access.
Third, the migration window itself should have logged, audited access. Who pulled the production export, when, where it landed, and when it was deleted from the intermediate location. This is the kind of audit trail that holds up to a privacy investigation, and it is straightforward to produce if planned for.
Saved payment tokens
Saved payment tokens are the third operationally painful issue. The token is technically owned by the payment processor, not by Magento, but the storefront stores a reference that maps customer accounts to tokens at the processor.
The migration needs to preserve those references intact. Each payment service provider has its own data model for tokens. Stripe, Braintree, Adyen, and Authorize.net all expose customer-vault APIs that let the storefront associate a customer ID with a stored payment method. The migration script must read the existing references from Magento 1 and write equivalents into Adobe Commerce, preserving the customer-to-token mapping.
If this is done wrong, the consequence is that customers who try to check out with their saved card see a missing-payment-method error. The cart will not complete. The customer either calls support or abandons. Either way is a measurable revenue hit during the period when the customer base is already disoriented by the migration.
The Stripe Customer migration guide and equivalent guides from the other major processors document the exact steps. The migration script needs to handle whichever processor the store uses, and the test plan must include a checkout completion test using a saved card.
Data subject rights after migration
GDPR and an increasing number of US state laws require the business to respond to data subject access requests, data subject deletion requests, and data portability requests within fixed timelines. The migration must preserve the ability to respond to these requests for customers who existed before the migration.
The practical requirement is that the customer’s full data footprint is reachable from the customer record in Adobe Commerce. If the migration left order history attached to a customer ID that does not match the new customer record, the data is technically retained but operationally unreachable. The next deletion request that touches this customer becomes a multi-hour engineering exercise instead of a routine support task.
Build the test for data subject rights into the migration acceptance criteria. Pick five representative customers from the Magento 1 production data, run a simulated data subject access request against the Adobe Commerce post-migration data, and verify that all the records are present and properly associated. If the simulated request takes more than 15 minutes to fulfill, the data model has a problem that will hurt the business later.
The checklist
A clean Magento 1 to Adobe Commerce customer data migration covers the following categories before launch. Use this list as the explicit acceptance criteria for the migration phase.
| Category | Acceptance criterion |
|---|---|
| Customer accounts | All accounts migrated with original email and customer group preserved |
| Address book | All addresses migrated, default shipping and billing flags preserved |
| Order history | All orders associated with the correct customer record, status preserved |
| Password hashes | Legacy hashes preserved, rehash-on-login wired up, password reset works |
| Consent records | Newsletter, GDPR, CCPA, and SMS consents migrated with timestamps |
| Saved payment tokens | Customer-to-token mapping preserved for each PSP in use |
| Wishlist | All wishlists migrated and accessible to the customer |
| Loyalty points | Balances migrated, transaction history migrated where the loyalty extension supports it |
| B2B company associations | Company hierarchy preserved, role assignments preserved |
| Custom attributes | Every custom attribute on customer_entity mapped to the new schema |
| Data subject rights | Test request fulfilled in under 15 minutes against migrated data |
The discipline is to treat this list as launch-blocking. Stores that ship the migration before every row in the table passes acceptance routinely deal with the consequences in the support queue for months after launch.
Bemeir’s Adobe Commerce engineering practice runs customer data migration as a named workstream with a dedicated lead, separate from the catalog and storefront workstreams. The discipline is the only thing that prevents the operational tail. If you are also evaluating migrations to Shopify Plus or Shopware, the same checklist translates with minor platform-specific adjustments. The compliance work is fundamentally the same regardless of target. The platform-specific differences are easier to handle once the data model and the consent records are correct.
If you cut a corner on customer data migration, the support team pays for it. If you do the work properly, the migration is invisible to customers, which is exactly what you want.
