The first surprise on most migrations isn't the data work or the redirect map. It's the conversation about passwords. Customers expect to log in with their existing credentials. They can't, on any platform migration, anywhere. The reason is technical and the resolution is a process. Both deserve more attention than they usually get.
Why passwords don't migrate. Ever.
Passwords aren't stored in plaintext on any responsible platform. They're stored as cryptographic hashes generated by a specific algorithm with specific parameters. When a customer logs in, the platform hashes the input password using the same algorithm and compares it to the stored hash.
Different platforms use different hashing algorithms. Magento uses one set of hash functions. WooCommerce uses PHPass. Salesforce Commerce Cloud uses something else. Shopify uses bcrypt with specific cost parameters. The hashes are not interchangeable.
If you exported the hash from Magento and imported it into Shopify, Shopify couldn't verify a customer's password against it. Even if you tried to re-hash the input password using Magento's algorithm, Shopify's authentication system doesn't know how to do that and shouldn't.
The only way to transfer a working password would be to know the plaintext, which nobody has. Hashes are one-way by design. That's the security property that makes them safe to store.
This is true across every platform pair, every direction. Magento to Shopify, Shopify to Magento, BigCommerce to Salesforce, custom to anything. There is no platform pair where passwords transfer.
What requires re-collection
Three categories of customer data require re-collection or rebuilding.
Passwords. Always. No platform pair is an exception.
Stored payment methods. Saved credit cards are stored as tokens with the payment processor, not the platform. The token is tied to the merchant account on the source platform's gateway. Moving payment processors (common when consolidating to Shopify Payments) means tokens can't be re-vaulted. Customers re-enter card details on next purchase.
If you're staying on the same payment processor (e.g., the source brand was on Stripe, and the new Shopify Plus store will use Stripe via a third-party gateway), token migration is sometimes possible but requires direct work with the processor.
Subscription payment authorisation. For active subscriptions, the customer has authorised recurring billing on the source platform. On the new platform, that authorisation is fresh. Recharge, Skio, and most subscription apps have re-vaulting tooling that handles 80 to 95% of subscriptions automatically. The remainder need a customer-initiated payment update.
The forced password reset
The standard resolution is a forced password reset on first login post-launch. Three implementation patterns exist.
Pattern 1: Pre-launch email campaign. Two to seven days before cutover, customers receive an email explaining the move and asking them to set a new password before launch. Lower friction post-launch but harder to time correctly because you need new-platform infrastructure ready before the cutover.
Pattern 2: At-cutover email. On launch day, customers receive an email with a password reset link. Most common pattern. Works because the new infrastructure is already live and tested.
Pattern 3: First-login prompt. Customers don't receive a proactive email. The first time they try to log in, they're prompted to reset. Lowest engagement work but creates friction at the most important moment (when they're trying to buy).
Most brands use a hybrid: a launch-day announcement email that includes the password reset call-to-action, plus a first-login prompt as a fallback for customers who didn't read the email.
Specific guidance for high-value segments
For three customer segments, the standard email isn't enough.
Active subscribers. These customers have recurring billing authorisations that need attention. The email needs to explain that subscriptions continue but they may need to update payment details. Most subscription apps handle re-vaulting silently, but the 5 to 15% that fail need explicit communication. Best to stage subscriber communications separately from the broader customer base.
B2B and wholesale. Account managers should reach out individually to top accounts before the broader email. The B2B login flow is different (company-aware) and the workflow changes are bigger. A single email isn't enough for this segment.
VIPs and top spenders. A personal email from someone known to them (account manager, founder, head of CX) outperforms the generic broadcast significantly. For brands with a top 5% segment that drives a disproportionate share of revenue, the extra effort pays back.
The standard customer email handles 90+% of the base. The other 10% deserves named attention.
B2B customer migration specifically
B2B customer migration is more involved than B2C. It's not just data; it's structure.
Source platforms model B2B differently. WooCommerce uses plugins like B2BKing or custom code. Magento has multiple commerce-tier B2B implementations. Salesforce Commerce Cloud has its own structure. ATG had a sophisticated B2B model. Each platform has different concepts that need translationThe migration usually involves these steps:
Step 1: Audit source B2B structure. What does a company look like on the source platform? What are the buyer roles? What pricing rules apply per account?
Step 2: Reconstruct companies. Create company records with all locations.
Step 3: Re-assign customers. Map customer records to company locations with appropriate permissions (admin, location admin, ordering only).
Step 4: Build catalogues. Translate pricing rules into Shopify B2B catalogues. Each pricing tier or per-account pricing rule becomes a catalogue.
Step 5: Configure payment terms. Net-30, net-60, prepaid, and approval thresholds get configured per company.
Step 6: Test before broadcast. Sample companies log in and complete a test transaction before broader cutover.
For B2B-heavy brands, customer migration can be the longest workstream of the entire migration. A 4 to 8 week project parallel to the rest of the build is normal.
Edge cases worth flagging
Three edge cases come up often enough to plan for.
Duplicate customers. Source platforms often accumulate duplicates: same person registered twice with different emails, account merges that didn't fully complete, guest checkouts that created shadow records. Migration is the moment to deduplicate. The script logic merges by primary email, secondary email, and phone where confidence is high, and flags ambiguous matches for manual review.
Inactive customer pruning. Some brands use the migration to retire customers who haven't ordered in 24+ months. Reduces the customer database, improves email metrics, and clarifies the active base. The decision is brand-specific. Some brands keep inactive customers because reactivation campaigns work. Others prune.
International customer data. Customers across multiple regions may have different consent states or privacy obligations. GDPR, CCPA, and Australian privacy law all apply differently. The migration needs to preserve consent state per customer per region, and the password reset email needs to comply with local consent requirements.
Where to start
If you're planning a migration and want to handle the customer side cleanly, the audit phase should include a customer data audit covering total count, duplicate count, B2B structure, subscription population, and segmentation. The output is a migration plan, a communications timeline, and a re-vaulting strategy for any payment authorisations.
For the related glossary entry that covers this in summary form, see customer account migration. For broader context on Shopify Plus migrations, see the complete migration guide.
For the SEO and infrastructure work that runs alongside customer migration, how to preserve SEO when migrating to Shopify Plus covers the URL and ranking work. For platform-specific guidance on customer data structures, the Magento, WooCommerce, and Salesforce Commerce Cloud playbooks cover what's specific to each source.
Or browse the rest of our Platform Migration insights for more on the operational decisions that come with a re-platform.
Frequently asked questions
Why can't customer passwords transfer between platforms?
Passwords are stored as one-way cryptographic hashes generated by specific algorithms (Magento uses SHA-256, WooCommerce uses PHPass, Shopify uses bcrypt). The hashes are not interchangeable between platforms because each platform's authentication system can only verify against its own hash format. The only way to transfer a working password would be to know the plaintext, which nobody has. This is a security feature, not a limitation.
What customer data actually transfers during migration?
Almost everything except passwords. Email, name, addresses, marketing consent state, customer tags, custom fields, order history, account creation date, total spend, and order count all transfer through migration scripts. Subscription state and stored payment methods need separate handling. B2B organisation memberships transfer but the structure typically gets reconstructed because target platforms model B2B differently.
How do customers regain access after migration?
Through a forced password reset on first login. The standard pattern is a launch-day email campaign explaining the move with a password reset call-to-action. Most brands hit 30 to 50% reset completion within 30 days, 50 to 70% within 90 days, and 70 to 85% within 12 months. The remaining 15 to 30% are inactive customers who never come back regardless.
Will my saved payment methods transfer to Shopify Plus?
Saved credit card tokens are stored with the payment processor, not the platform. If you're staying on the same payment processor (Stripe to Stripe, for example), token migration is sometimes possible but requires direct work with the processor. If you're moving processors (common when consolidating to Shopify Payments), tokens cannot be re-vaulted and customers re-enter card details on next purchase.
What about active subscriptions during migration?
Subscription apps like Recharge and Skio have re-vaulting tools that handle 80 to 95% of subscriptions automatically by working with the payment processor. The remaining 5 to 20% need a customer-initiated payment update. Subscriber communications should be staged separately from the broader customer base because the message and stakes are different.
How should I communicate the migration to customers?
A single launch-day email handles 80 to 90% of the customer base. Subject line should be brand-led and direct ("We've moved [Brand] to a new home" rather than "Your password has expired"). Body should be a one-paragraph note from a real human at the brand explaining the move and previewing what's better. For VIPs, B2B accounts, and active subscribers, send personalised communication separately.
How does B2B customer migration differ from B2C?
B2B is more involved because it's not just data, it's structure. Source platforms model B2B differently (Magento companies, SFCC customer groups, ATG organisations). The translation involves reconstructing companies, locations, customer permissions, catalogues, payment terms, and approval workflows. For B2B-heavy brands, customer migration is usually 4 to 8 weeks of parallel work.
What happens to inactive customers during migration?
Inactive customers (no orders in 24+ months) migrate by default but are candidates for retirement. Some brands prune them during migration to clean up the database, improve email metrics, and clarify the active base. Other brands keep them because reactivation campaigns work. The decision is brand-specific. The migration audit should flag inactive customer counts so the decision is deliberate.
A Shopify Plus Agency for Strategic Design & Advanced Engineering
Building something ambitious?
- Passwords don't migrate between platforms because they're stored as one-way hashes generated by different algorithms. There is no technical workaround.
- Everything else transfers cleanly: email, name, addresses, marketing consent, customer tags, order history, custom fields, and B2B organisation membership. The migration is non-trivial but well-understood.
- The standard resolution is a forced password reset on first login post-launch. Communications strategy decides whether customers find it confusing or expected.
- For high-value segments (subscribers, B2B, VIPs), the email needs to be staged differently. Generic "your password expired" emails get ignored or marked as phishing.
- B2B customer migration is more involved: company hierarchies, locations, payment terms, and approved buyers usually need to be reconstructed rather than imported as flat customer records.
