Classic vs New Customer Accounts on Shopify: What Actually Changes
Shopify now offers two account systems and they feel different to run, not just to look at. Classic accounts are the familiar email and password model, with account pages many themes and apps have customized for a decade. New customer accounts sign customers in with a one time code sent to their email, remove passwords entirely, and give a different account area with order history, profile settings, and, on suitable plans, B2B and returns related features depending on configuration. Stores ask which one is better. The honest operator answer is that new accounts are the direction of travel, but switching changes support patterns, app compatibility, and how repeat customers experience your store, so it deserves a planned move, not a toggle on a busy afternoon.
Sign in without passwords changes your support tickets
Password resets are a steady slice of account support on classic accounts, and they vanish with code based sign in. In their place you get a different ticket: the code went to spam, the code expired, the customer typed the wrong email and cannot understand why no code arrives. Those tickets are easier to resolve, but your help content and your support macros need rewriting before the switch, not after the first confused regular writes in. Tell customers in advance, on the account page and in a short email, that sign in is changing and no password is needed anymore. The customers most affected are your oldest regulars, the ones with a saved password and a routine, and they are exactly the customers you can least afford to confuse.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Shopify Markets vs Multiple Stores: Which Setup Fits, What the Shopify Shop Channel Actually Does for Your Store, and Shopify Shipping Zones vs Rates: What Each One Controls.
What customers gain and what they lose
New accounts give a cleaner order history, easier profile and address handling, and a sign in that works the same on a new phone with no password manager archaeology. On the loss side, some classic account page customizations do not carry over: the extra tabs, loyalty panels, download links, and custom fields that themes and apps injected into the old account template may not appear in the new account area, or may need a different extension based approach. Audit what your classic account page actually contains before switching. Merchants are often surprised by how much quiet functionality accumulated there over years, including wholesale documents and care instructions that customers genuinely use.
Apps, extensions, and the compatibility check that decides timing
The switch question is really an app question. Loyalty, subscriptions, returns, wishlist, and B2B tools each interact with customer accounts differently, and support for new accounts varies by app and by how the app uses extensions. Make a list of every app that touches the account experience, check each vendor current documentation for new customer accounts, and test sign in and the core action of each in a development or test context where possible. Do not take a sales page claim as verification; run the flow. The blocker, when there is one, is usually a single app whose account integration has no new accounts path yet, and finding that out before switching is the entire value of the audit.
Plan the switch like a small launch
Pick a quiet trading period, not a sale week. Update help pages, support macros, and any email that mentions passwords or account sign in. Prepare a short notice for logged in customers and a banner or account page message for the transition window. Switch, then test as a real customer on desktop and mobile: request a code, sign in, view an order, update an address, and run each account connected app flow. Watch support contacts for the first two weeks with the account change tagged, so you can separate switch confusion from ordinary volume. Stores that do this find the move uneventful, which is the goal; account infrastructure should be boring.
Frequently asked questions
Do customers lose their order history when we switch?
No. Order history is tied to the customer record and email, not to the account system interface. Customers who sign in with the same email in new accounts see their past orders. The confusion risk is a customer using a different email than the one on their orders, which happened under classic accounts too, but surfaces at switch time because everyone signs in fresh. Your launch messaging should tell customers to use the email they ordered with, and support should check for duplicate customer records first when history appears missing.
Can we switch back to classic accounts if it goes badly?
Shopify has allowed stores to move between account versions, but you should treat switching as a decision with friction rather than a free toggle, because app configurations, customer communication, and any new accounts specific setup all have to be unwound. Check the current rules in Shopify documentation at the time you plan the move, since platform details change. The practical protection is the pre switch audit and a quiet launch window, which make a reversal unlikely to be needed.
Do new customer accounts work for B2B buyers?
New customer accounts are the foundation Shopify builds its newer B2B experience on, including company profiles and buyer specific views on suitable plans. If B2B matters to you, that is an argument for switching rather than against it. The detail work is testing your specific B2B flows, catalogues, payment terms, and any app layer, with a real buyer account before inviting customers across. Plan eligibility and feature availability change over time, so verify against current Shopify documentation for your plan.
Why do some customers say the sign in code never arrived?
The usual causes are mundane: the code went to a spam or promotions folder, the customer entered an email that differs from their account email, or they requested several codes and used an older one after a newer one was issued. Support should ask which email they used, tell them to use only the most recent code, and check spam first. Building those three checks into a support macro resolves most code tickets in one reply, which is a better support experience than the password reset trail it replaces.