For years, customising a Shopify Plus checkout meant editing checkout.liquid — a theme file with the checkout inside it. It was flexible in the way that a file you can edit is always flexible, and fragile in the same way. Shopify retired it, and stores that had years of accumulated checkout tweaks had to move them somewhere else.
The replacement is not a file. It is a set of extension points, and the mental model is different enough that teams often try to rebuild the old customisation shape and fail.
What replaced checkout.liquid?
Three separate mechanisms now cover what one file used to do.
Checkout UI extensions add interface elements at defined points in the checkout. You do not paint anywhere on the page; you render into a target. Shopify publishes those targets explicitly — after each line item, before or after the discount form, above or below the payment method list, before or after the shipping address form, under each shipping option, and so on. You pick the target, and Shopify renders your component there.
Shopify Functions handle logic rather than interface: which discounts apply, which delivery options appear, which payment methods are visible, whether a cart passes validation. This is backend code Shopify runs during checkout, not JavaScript in the browser.
The branding API handles the visual layer — colours, typography, corner radii, button styles — as configuration rather than CSS overrides.
Why the constraint is the point
The obvious complaint is that targets are more limited than a file you can edit freely. That is true, and it is deliberate.
checkout.liquid customisations broke silently. Shopify would ship a checkout change, someone's selector would stop matching, and a store would discover weeks later that its upsell had quietly disappeared — or worse, that a validation step had. Because the customisation lived in theme markup, nothing tested it and nothing warned about it.
Extensions are versioned against an API. When Shopify changes the checkout, extensions built against a supported version keep working, and upgrading is a deliberate step with a migration path rather than a silent break. Checkout is the one page where a silent break costs revenue immediately, which is why it is the one page Shopify closed off.
Where old customisations land
Mapping is usually straightforward once you sort customisations by what they actually did.
Trust badges, delivery-time notes, gift messages, custom field capture and post-purchase upsells become UI extensions at the relevant target.
"Hide this payment method for orders over X", "only show express shipping in these postcodes", "apply this discount when the cart qualifies" become Functions. These are the ones most often mis-scoped, because in the old world they were implemented as JavaScript that hid an element — which never actually removed the option, it only hid it.
Font, colour and spacing changes become branding configuration, and typically shrink from hundreds of lines of CSS to a settings block.
A small number of customisations do not map at all, and that is the honest part of the conversation. If a store had rewritten the checkout flow itself — reordering steps, injecting an interstitial page — there is no equivalent. Those need rethinking as a different mechanism, usually earlier in the funnel.
What this means if you are still on a legacy setup
The practical risk is not the migration work. It is that nobody has inventoried what the old checkout actually did. Checkout customisations accumulate over years, added by different agencies and apps, and the store owner rarely has a list.
Start with the inventory, not the code: every element that appears in checkout, every rule that changes what a customer sees, and who asked for it. A surprising share turns out to be obsolete — a badge for a payment method the store no longer takes, a rule for a promotion that ended.