Shopify removed the most dangerous file on your store. checkout.liquid gave anyone with theme access the ability to rewrite the page where money changes hands, and it is now unsupported for the information, shipping and payment steps; on 28 August 2025 the same sunset reached the thank-you and order-status pages. Whether that trade helped you or hurt you depends entirely on what your old checkout was quietly doing.
This post is about the surface: what the checkout page allows you to change now, who is permitted to change it, and how to audit a migration most merchants did not choose to run. The logic that decides discounts, shipping availability and whether a cart may proceed at all is a separate mechanism with separate rules, and it has its own post. Keep the two apart and the platform makes sense. Merge them and you will brief the wrong thing to the wrong person.
What actually replaced the file
The replacement is not one thing. It is four surfaces with four permission models: checkout UI extensions, which are small apps that render into slots the platform defines and the merchant positions in the checkout editor; the Admin API’s checkout branding types, which control the design system rather than the markup; Shopify Functions, which run server-side and decide outcomes rather than appearance; and web and app pixels, which carry the tracking that additional scripts used to.
That taxonomy is the genuinely useful part of the migration. "We will rebuild it with checkout extensibility" is not a plan, because the first question about any legacy customisation is which of the four surfaces it belongs to, and the honest answer for some of them is none. A checkout that reordered fields, hid a payment method by manipulating the DOM, or dropped a third-party widget into an arbitrary position is not being ported. It is being redesigned inside a much smaller set of allowed moves.
Who is allowed to change what
Plan gating decides most projects, and it is not uniform across the checkout. Checkout UI extensions for the information, shipping and payment steps are available only to stores on Shopify Plus. Extensions for the thank-you page, the order-status page and the post-purchase moment are available on every plan except Starter. A merchant who is not on Plus is therefore not locked out of checkout extensibility; they are locked out of the first two-thirds of it, which is a different and far more workable constraint than the one they are usually quoted.
Styling follows the same line. The checkout branding API is Plus-only, and it applies globally rather than page by page: the documentation is explicit that styles land across checkout, the checkout queue, checkout UI extensions and customer account pages together. You cannot brand the payment step differently from the thank-you page. For most stores that is a feature rather than a limitation, because the previous freedom is precisely what produced checkouts that looked like three different companies had built them.
What got harder, and it is worth saying so
Anyone describing this migration as pure upside is selling something. Real capability was removed, and the losses cluster in a few predictable places:
- Arbitrary DOM access. There is no jQuery in the new checkout and no injecting markup wherever you like. An extension renders into a slot, and if no slot exists where you wanted the content, the content does not go there.
- Position control. Merchants place extensions in the checkout editor, which is the right default and also means a carefully specified layout is one drag away from being somewhere else.
- Tracking that assumed a script tag. Additional scripts are gone from checkout, and the replacement is a pixel with a defined event contract that is considerably stricter about what it can see.
- Anything that depended on reading personally identifiable information during checkout, which the legacy methods exposed far more freely than the current ones do.
- The slot inventory itself moves. Extension targets are added and revised release to release, so a target that did not exist when the work was scoped may exist now, and the reverse is also true.
The deadline that has not passed yet
Plus merchants have already been through this. The 28 August 2025 sunset closed additional scripts and checkout.liquid on the thank-you and order-status pages, and Shopify has been auto-upgrading stores that did not act, converting what it can on a best-effort basis and dropping the rest. Stores that are not on Plus have one live date left: script tags on the thank-you and order-status pages stop being supported on 26 August 2026. If you are on a standard plan and nobody has audited what still writes to those two pages, that is this month’s job rather than next quarter’s.
Auditing a migration you did not choose
An auto-upgrade is not a migration, it is a survival event, and the thing to check afterwards is not whether checkout still loads. It obviously does. The question is which of the behaviours you were relying on quietly stopped. Work from an inventory rather than from memory: list every customisation the old checkout carried, name the surface each one now lives on, and mark the ones with no equivalent as decisions rather than defects. A mid-size store’s inventory usually runs to about seven items, and two of them typically have no direct replacement at all.
Analytics is where the damage hides longest. A conversion pixel that silently stopped firing does not break a page, it breaks a quarter of attribution, and the symptom arrives months later as paid channels looking mysteriously worse than they are. Reconcile order counts in your admin against your analytics property for the fortnight after any checkout change, before you conclude anything at all about performance.
Test the new checkout rather than admiring it
The upside of the restriction is real: extensions survive theme and platform updates instead of breaking on them, and a checkout that cannot be arbitrarily rewritten is a checkout that can be measured. The constraints also make the old habit of shipping checkout changes on instinct much harder to sustain, which is no loss at all. Checkout is the highest-leverage and least forgiving surface on the store, and the general principles that decide whether one converts are worth reading separately from the platform mechanics.
So treat every extension as a hypothesis. Trust badges above the payment step, a delivery-note field, a post-purchase offer: each is a change to the page where the money is, and each deserves a measured result rather than an opinion. Replacing a legacy checkout is properly Shopify development work rather than theme editing, and it should be scoped by somebody who has read the current extension targets and plan rules before promising a layout. If the 26 August date is still unowned on your store, get in touch.
