Product and order migration receive most of the attention in a Shopify replatforming programme. Customer accounts are often treated as another CSV import. That mistake becomes visible on launch day when loyal customers cannot sign in, password-reset emails fail, historic orders disappear, duplicate profiles fragment loyalty status and customer support cannot explain what changed.
A customer account is not only a row in a database. It is an identity, authentication journey, consent record, address book, order relationship, returns context, loyalty profile and trust contract.
A successful migration must decide which Shopify account model will be used, what identity can legally and technically move, how historic data will be represented and how customers will regain access with minimal friction.
Understand Shopify’s account models first
Shopify supports newer customer accounts that use a one-time verification code sent by email, as well as legacy customer accounts that use email and password. The available capabilities and extension model differ.
The newer model can reduce password-reset friction because customers do not need a stored Shopify password. It also changes the sign-in journey and requires reliable email delivery and customer understanding.
Headless implementations may use the Customer Account API and OAuth-based authentication to create authenticated customer experiences. This adds flexibility but also introduces redirect, token, session and consent responsibilities.
Choose the target account architecture before mapping data. Otherwise, the migration team may optimise password transfer for a destination that does not use passwords.
Why passwords usually cannot be migrated directly
Source platforms normally store one-way password hashes, not recoverable passwords. Even when hashes can be exported, Shopify may not support the source algorithm or allow those hashes to be imported into its authentication system.
Never ask for plaintext passwords or attempt to reverse them. Treat customer credential resets as an identity transition.
If using passwordless customer accounts, communicate that sign-in now uses an emailed code. If using legacy accounts, plan account invitations or password-reset flows. For an external identity provider in a headless architecture, evaluate whether existing credentials can remain with that provider and be federated appropriately.
The business decision is not “Can we copy passwords?” It is “How will every legitimate customer securely regain access with the least confusion?”
Create a customer identity matching strategy
Email is often used as the matching key, but it is not always unique or clean. Customers may have changed addresses, placed guest orders under different emails, shared a household account or used marketplace relay addresses.
Build deterministic matching rules. Normalise case and whitespace, but avoid transformations that could merge distinct addresses. Decide how phone-only customers and records without verified contact details will be treated.
Establish a golden customer ID in a migration mapping table. Preserve the source customer ID as a metafield or external reference where appropriate. This enables reconciliation, support lookup and incremental migration.
Never merge profiles automatically when evidence is ambiguous. Create an exception queue for high-value or complex accounts.
Map more than customer fields
A comprehensive map covers profile fields, addresses, marketing consent, tax status, company association, tags, loyalty identifiers, store credit references, order relationships, returns and customer-service notes.
Classify each field:
- Native Shopify field
- Metafield
- Data retained in an external system
- Historical archive only
- Prohibited or unnecessary data
- Requires transformation or customer confirmation
Do not use free-form tags as a substitute for every data model. Tags are useful for operational segmentation but become fragile when they encode balances, legal consent or structured relationships.
Apply data minimisation. Migration is an opportunity to stop carrying obsolete, unverified or unjustified personal information.
Preserve order history as a customer experience
Customers expect to see past purchases, track open orders, start returns and retrieve invoices. Operational teams need history for service, fraud review and loyalty decisions.
Determine which orders can be imported natively, which require a migration application or API, and which will remain in a read-only legacy archive. Validate financial totals, currency, taxes, discounts, fulfilment, refunds and customer associations.
If complete native history is impractical, provide a coherent experience. A customer portal can display legacy orders through an integration, or support agents can access an archive. Explain the boundary clearly.
Do not silently show only post-launch orders; customers may interpret missing history as loss or account compromise.
Handle guest checkout and account claiming
Many source orders may not belong to an authenticated account. Decide how Shopify will associate guest orders with customers and whether customers can claim history after authentication.
Avoid exposing an order merely because someone knows an email address. Account-claiming flows should verify control of the address and apply fraud controls for high-risk information.
Test customers who purchased as guests, later created an account, used multiple addresses or checked out through accelerated payment methods.
Protect consent and communication preferences
Marketing consent is regulated data, not a convenience field. Preserve the status, timestamp, source and method when available. Do not convert unknown or implied consent into subscribed.
Separate transactional account-activation or migration communication from marketing. Review local requirements and the organisation’s privacy policy.
When introducing passwordless sign-in or a new identity provider, update customer-facing privacy and authentication notices where necessary. Coordinate email deliverability because launch communication and verification codes may create a sudden sending spike.
Design the activation journey
The activation journey should explain what changed, why the message is legitimate and exactly what the customer needs to do.
Segment customers rather than sending one universal message. Active customers with open orders may need early notice. Dormant accounts may not need immediate activation. VIP, subscription and B2B customers may require assisted migration.
Use branded sending domains, consistent links and clear security language. Avoid urgency that resembles phishing. Provide a support route that does not require the customer to sign in.
Measure delivery, code or invitation completion, failed sign-ins, support contacts and checkout conversion by cohort.
Plan for duplicate profiles
Duplicates can be created when a migrated customer checks out before activation, uses a different email or authenticates through another channel. Define how profiles will be detected and merged without losing orders, consent or loyalty value.
Maintain source-to-target identifiers and event timestamps. Avoid destructive automated merges during the launch window unless the rules are proven.
Give support agents a documented process and sufficient context. Customers should not be asked to repeat identity verification across multiple teams.
Integrate loyalty, subscriptions and store credit carefully
These systems often maintain balances and contractual state outside the commerce platform. Inventory the system of record for points, tiers, referrals, subscription contracts, gift cards and store credit.
Do not treat a loyalty balance like a tag or a subscription like an historic order. Migration may require vendor-specific import, customer re-authorisation, payment-token handling and reconciliation.
Run balance comparisons before and after cutover. Create approval rules for manual adjustments and retain an audit trail.
B2B customer-account considerations
Shopify B2B introduces companies, locations, roles, purchasing permissions, price lists and payment terms. Mapping individual consumers into a B2B structure requires more than importing contacts.
Define company administrators, buyers, approvers and location access. Validate tax identifiers, credit terms and catalogues. Test what happens when the same person buys personally and for a company.
Communicate with business customers before changing login or approval workflows. A small identity error can block an entire account from ordering.
Use staged migration and delta synchronisation
Run discovery and trial imports with representative data. Validate field transformation, account association, order history and consent.
Perform a bulk migration before launch, followed by delta synchronisation for customers and orders changed during the transition. Freeze only the minimum necessary functions and define which platform owns new registrations during each stage.
Every migration run should be idempotent. Replaying a batch must not create duplicate customers or orders. Keep a reconciliation table with source ID, target ID, status, timestamp and error.
Test real customer journeys
Technical row counts are necessary but insufficient. Test:
- Existing customer receives and completes the new sign-in flow.
- Verification or reset email arrives promptly.
- Customer with multiple addresses checks out correctly.
- Historic, open and refunded orders display as intended.
- Guest customer can safely associate eligible history.
- Loyalty and subscription state remains accurate.
- B2B user sees only permitted company locations.
- Customer changes email after migration.
- Duplicate-account handling preserves consent and orders.
- Support agent can locate a customer using the old identifier.
- Revoked or deleted accounts remain unavailable.
Include mobile devices, email clients and accessibility. Authentication friction is a conversion problem as well as a technical one.
Monitor conversion and support after launch
Create a migration command centre with engineering, ecommerce operations, customer support, CRM and security representation.
Watch sign-in success, verification-email delivery, checkout conversion for returning customers, duplicate creation, account-related search terms, support volume and order-history complaints.
Define thresholds for rollback or intervention. Authentication changes may not require a full storefront rollback, but teams need the ability to pause communication, repair identity mappings or switch a login route.
Security controls
Protect migration exports with encryption, access limits and deletion schedules. Never place customer data in unmanaged spreadsheets or developer laptops.
Use least-privileged API credentials, audit access and rotate secrets after the migration. Validate redirects and domains to prevent phishing. Rate-limit account recovery and monitor unusual verification activity.
Ensure logs do not contain passwords, tokens, verification codes or unnecessary personal data.
Migration timeline
Begin with identity and data discovery, account-model selection and field mapping. Then build migration tooling, target integrations and customer communications.
Run multiple rehearsals, including a full-volume performance test and reconciliation. Complete deliverability preparation before sending activation messages.
During cutover, execute the final delta, validate critical cohorts and release communication gradually. Continue hypercare until sign-in, conversion and support measures stabilise.
Final recommendation
Treat customer accounts as an identity migration, not a data import. Select the target authentication model first, preserve a stable customer mapping, handle password transition honestly and design order history, consent and support as parts of one journey.
The technical objective is correct records. The commercial objective is that returning customers recognise the experience, regain access safely and continue purchasing without questioning whether the brand has lost their history or trust.
Sources and further reading
Shopify customer accounts guidance
Shopify Customer Account API
Shopify migration guidance
Cutover runbook
The cutover plan should list every migration batch, owner, expected count, validation query and rollback condition. Run the final delta only after confirming source and target clocks, API capacity and write ownership.
Sequence customer import, order import, loyalty reconciliation and communication deliberately. If activation messages are sent before historic orders are visible, customers may conclude the account is incomplete. If orders arrive before identity matching stabilises, duplicates may increase.
Customer-support readiness
Provide support with source and Shopify identifiers, migration status, last attempted activation and safe remediation actions. Create scripts for passwordless sign-in, missing history, changed email, duplicates and B2B access.
Limit what support agents can see and change. High-risk merges or email changes should require identity verification and an auditable approval path. Feed support reasons into the command-centre dashboard so systemic issues are detected quickly.
Reconciliation controls
Reconcile counts and financial totals by cohort, not only in aggregate. Compare active customers, subscribed customers, addresses, orders by status, refunds, loyalty balances and company relationships.
Sample high-value and unusual records manually. Store machine-readable error codes and retry only failures that are safe to replay. Sign off each reconciliation domain with a named business owner.
Conversion-protection experiment
Release the new sign-in experience to employees and a small customer cohort first. Measure email delivery, time to authenticate, abandonment and checkout completion. Compare mobile and desktop behaviour.
Use progressive communication and monitor returning-customer conversion against a baseline. If sign-in friction rises, adjust copy, deliverability or routing before expanding. Account migration success is proven in customer behaviour, not only database parity.
