# What happens to customer accounts when migrating a store? > When you migrate a store, customer accounts are private data that you export from the source and import into the new platform, not something a front-end capture can reach, and the one thing that usually does not transfer is passwords. A customer account holds an email, saved addresses, order history, and profile details, all sitting in the database behind the login, so it comes across through an export of that data, handled carefully because it is personal information. Passwords are the exception: they are stored as one-way hashes that the new platform generally cannot reuse, so most migrations ask customers to reset their password on first login, which you communicate in advance so it feels expected rather than broken. Everything else, their details and order history, can carry over so returning customers find their account intact. WPBuildAI exports your customer records and imports them into the new store, preserves their order history, and sets up a smooth password reset, so accounts survive the move with minimal friction. Source: https://wpbuildai.com/what-happens-to-customer-accounts-when-migrating-a-store/ By lawrence-arya ยท 2026-06-25 --- When you migrate a store, customer accounts are private data that you export from the source and import into the new platform, not something a front-end capture can reach, and the one thing that usually does not transfer is passwords. A customer account holds an email, saved addresses, order history, and profile details, all sitting in the database behind the login, so it comes across through an export of that data, handled carefully because it is personal information. Passwords are the exception: they are stored as one-way hashes that the new platform generally cannot reuse, so most migrations ask customers to reset their password on first login, which you communicate in advance so it feels expected rather than broken. Everything else, their details and order history, can carry over so returning customers find their account intact. WPBuildAI exports your customer records and imports them into the new store, preserves their order history, and sets up a smooth password reset, so accounts survive the move with minimal friction. ## Accounts are private data, so they are exported not captured The first thing to establish is which side of the public line accounts sit on. Much of a store migrates by capturing the public storefront, because product pages and categories are served to everyone. Customer accounts are the opposite: they live behind the login, visible only to the account holder and the store, so a front-end capture cannot read them. This is the same boundary that governs [gated pages](/what-happens-to-password-protected-pages-after-migration) and any private content. It means account data has to come from an export at the source, taken while you still have admin access, rather than from crawling the site. Getting this distinction right up front is what keeps you from assuming a capture covered accounts when it never could. ## What carries over, and the password exception Most of an account transfers cleanly, with one well-known exception. The email address, saved shipping and billing addresses, profile details, and the link to a customer's order history can all be exported and imported into the new platform, so a returning customer finds their account and their past orders intact. Passwords are the exception, because they are stored as one-way hashes, deliberately impossible to reverse, and the new platform usually cannot reuse another system's hashes, so it cannot simply import the old passwords. The standard, safe resolution is a password reset on first login. So plan for everything to migrate except the password, and treat the reset as the one expected step for customers, rather than a sign something went wrong. ## Communicate the password reset in advance The password reset is only a problem if it surprises people. A returning customer who tries their old password, fails, and gets no explanation may assume their account was lost or the store was hacked, and abandon it. The fix is communication: before or at launch, email customers to explain that the store has moved to a new platform and a one-time password reset is needed, with a clear link to do it. Framed as a planned security step, it reassures rather than alarms. This is part of the wider need to [keep your email working through the move](/keep-email-working-when-changing-web-host), since that reset email has to actually arrive. A little proactive communication turns the one rough edge of account migration into a non-event. ## Handle the personal data carefully Customer records are personal information, so security and privacy are part of the job, not an afterthought. The export contains emails, addresses, and purchase histories, which is exactly the kind of data privacy rules like the [GDPR](https://gdpr.eu/what-is-gdpr/) govern, so transfer it securely, limit who can touch the export, and delete working copies once the migration is complete. Do not email customer data around casually or leave exports sitting in shared folders. The migration should preserve the accounts customers depend on without ever exposing their data in the process. Treating the export as sensitive from the moment it is created, and following your own data-protection obligations, keeps the migration from trading account continuity for a privacy risk. ## Accounts are continuity, URLs are traffic As with coupons, it helps to see that accounts are a commerce-continuity concern, separate from SEO. Whether a returning customer keeps their account affects loyalty and lifetime value, not your search rankings, and the platform itself is not a ranking factor, as the [Backlinko analysis](https://backlinko.com/search-engine-ranking) shows. So account migration runs on the commerce track, alongside [exporting orders](/export-woocommerce-orders-without-plugin-cost) and coupons, while the SEO track, preserving product URLs and setting 301s as any [careful site move](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) requires, runs in parallel to protect the traffic that brings customers in. Both matter: the URL work keeps new and returning visitors arriving, and the account work keeps returning customers feeling recognized when they do, given that a minority of loyal customers often drive much of the revenue, echoing the concentration the [Ahrefs study](https://ahrefs.com/blog/search-traffic-study/) finds in traffic. ## Steps to migrate customer accounts 1. **Export customer records** from the source: emails, addresses, profiles, order links. 2. **Handle the export securely** as the personal data it is. 3. **Import the records** into the new platform so accounts are recreated. 4. **Plan for a password reset**, since hashes generally cannot transfer. 5. **Email customers in advance** explaining the one-time reset, with a clear link. 6. **Test a returning-customer login and reset** before launch, and delete working copies after. ## Worked example: returning customers kept their history Consider a store with thousands of registered customers, many repeat buyers who relied on saved addresses and order history. Migrating platforms, the team exported the customer records securely and imported them into the new store, so each account kept its email, addresses, and past orders. Knowing passwords could not transfer, they prepared a launch email explaining the move and the one-time reset, with a reset link. When returning customers arrived, they reset their password once, then found their account and order history exactly as before. Because the reset was expected and the history was intact, the migration felt like an upgrade rather than a loss, and the loyal repeat buyers who drove much of the revenue stayed loyal. ## Limitation: not every account detail maps cleanly It is honest to bound this. Core account data migrates well, but the new platform may model accounts differently, so some details, stored payment methods, loyalty-point balances, wish lists, or custom fields, may not map one to one and can need their own handling or may not transfer at all. Stored payment methods in particular are held by the payment gateway, not really by the account, so they follow the gateway's rules rather than the account export. So inventory what your accounts actually contain and decide per element how it migrates, rather than assuming an account is a single portable object. The email, addresses, and order history are the reliable core; the extras deserve individual attention. ## Key points When you migrate a store, customer accounts are private data behind the login, so they are exported from the source and imported into the new platform, not captured from public pages. Emails, saved addresses, profiles, and order history carry over, but passwords are hashed and generally cannot transfer, so plan for a one-time reset on first login and email customers in advance so it feels expected, not broken. Treat the export as the personal information it is: transfer it securely, limit access, follow your data-protection obligations, and delete working copies afterward. Accounts are a commerce-continuity concern, separate from the URL and 301 work that protects your traffic, and some extras like stored payment methods, loyalty points, or wish lists may not map cleanly and need individual handling. WPBuildAI exports your customer records and imports them into the new store, preserves their order history, and sets up a smooth password reset, so accounts survive the move with minimal friction. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.