Passwords don't move. That's the short answer, and it's worth accepting early because most of the wasted effort in a replatform goes into trying to beat it. When you migrate customer accounts to Shopify you can bring across names, emails, phone numbers, addresses, tags, marketing consent, order history and custom fields. You cannot bring the password hashes. Shopify won't accept a hash from Magento, WooCommerce, BigCommerce, Wix or a bespoke Laravel build, and no app can do it for you either.
So the real project isn't migration. It's getting a few thousand people to set a new password without setting your sending domain on fire in the process.
What actually transfers when you migrate customer accounts to Shopify
The customer CSV import handles the boring, valuable stuff: first and last name, email, company, default address, phone, tags, notes, tax exemption and email marketing status. You can push customer metafields through the same file if you name the columns correctly, which is how we carry over things like loyalty tier, source platform ID, wholesale flag or preferred store location.
Order history is a separate job. Orders come in through the API with the customer's email on them, and Shopify stitches them to the customer record by email match. Get the emails wrong or import orders before customers and you end up with duplicate profiles and a customer service team that can't find anyone. We import customers first, then orders, then reconcile counts by email before anyone touches the theme.
What doesn't come across cleanly:
- Passwords. Ever. More below.
- Gift card codes. Plan on re-issuing balances as new codes and keeping a spreadsheet that maps old code to new, so support can honour a printed voucher someone finds in a drawer in March.
- Loyalty points. These live in whatever app you install on Shopify, not in Shopify. Most loyalty apps take a balance import. Do it after customers exist, not before.
- Saved cards. Tokens belong to your old gateway. A customer who had a card on file at your Magento store starts fresh at Shopify checkout with Razorpay or Shopify Payments.
- Subscriptions. A migration of its own. Don't fold it into the customer import.
Why the passwords can't come with you
Any platform storing passwords properly stores a one-way hash with a salt. The point of a one-way hash is that nobody, including you, can read the password back out. Shopify generates and stores its own hashes with its own scheme, and there is no field anywhere in the Admin API that accepts a foreign one. The only way to set a Shopify password programmatically has always been to hand Shopify the plaintext string, which you don't have.
Which brings up the uncomfortable version of this. If a migration vendor tells you they can carry passwords over from your old store, one of two things is true: they're mistaken, or your old system was keeping passwords in a form somebody can read. The second is a breach waiting to be disclosed, and it's more common on old custom PHP builds than anyone likes to admit. We've opened a legacy database during discovery and found a password column in cleartext. That finding changes the scope of the project. It does not make the migration easier.
The one real exception: Multipass on Shopify Plus
If you keep an external system that owns identity — a membership site, a B2B portal, an app with its own login — Shopify Plus supports Multipass. Your system authenticates the user against its own password store, then hands Shopify a signed, timestamped token, and Shopify logs the customer in and creates the account if it doesn't exist. The customer's password never changes, because Shopify never sees it.
The catch is obvious once you say it out loud: you have to keep running the old authentication system forever, and every login now depends on it being up. That's a sensible trade for a subscription platform or a members-only catalogue. It's a bad trade if the only reason you're doing it is to avoid sending a reset email. If you're weighing whether Plus earns its keep for this and a handful of other reasons, we've written more plainly about that on our Shopify Plus page than most agencies will.
Consider passwordless before you build a password strategy
Shopify's newer customer accounts don't use passwords at all. The customer types their email, gets a six-digit code, and they're in. No reset link, no forgotten password, no invite acceptance step that half your list ignores.
For a lot of Indian D2C stores this is closer to what shoppers already expect. People are used to an OTP. They are not used to remembering which of four passwords they used on your site in 2022. Switching to the newer accounts experience turns the entire password migration problem into a non-problem, and it's a setting, not a build.
The trade-offs are real though. The account area is hosted by Shopify and your control over its look and behaviour is limited compared with a Liquid template you can rewrite line by line. If you've built a heavily customised account dashboard — order reordering, warranty registration, a distributor portal — check what survives before you flip it. We've had to reverse this decision on stores where the account page was carrying more weight than anyone remembered.
Shrink the list before you email anybody
Most brands over-migrate. A 60,000-record customer table usually contains a large block of people who bought once, four years ago, from a category you no longer sell. Emailing all of them an invite to set a password on a store they don't remember is the fastest route to a spam-complaint rate that damages every campaign you send for the next two months.
Segment before cutover, on the old data:
- Ordered in the last 12 months.
- Ordered 13–36 months ago.
- Never ordered, or ordered earlier than that.
Import everyone. Email the first group at launch, the second group later and lightly, and leave the third alone entirely. They're still in Shopify, tagged, searchable, and available for a proper win-back campaign when you have a reason to run one.
The arithmetic, with made-up but honest numbers
Say you have 60,000 records: 18,000 bought in the last year, 14,000 in the two years before that, 28,000 older or never. You mail the 32,000 in the first two groups and skip the rest.
Send in batches of 2,500 a day and that's a 13-day run. If 12% of the 32,000 end up activating an account across the whole sequence, you've got 3,840 logged-in customers. Sounds thin. It is thin, and it's also normal, because Shopify checkout does not require an account. The other 28,160 will buy as guests and never notice anything happened.
Here's the number that actually matters. If you'd mailed all 60,000 in one blast from a domain with no recent sending history, and 0.4% hit the spam button, that's 240 complaints in a day. Gmail starts throttling you well below that. You'd have traded a few hundred extra account activations for a deliverability problem that costs you real revenue in the festive quarter. The passwords were never the risk. The list was.
A re-activation sequence that limits list decay
This is the flow we run, with dates relative to go-live:
- T-5 days, engaged segment only. A plain heads-up: the store is moving, order history is coming with you, you'll need to set a new password once. No invite link yet. This one email does more for your support inbox than anything else in the sequence.
- Day 0. Account invite to the 0–12 month segment, batched daily. Subject line names the brand and says "set your new password" in words a human would use. Body explains why, in one line, without apologising for four paragraphs.
- Day 3. Resend to non-openers only, new subject line, same offer. Nothing to non-openers except this.
- Day 8. Reason-to-bother email to openers who didn't activate: saved addresses, order history, faster reorder. If you add an incentive, use free shipping rather than a percentage. A discount pulls in people who wanted a discount, not people who wanted an account.
- Day 18. Last call, then stop. Anyone still silent goes back into your normal campaign calendar. Chasing further doesn't convert, it just accumulates complaints.
- Ongoing. Trigger the invite after a guest checkout instead. Intent is fresh, the email is expected, and activation rates are far better than anything a cold reactivation blast produces. This one flow will out-perform the whole launch sequence within a quarter.
Start the 13–36 month segment two weeks after the first group has finished, at half the daily volume, and watch complaint rate per batch rather than per campaign. If it drifts up, stop and cut deeper. Being Omnisend-certified mostly means we've watched enough of these runs to know when to abandon one.
What breaks in week one
The invite links expire. Check the current window in your admin before you schedule anything, and make sure your day-18 email doesn't point people at a dead link — a customer clicking an expired invite and landing on an error is worse than not mailing them.
Then the login page. People will type their old password, watch it fail, and conclude their account was hacked. Put a line of copy directly above the login form for the first 60 days explaining that passwords were reset during the move, with the reset link right there. Add the same line to the order confirmation email footer. Write a support macro before launch, not after the fifteenth ticket.
Redirect old account URLs too. If your old platform used /customer/account/login or similar, those links are sitting in years of email archives and browser bookmarks. They should land on the Shopify login page, not a 404. Full redirect mapping is part of any migration worth paying for — we cover how we handle it on our Shopify migration page.
One more: consent. Whatever marketing permission your old platform recorded, carry it across accurately in the import, including the unsubscribes. Re-subscribing people because a CSV column defaulted to "yes" is the kind of mistake that's cheap to prevent and expensive to explain.
If you're mapping this out now, export your customer table with a last-order-date column and count the three segments before you plan a single email. The size of that first bucket tells you what the reactivation project actually is. A free audit gets you a second opinion on the numbers if the answer looks worse than you expected.