Shopify checkout extensibility, after the deadlines

Most writing about checkout extensibility is still in the future tense. It should not be. The deadlines Shopify published have passed, the automatic upgrades ran, and stores that did not migrate did not get a warning banner — they got a checkout with the customizations removed.

If you are reading this because something in your checkout stopped working and nobody can find the code that used to do it, this is the article for you. The code is not broken. It is gone, and it went on a published schedule.

What actually happened, and when

Shopify's own upgrade guide is blunt about the sequence. August 28, 2025 was the deadline to upgrade the Thank you and Order status pages, "including your apps using script tags and additional scripts." Then, in January 2026, "automatic upgrades began, and all customizations using additional scripts, apps with script tags, or checkout.liquid on the Thank you and Order status pages will be lost."

Lost is the operative word, and it is Shopify's. There was no fallback rendering, no degraded mode. The upgrade replaced the page and whatever was hanging off it went with it.

The main checkout steps went earlier and harder. checkout.liquid is now unsupported for the Information, Shipping and Payment steps outright. Script tags on the Thank you and Order status pages were sunset for Plus stores on that same August 2025 date, and for non-Plus stores on August 26, 2026.

So there is no migration window left to plan for. There is an audit to do.

What replaced it, honestly

The thing people miss is that checkout.liquid was not replaced by one thing. It was one file that could do anything, and it was replaced by four separate surfaces, each of which can do a defined subset. That is the whole trade: you gave up "edit the template" and got "extend at supported points," which survives platform updates because Shopify knows where your code is.

Checkout UI extensions are the visible ones. React components that render at named targets in the checkout — a trust message under the payment block, a delivery-instructions field, an upsell above the summary. You do not choose pixel positions; you choose a target, and Shopify decides where that target lives. This is the part merchants find most frustrating and the part that makes checkout updates stop breaking things.

Functions are the invisible ones, and this is where most of the real logic went. Discounts that native rules cannot express, checkout validation that blocks an order, delivery and payment method customization, cart transforms that add a fee line or expand a bundle. They run inside Shopify's own infrastructure at the moment it prices the cart, so there is no server of yours that can be slow or down. We build these, and the constraint that surprises people is not the language — it is that a Function cannot call your database or read a clock.

Branding and settings cover what used to be CSS. Colors, typography, corner radius, logo placement, layout choice — configured, not styled. If your old checkout had a layout no setting can express, this is where you find out.

Web pixels cover the analytics that used to live in additional scripts. They run in a sandbox with a defined event schema rather than as arbitrary JavaScript on the page, which is why a lot of tag-manager setups needed rebuilding rather than porting.

What maps to what

A useful way to audit an old checkout is to go through it by intent rather than by code.

Anything that changed a price or a rule — tiered discounts, customer-group pricing, minimum order enforcement, hiding a payment method from certain carts, blocking a PO box — is Function work. It moved from Scripts, and Scripts is gone too: editing was disabled on 15 April 2026 and every published Script stopped executing on 30 June 2026. If your rules were Scripts, they are not running now — the dated timeline is here, including the separate script-tag deadline that runs to March 2027 and catches people who thought they were finished.

Anything that showed or collected something — a gift message field, a delivery date picker, a returns policy notice, a B2B PO number — is a UI extension.

Anything that looked a certain way is branding, and this is where the honest answer is sometimes "you cannot have that back." A checkout that was visually rebuilt in Liquid does not port. What ports is the intent behind it.

Anything that fired a tag is a web pixel, and it needs re-testing rather than re-pointing, because the event names and payloads are not the ones your old scripts listened for.

How to find out what you lost

If the automatic upgrade ran on a store you inherited, nobody may know what used to be there. Three places to look, in order of usefulness.

The theme's git history or a theme backup, if one exists from before the upgrade. The old checkout.liquid is the specification for everything that used to happen, and it is the only place the intent is written down.

The order records themselves. Order attributes, note attributes and line item properties that stopped appearing on new orders tell you exactly which field disappeared and roughly when.

Support tickets and internal complaints. In practice this is the fastest signal — the missing thing is usually already being reported as "customers can't leave delivery instructions any more," and nobody connected it to a platform deadline.

The part worth saying plainly

Checkout extensibility gets described as a limitation, and in the narrow sense it is: there are things the old file could do that no extension point will ever do. But the old arrangement was one where every Shopify checkout improvement risked breaking your store, so improvements were slow and your customizations were fragile in both directions.

The current arrangement is worse for the store that wants a bespoke checkout and much better for the store that wants a checkout that keeps working. Most stores are the second kind and had been sold the first.

If your checkout lost something in the upgrade, the useful question is not how to get the old implementation back. It is which of the four surfaces the intent belongs to now — and whether, written that way, it survives the next update without anyone having to think about it. That is the work we do here.