Shopify's Non-Plus Checkout Deadline: What Breaks on August 26, and the Order to Fix It

There is a deadline sitting in the Shopify admin of every Basic, Grow, and Advanced store that still customizes its post-checkout pages, and as I write this at the end of July 2026 it is under four weeks away: August 26, 2026. Shopify's own wording is unambiguous — "If you're on a non-Plus plan, then you have until August 26, 2026 to upgrade and replace your Thank you and Order status pages," and if you don't, those pages get auto-upgraded for you.

If you build or maintain Shopify stores for clients, this is the month that matters. Not because the migration is hard — for most stores it genuinely isn't — but because the failure mode is silent. Nothing throws. Nothing 500s. A field that used to run JavaScript stops running JavaScript, and the first symptom is a conversion column in an ad platform that quietly goes soft weeks later.

The single biggest source of confusion here is that almost every article on the topic mixes up two different audiences with two different deadlines. So before anything else: which side of the line is the store on?

One format note: the canonical version of this article carries an interactive decision quiz and a tickable migration checklist, neither of which survives a plain markdown feed. Below I have written out the same routing logic and the same steps as text, and linked to the interactive versions.

Two deadlines, two completely different stories

Sources: Shopify Help Center — Plus upgrade guide and upgrade guide.

The detail most write-ups get wrong

checkout.liquid was only ever available to Shopify Plus stores. Shopify's own theme docs put it plainly: "If your store isn't on Shopify Plus, then you can customize your checkout pages in the theme editor."

So if your client is on Basic, Grow, or Advanced, they are not "migrating off checkout.liquid." They never had it. Their exposure is somewhere else entirely: the additional scripts field and any installed app that injects script tags on the Thank you and Order status pages. That is the inventory to audit — not a theme file that was never in the repo.

This matters practically, because if you go looking for checkout.liquid in a non-Plus store's theme, find nothing, and conclude the store is unaffected, you have just cleared a store that is fully affected.

The actual timeline, with the official post for each event

Two of these are worth flagging for anyone doing client work right now. First, the in-checkout steps have been off checkout.liquid since August 2024 — that is two years of "unsupported," not a pending change. Second, Shopify Scripts is a genuinely separate sunset that already fired on June 30, 2026; if a store's discount or shipping logic went strange this summer, that is a different rabbit hole (we cover it in a separate Scripts-to-Functions guide).

What "breaks" actually means

For the three in-checkout steps, breakage is total and already historical: checkout.liquid is, in Shopify's present-tense wording, "now unsupported for the Information, Shipping, and Payment checkout steps."

On the post-checkout pages the failure is quieter and, for a developer inheriting a store, much nastier. On a legacy checkout the additional scripts field goes read-only — visible, populated, apparently fine. Then at the deadline the scripts in it simply stop firing. As one agency writing about the 2026 migration describes it: "every script in that field stops firing. No warning popup, no gradual sunset."

Shopify's own help page is the formal version of the same thing: "Additional scripts for tracking and analytics and page customizations aren't supported on the new Thank you and Order status pages."

The part that costs real money: analytics

This is where the silent failure turns expensive. Tracking that lived in additional scripts stops the moment a shopper enters the new checkout — middle-funnel events like begin_checkout and add_payment_info disappear from the stream. And because Shopify stopped passing personally identifiable data (email, phone, name) to legacy tracking scripts, platforms like Meta lose the fields they used to match conversions on.

One analytics team that audits these migrations (QE Retail) reports that the gap between Shopify's order counts and ad-platform-reported conversions can hit 30% or higher, and estimates that high-volume stores lose 15% to 20% of revenue into that reporting gap. Treat that as one team's findings rather than an industry benchmark — but the direction is not really in dispute, and the diagnostic signature is distinctive: orders in the admin look normal, the ad platforms report fewer and fewer of them.

The replacement channel is the Web Pixels API, which Shopify describes as giving "access to a set of controlled APIs for accessing browser APIs and subscribing to customer events, within one of our Lax or Strict sandboxes." If you are rewiring GTM, GA4, and ad pixels the new way, that rewrite is its own project — we walk it end to end in the Google Tag Manager on Shopify guide.

The replacement stack: five tools, not one

There is no single successor to checkout.liquid. There is a toolkit, and picking the wrong piece is the most common scoping mistake:

• Checkout UI extensions — fields, banners, messaging, and content on checkout and post-checkout pages, running in an isolated sandbox instead of your theme.
• Shopify Functions — back-end logic for discounts, shipping, payment, and validation.
• Web Pixels API — the sandboxed replacement for tracking scripts; subscribes to customer events.
• Post-purchase extensions — new UI and functionality on the post-purchase page, the offer screen shown immediately after payment and before the Thank you page.
• Thank you and Order status extensions — the two post-checkout pages non-Plus stores are migrating right now.

Branding — colors, fonts, logos — is configured in the checkout editor. There is no separately named branding-API product to buy, and the URL commonly cited for one returns a 404.

The plan gate, precisely

That last row catches people. Shopify's wording: "Apps that are distributed via the Shopify App Store and contain Functions can be used in all Shopify plans, but custom apps that include Shopify Function APIs can only be used by shops with a Shopify Plus plan." A custom Function you build for a Basic-plan client is not a scoping detail you want to discover in week three.

Hard limits worth knowing before you estimate

These are platform boundaries, not best practices. From the checkout UI extensions docs:

• 64 KB. "Your compiled UI extension bundle can't exceed 64 KB." This is the constraint that quietly kills do-everything widgets, and it is worth checking your bundle size on day one rather than day twenty.
• Isolated sandbox. Extensions "run in an isolated sandbox, separate from the checkout page and other UI extensions" — they cannot talk to each other.
• No payment or page access. They "don't have access to sensitive payment information or the checkout page itself."
• Read-only metafields on Thank you. Extensions there "can read metafields through the Metafields API, but don't have write access."
• Rate limiting. "After an extension is rate limited, it can't make further changes during the buyer's session."

If a vendor or a plan promises something on the far side of one of those lines, that is the moment to ask how.

The order of operations

The canonical article runs this as a tickable checklist; here it is as a sequence. Steps 1–3 are identical whichever route you take, the split is inside step 4, and the rest applies to everyone.

1. Find the store's actual status. Admin → Settings → Checkout → Configurations, then run the upgrade report. Non-Plus stores that haven't migrated also see an admin banner reading "Upgrade Thank you and Order status pages by August 26, 2026." Do this before you promise anyone anything.
2. Inventory what the checkout and Thank-you page actually do. Every custom field, banner, shipping or discount rule, every entry in additional scripts, and every installed app that relies on script tags. The apps are the part clients forget.
3. Route the work. Roughly: if the store only has tracking scripts and no real customization, this is a pixels job and little else. If it has content-level customization — banners, upsells, trust content, order-tracking widgets — the no-code checkout editor plus one app usually covers it. If it has store-specific logic that a settings toggle can't express, that is a UI extension or a Function, i.e. a build.
4. Build somewhere that isn't production. Two routes:
   • No-code: build in a draft configuration. "Draft configurations let you try different apps and branding before you make them active." Only one configuration is active on real traffic at a time, and publishing a draft replaces the current active one — so the live checkout stays untouched while you assemble.
   • Custom: preview on a dev store. "To run your extension locally during development, start a dev server using Shopify CLI. The dev command creates a preview of your extension on your chosen dev store."
5. Test before publishing. The checkout and accounts editor "uses a simulated checkout environment. You can't place orders in this editor, and some checkout and order actions like Pay Now and Buy Again are deactivated." For custom extensions there are two extra steps from the testing docs: preview a block extension in each supported placement by appending ?placement-reference={name} to the checkout URL, and to test against Shop Pay, activate Shopify Payments on the dev store and enable test mode, then "create a guest checkout using a test card for the payment method. Use an email that doesn't have a Shop Pay Account attributed to it."
6. Restore tracking on Web Pixels and customer events. Then actually verify: fire test events, and compare order counts against ad-platform conversions rather than assuming parity.
7. Publish and re-check. Publish the draft, re-run the upgrade report, confirm the legacy banner is gone.

One deployment gotcha that bites teams shipping their first extension: "Checkout UI extensions don't display in checkout until the merchant uses the checkout editor to add the app and place it in checkout." Deploying is not shipping. Somebody has to place the block.

The interactive checklist lives on the canonical article, and the five-question routing quiz is here.

What it costs, honestly

There is no market rate for this and the published data is thin. One migration guide estimates the no-code checkout editor covers about 80% of former checkout.liquid use cases, and puts a developer at roughly 2–3 days to rebuild a typical customization as a UI extension. One agency (Speedboostr) publishes about $5,000–$10,000 and 2–4 weeks for a simple migration, and over $50,000 and 8–16 weeks for complex builds; another (WeArePresta) puts senior developer and architect rates at $150–$300 an hour.

Every one of those numbers comes from a single source. Use them for orientation, never as a benchmark you quote back to a client. The reliable part is the shape of the decision: an app subscription, a scoped build, or accepting the standard checkout. Most stores are in the first bucket and are being quoted for the second.

Why Shopify says it did this

It is worth reading the platform's own framing, because it explains the constraints rather than just imposing them. Shopify called checkout extensibility "an easier way to customize Shopify Checkout in a way that's app-based, upgrade-safe, higher-converting, and integrated with Shop Pay."

The trade is legible: you lose arbitrary code in the checkout, and in exchange checkout updates stop breaking your work, because your code no longer lives in the path the platform is updating. The 64 KB cap and the sandbox isolation are the price of that guarantee, not arbitrary cruelty.

The bottom line

If you maintain non-Plus Shopify stores, do one thing this week: open Settings → Checkout → Configurations on each of them, run the upgrade report, and write down which ones still show the legacy banner. That is a ten-minute task per store and it converts an invisible deadline into a list.

Then work the list in the order above. Tracking first, because that is what costs money and nobody notices it dying. Content customizations second, because the no-code editor and an app cover most of them. Real logic last, because that is the only part that needs a build — and the only part where four weeks is a genuinely tight timeline.

The thing that burns people is not the deadline. It is that nothing announces itself when it passes.

---

Originally published at shopify.ecom-store.pro, where the article includes an interactive migration checklist, a five-question routing quiz, and the full deadline timeline with sources.

Disclosure: this article was created with the help of AI.