How to Plan Customer Account Migration Without Breaking Passwords, Pricing or Order History
A platform migration can be technically successful while customers still experience it as a failure. Their password stops working, their trade pricing disappears, previous orders are missing, or the account is duplicated under a slightly different email address.
That is why customer account migration ecommerce projects need to be planned as more than a database export. The account is simultaneously an identity record, a commercial relationship and a history of previous transactions. Each part needs a clear migration rule, owner and test.
This guide explains how UK ecommerce project leads can plan an ecommerce customer data migration without creating avoidable login, pricing or customer-service problems.
Why customer account migration is more than moving email addresses
A customer account usually connects several types of information:
- Login identity and authentication details
- Name, email, telephone and contact preferences
- Saved addresses and delivery locations
- Customer group, trade tier or negotiated pricing
- Credit, payment or ordering permissions where relevant
- Previous orders, invoices, returns and refunds
- Marketing consent and source information
These records may not share the same identifier across the old and new platforms. One system may use an internal customer ID, another may use an email address, and an ERP may use an account code. If the migration relies on email alone, duplicate or incorrectly matched accounts are likely.
Start by treating each account as a set of related records that need to remain connected after cutover.
Define the source of truth for each account field
Do not choose one source of truth for the entire customer record unless one system genuinely owns every field. In many ecommerce environments, ownership is split.
For example:
- The ecommerce platform may own login status and saved addresses.
- The CRM may own contact details and sales ownership.
- The ERP may own trade account codes, payment terms and customer pricing.
- The order system may own historical order and fulfilment status.
Create a field-level ownership matrix before mapping data. Include the source field, destination field, transformation rule, whether it can be updated automatically and who approves exceptions.
This prevents a common account migration replatforming mistake: importing a technically complete record that contains commercially incorrect information.
Plan password migration without exposing credentials
Passwords require particular care. Passwords should not be exported as readable text, copied into spreadsheets or sent to developers in an unprotected file. A migration should work with securely stored password hashes or use a controlled account-recovery route.
Check whether password hashes are compatible
The old and new platforms may use different password-hashing algorithms, parameters or storage formats. If the new platform can securely verify the old hash format, customers may be able to continue using their existing passwords after migration. That behaviour must be verified in a controlled environment rather than assumed.
Check:
- Which hashing method the old platform uses
- Whether the new platform can validate that format
- Whether hashes can be rehashed securely after a successful login
- Whether password reset and account activation links work on the new domain
- Whether failed login attempts are handled consistently during cutover
VERIFY the current password-handling behaviour of both platforms and the approved security process before implementation. Do not weaken password protection simply to make migration easier.
Use a controlled reset route when hashes cannot move
If password formats are incompatible, explain the change clearly and provide a secure password reset or activation journey. Do not ask customers to email passwords or reuse an insecure temporary password.
Test the complete route: migrated account, reset request, email delivery, reset token, new password creation, login and access to account data. A reset link that works technically but sends customers to the old platform is still a migration defect.
Match accounts using more than one field
Account matching is one of the most important parts of ecommerce customer data migration. Email is useful, but it is not always a reliable unique key. Customers may have changed email addresses, shared an account, used different addresses or appear more than once in the old database.
Use a matching hierarchy such as:
- Trusted customer or ERP account ID
- Verified platform-specific external reference
- Normalised email address, where uniqueness is confirmed
- Combination of name, postcode, company and account reference
- Manual review for uncertain matches
Give each proposed match a confidence level. High-confidence records may be migrated automatically. Possible duplicates should enter a review queue rather than being merged silently.
Keep the original customer ID as a legacy reference where possible. It can help customer service trace old orders, investigate disputes and reconcile records after launch.
Protect customer-specific pricing and permissions
A migrated customer who can log in but sees the wrong price is not fully migrated. This is particularly important for B2B stores, trade portals and businesses with account-specific terms.
For each customer or account group, define:
- Parent account and branch relationship
- Customer tier or price list
- Contract or negotiated pricing reference
- Permitted products or categories
- Delivery locations
- Payment terms or credit restrictions
- User roles and ordering permissions
Test pricing at every visible stage: category page, product page, basket, quote or approval route, and order record. A cached guest price or default trade tier can create a serious commercial mismatch.
HOFK's guide to checking customer-specific price cache drift provides related testing principles for login-based pricing before go-live.
Design a customer order history migration that customers can trust
Order history is often treated as an archive, but customers use it for practical reasons. They may need to reorder products, download invoices, check delivery details, raise a return or confirm what they bought previously.
Decide what should migrate:
- All historical orders or only orders within a defined period
- Orders linked to active customer accounts
- Order lines, variants, prices and quantities
- Payment, dispatch, cancellation and refund status
- Invoices, credit notes and downloadable documents
- Links from historic products to current catalogue records
Do not recreate history as if old orders were new orders. Preserve their original dates, references, totals and status. Where a product has been discontinued, retain the historical line while showing that it is no longer available to reorder.
For large or complex datasets, consider whether some historic records should remain available through a read-only archive rather than being forced into the new transactional model.
Build a migration test matrix around real customer journeys
A successful import count does not prove that customer accounts work. Test journeys by customer type and risk.
Include at least:
- New customer with no previous order history
- Returning customer with a compatible password hash
- Customer requiring a password reset
- Trade customer with account-specific pricing
- Parent account with branch users
- Customer with multiple addresses
- Customer with cancelled, refunded or returned orders
- Duplicate or uncertain account match
- Customer with a discontinued historic product
For each case, compare the old record, migrated record, visible account area and downstream systems. Record expected result, actual result, evidence, owner and decision.
Run reconciliation before and after cutover
Reconciliation should compare more than the number of imported accounts. Use samples and aggregate checks together.
Useful checks include:
- Source account count versus migrated account count
- Matched, unmatched and duplicate records
- Accounts with pricing or permission exceptions
- Orders linked to the correct customer ID
- Totals and order counts by customer group
- Password reset requests and activation outcomes
- Customer-service cases raised after launch
Classify differences as expected, blocking, accepted with monitoring or requiring follow-up. A small number of documented exceptions is easier to manage than a large number of unexplained mismatches.
Plan cutover and customer communication together
Customers should know what to expect if their login process changes. Communication does not need to reveal technical detail. It should explain the action required and where to get help.
Prepare messages for:
- Customers whose existing passwords will continue to work
- Customers who need to activate or reset their account
- Trade customers whose pricing or ordering access has changed
- Customers asking about missing order history
Keep the old account route available in a controlled, read-only or support-led way where practical. Define who can investigate a missing account, incorrect price or order-history query after launch.
Customer account migration ecommerce checklist
- Field-level sources of truth are documented.
- Passwords are handled through secure hashes or a controlled reset route.
- Account matching uses trusted identifiers and confidence levels.
- Legacy customer IDs are retained where useful.
- Pricing, credit, branch and ordering permissions are mapped.
- Customer order history migration rules are documented.
- Representative customer journeys have passed testing.
- Old and new account records have been reconciled.
- Customer communications and support ownership are ready.
- Rollback, pause and post-launch monitoring responsibilities are agreed.
Where HOFK can help
Customer account migration can cross ecommerce platforms, ERP or CRM data, pricing services, authentication, order history, customer service and fulfilment workflows. HOFK can help map those dependencies, improve the migration logic or support the full stack implementation behind a more controlled replatform.
Relevant support may include ecommerce development, full stack development, monitoring and practical automation. The objective is not to migrate every record without question. It is to preserve the identity, commercial context and history that customers and internal teams rely on.
Conclusion
Customer account migration ecommerce projects succeed when they protect more than login access. Plan passwords securely, match accounts using reliable evidence, preserve customer-specific pricing and make customer order history migration traceable.
Test the complete journey for guest, consumer, trade and exception cases. Reconcile records before and after cutover, communicate clearly and give support teams a practical route for resolving mismatches. That turns account migration replatforming from a risky data transfer into a controlled customer and operational transition.
Frequently asked questions
What is customer account migration in ecommerce?
It is the process of moving customer identities, login access, addresses, pricing permissions, order history and related account data from one ecommerce platform to another.
Can existing customer passwords be migrated?
Sometimes, if the old password hashes are securely compatible with the new platform. If not, use a controlled password reset or account activation route. Never migrate readable passwords.
How should ecommerce customer data migration match accounts?
Use trusted customer or ERP identifiers first, then verified email and other supporting fields. Uncertain matches should be reviewed rather than merged automatically.
How do I protect customer-specific pricing during account migration?
Map customer groups, price lists, contracts, branches and permissions separately, then test prices on product pages, baskets, quotes and final order records.
Should all historical orders be migrated?
Not necessarily. Decide whether all orders, active-account history or a defined period should move into the new platform. Older records may be retained in a read-only archive if that is more reliable.