New Customer Accounts Broke Every Template Override You Had

The merchant turned on new customer accounts and immediately reported that the login page had lost its styling, the order history looked like a default, and none of the custom fields appeared. Every template the theme had overridden for the customer area was, as far as the storefront was concerned, gone.

Nothing had been deleted. The migration had changed which system renders the customer area, and the old Liquid templates for customers/login, customers/account and customers/order simply stopped being the rendered surface. The override was intact and irrelevant, which is a worse feeling than a missing file.

This is the migration gap between legacy customer account templates and the extensible accounts, and the fix is understanding what renders what now.

What changed architecturally

Legacy customer accounts were server rendered Liquid. The theme owned the templates, and overriding them was the whole customisation model.

New customer accounts move the experience to a set of hosted, extensible surfaces. The login and account flows are rendered by Shopify's account UI, customised through UI extensions and configuration rather than through the theme's Liquid files. So the theme's customer templates are bypassed entirely when new accounts are enabled.

The practical consequence is that any branding, field or behaviour that lived in those Liquid overrides must be rebuilt in the new model, and until it is, the customer sees defaults. This is the same migration shape as checkout extensibility, covered in shopify checkout extensibility migration, where the theme lost ownership of the surface and gained an extension model instead.

Why it reads as a bug

The switch is a setting, and settings feel reversible and small. The merchant toggles it, expects the same pages with new features, and instead gets a different rendering pipeline. Because the old templates still exist in the theme, developers assume they should apply, and spend time debugging why Liquid changes have no effect, when the honest answer is that the file is no longer in the render path.

The debugging dead end is the signature. If you edit a customer Liquid template, deploy, and see no change at all, with new accounts enabled, stop debugging the template and confirm which surface is rendering. That confirmation is the diagnosis.

What survives and what must be rebuilt

Some things carry over conceptually but not literally.

Branding. Colours, logo and typography move to the account configuration and to the brand assets that the hosted surfaces consume. Your CSS in the theme does not reach them.

Custom fields and data. Anything you rendered from customer metafields in Liquid must now be surfaced through the account extension points that expose customer data, or through the customer metafields API read by your extension. The data model is still there, the rendering path is not.

Behaviour. Custom validation or flows that lived in template level JavaScript must be reimplemented as extensions or accepted as lost. Some legacy behaviours simply have no equivalent yet, and deciding which to drop is part of the migration.

The migration sequence that works

Run both, read the traffic. Before switching, confirm what percentage of customers actually use the account area, and which pages they touch. The order history and login are usually the whole surface, which narrows the rebuild to a few screens.

Inventory the overrides. List every customers/* template and snippet that differs from the theme default, and every behaviour added in JavaScript. That inventory is the migration scope. Anything not on the list can be abandoned without loss.

Rebuild the high traffic surfaces first. Login and order history carry almost all the usage. Rebuild their branding and data in the new model, verify against the inventory, and only then flip the setting for everyone.

Keep a rollback story. The setting is reversible, but only if you have not deleted the legacy templates or assumed data changes that the legacy path cannot read. Reversibility is a property you preserve on purpose.

The review checklist

For any store enabling new accounts, ask: which templates will stop rendering, which overrides are on the inventory, and which have been rebuilt in the extension model. If the answer to the last is none, the store is about to show defaults to its customers and call it an upgrade.

This is the recurring theme of platform migrations on Shopify. The platform moves a surface from theme ownership to an extension model, and every override becomes a decision rather than a given. The metaobject and section rendering versions of the same lesson are in the section rendering API returning yesterday's cart.

The merchant communication half

The technical migration is only half the job, and the half that gets skipped is the one merchants feel. The account area is where a store's most loyal customers look it in the eye, and a sudden switch to unstyled defaults reads as neglect, not as an upgrade.

Before flipping the setting, set the expectation. Tell customers the account area is changing, keep the highest traffic screens branded first, and keep the legacy surface available until the new one has been verified against the inventory. A migration that lands with the login and order history intact and branded will be read as an improvement. The same code, landed with defaults everywhere, will be read as an outage, because from the customer's seat that is what it is.

The rule

When a platform moves a rendered surface out of the theme, your overrides do not break. They retire. The migration is not a fix to the old files, it is a rebuild of their intent in the new model, scoped by an inventory of what actually mattered.

Confirm which pipeline renders before debugging a template that may no longer be in the path, and treat "my Liquid change has no effect" as the signal that you are editing a museum piece rather than a live page.