Shopify Checkout Extensibility: The August 26 Deadline
The failure mode is not a broken page. It is tracking that goes quiet while the store keeps taking orders.
Two deprecations landed close together and they keep getting merged into one. Shopify Scripts stopped executing on 30 June 2026 — discount, shipping and payment logic written in the Script Editor no longer runs anywhere. Separately, legacy customisation of the Thank you and Order status pages ends for non-Plus stores on 26 August 2026. Plus stores passed that point on 28 August 2025.
What actually stops working
checkout.liquid was already unsupported for the Information, Shipping and Payment steps. What remains on the clock is everything post-purchase: additional scripts, script tags and checkout.liquid on the Thank you and Order status pages.
- Google Ads conversion tags and Meta pixels injected through additional scripts
- GTM containers loaded on the order status page
- affiliate and referral scripts that fire on purchase confirmation
- post-purchase upsells, survey widgets, and anything reading order data from those pages
The dangerous property of this deprecation is that the storefront keeps working. Customers check out normally. Orders arrive. Only the measurement layer goes silent, so the first signal is usually a reporting anomaly a week later that gets attributed to seasonality.
What replaces each piece
- Checkout UI extensions — interface changes at defined extension points, running sandboxed rather than on the page
- Shopify Functions — discount, shipping and payment logic; the replacement for Scripts
- Web pixels — the supported path for analytics, in a sandbox with a defined event schema
- Branding API and the checkout editor — the styling that used to live in CSS overrides
The mapping is not one-to-one, and pretending otherwise is how these migrations run over. Web pixels give you an event contract and a sandbox, not arbitrary DOM access. Code that read the page to scrape a value has no direct equivalent — it needs rewriting against the event payload.
Audit your own store before estimating
Find out what you actually have before scoping the work. Shopify's Scripts customisations report covers Script Editor logic. For the post-purchase side, the settings themselves are the inventory.
# collect the inventory before estimating anything Settings -> Checkout -> Additional scripts # legacy post-purchase JS Settings -> Checkout -> Order status page # legacy customisations Apps -> installed apps # anything still injecting script tags # then confirm what is actually firing in production open a real order confirmation, watch the network panel, list every third-party request, and match each one to an owner
That last step matters more than the first two. Stores accumulate tags nobody claims, added for a campaign that ended two years ago. A meaningful share of the migration effort is deciding what genuinely needs to survive.
Server-side is the honest answer for tracking
If your conversion tracking depends on a browser tag firing on a page Shopify is taking away, this is a good moment to stop depending on that at all. Order data reaching the Meta Conversions API or the Google Ads API from your own backend does not care which page rendered, whether a pixel loaded, or what an ad blocker did.
Web pixels are the supported client-side path and worth wiring up properly. But a server-side pipeline keyed on the order webhook is the version that survives the next deprecation as well as this one.
If you are reading this after the deadline
The automatic upgrade removes legacy customisations; it does not relocate them. Recovery is the same work as the migration, run under worse conditions: reconstruct what was on those pages, identify which conversions stopped being recorded, and backfill the reporting gap from order data before it hardens into a quarter of numbers nobody trusts.
Reconcile platform-reported conversions against actual Shopify orders for the affected period. That gap is the real damage, and it is recoverable from order exports.