Reviewed November 6, 2026

Checkout Extensibility Broke Your Custom Code: Where the Old Scripts Went

If your custom checkout code stopped working, it did not break. Shopify removed the thing it ran on. Checkout.liquid is deprecated for new customizations, and the replacements, checkout extensibility and Shopify Functions, do not run the same code in the same places.

The surprise is not that Shopify changed checkout. The surprise is how many stores discovered the change when something stopped working, rather than when they planned for it. A tracking pixel that went silent, a discount that stopped applying, a custom field that vanished from the order: each one is a piece of old code that no longer has a place to run.

What actually got removed

Checkout.liquid was the file that let Plus stores rewrite the checkout page. Shopify deprecated it and replaced it with checkout extensibility, a system of UI extensions and Functions that runs in defined places instead of letting merchants edit the page directly. Shopify Scripts, the old way to write custom discounts and shipping logic, was replaced by Shopify Functions, which run server-side and cannot be edited in the admin the way scripts were.

The change is not cosmetic. Code that ran in the browser now runs on the server, code that edited the page now runs in an extension point, and code that had no replacement simply has nowhere to go. A store that never inventoried its checkout customizations discovers the gaps one failure at a time.

Where your old code went

Tracking pixels and analytics move to web pixels and customer events, which run in a sandbox and cannot touch the checkout page directly. Discounts move to Functions, which apply server-side and work in express checkouts where old scripts never ran. UI changes move to checkout UI extensions, which place content in defined spots rather than anywhere on the page.

Each replacement is narrower than the thing it replaced, which is the point. Shopify is trading flexibility for stability and speed. The store that maps each old customization to its replacement before migrating keeps its checkout working. The store that migrates by copying old code into new places finds out what has no replacement.

The migration order that hurts least

Inventory every checkout customization first: the pixels, the discounts, the shipping rules, the custom fields, the scripts. Map each one to its replacement, or mark it as having none. Test in a draft checkout before touching the live one, and test the analytics pixel specifically, because it is the one most stores lose silently. A pixel that stops firing does not produce an error. It produces a gap in the data that shows up weeks later.

Frequently asked questions

Is checkout.liquid still supported?

No, not for new customizations. Shopify deprecated checkout.liquid and moved checkout customization to checkout extensibility, built on UI extensions and Functions. Stores still running checkout.liquid customizations need to migrate them, because the old file has no future.

What replaced Shopify Scripts?

Shopify Functions. Scripts ran in the checkout and could be edited in the admin. Functions run server-side, are installed as part of an app, and apply in express checkouts where scripts never ran. The logic moves, but the editing experience is different.

Can I still add custom code to checkout?

Yes, in defined places. Checkout UI extensions let you add content and fields at specific extension points, and Functions let you change pricing, discounts, and shipping logic. What you cannot do anymore is edit the checkout page directly.

How do I move tracking pixels to checkout extensibility?

Use web pixels and customer events, which run in a sandbox and report to your analytics tools. The pixel code itself changes, because it can no longer touch the page directly. Test the new pixel in a draft checkout and compare the event counts with the old one before going live.