Shopify Checkout Extensibility Migration for Non-Plus Stores: What Breaks Before August 26, 2026 (and the Exact Runbook)

If you run a Shopify store on the Basic, Shopify, or Advanced plan, you have a hard deadline that most "checkout extensibility" articles get wrong: August 26, 2026. On that date Shopify automatically upgrades your Thank you and Order status pages and removes the legacy code attached to them — and the single most common casualty is the conversion tracking that quietly funds your ad spend.

The good news, and the part the panic headlines miss: for non-Plus stores this is a much smaller, more contained migration than "your checkout is breaking." This guide is the version-current, code-level runbook we use at Keplaris — what actually breaks, the Shopify APIs that replace each piece, and a tested sequence to cut over without losing a single conversion event. Every deadline and limitation below links to Shopify's own documentation so you can verify it yourself.

The 60-second version

• Deadline: August 26, 2026 for non-Plus stores (Basic, Shopify, Advanced) (Shopify Help Center).
• Scope: the Thank you and Order status pages only — not the whole checkout.
• What breaks: anything in the Additional Scripts box, app script tags, and order-status scripts — i.e. most of your conversion tracking.
• The fix: rebuild tracking as Web Pixels and rebuild any content as app blocks or checkout UI extensions.
• The catch: Shopify's auto-upgrade is irreversible. Migrate and test deliberately before the date instead of letting it happen to you.

What checkout extensibility actually is (and what it replaces)

For years, customizing Shopify's post-purchase pages meant injecting raw JavaScript and Liquid into script boxes. Checkout extensibility is the supported replacement: a set of sandboxed, upgrade-safe APIs that survive Shopify's checkout updates instead of breaking on them. There are four tools, and each maps cleanly to a legacy mechanism it retires:

The reason for the change is the same reason it's safer: these APIs run in sandboxes Shopify controls, so a checkout update can't be silently broken by a third-party script anymore (shopify.dev — Web Pixels API).

The deadline, decoded

Most confusion comes from blending two separate timelines — the Plus checkout deadline, which already passed, and the non-Plus one, which hasn't. Here is every date that matters, and who it applies to:

As of today, that means non-Plus stores have roughly ten weeks, and any Plus store still on Scripts has about two.

The scope trap: for non-Plus, your checkout is not breaking

Here's where we talk merchants off the ledge. The alarming "checkout.liquid is dead" coverage is real — but checkout.liquid was only ever available to Shopify Plus (shopify.dev). If you're on Basic, Shopify, or Advanced, you never had it. The Information, Shipping, and Payment steps of your checkout were always Shopify-hosted and untouched by this change.

For a standard store, the entire blast radius is the Thank you page, the Order status page, and the script boxes attached to them. That's it. Knowing this is the difference between scoping a tidy week of work and over-quoting a checkout rebuild that was never necessary.

What actually breaks on August 26, 2026

Three legacy mechanisms stop working, and they take real revenue infrastructure with them:

1. The Additional Scripts box (Settings → Checkout) — already view-only for everyone since the Plus deadline, and switched off for non-Plus on the deadline.
2. App ScriptTags on the post-purchase pages — blocked from creation since Feb 1, 2025 and turned off on the deadline.
3. Order-status page scripts — the same fate.

In practice, the casualties are almost always tracking and post-purchase tooling:

• Google Ads conversion tags and Meta Pixel purchase events
• GA4 and Google Tag Manager containers
• TikTok, Pinterest, and other channel pixels
• Affiliate and partner network scripts
• Post-purchase upsell HTML and NPS/survey snippets

If any of those still live in a script box, they go dark — and because nothing visibly errors on the storefront, you often won't notice until the weekly ad report shows conversions cratering.

Why tracking breaks silently: the Web Pixels sandbox

The reason a careless migration fails quietly is architectural. Web Pixels don't run on the page the way Additional Scripts did — they run in a sandbox with no access to the checkout DOM. There are two sandbox modes (shopify.dev — Web Pixels API):

The mental shift: you no longer inject a script that reads the page. You subscribe to events Shopify emits — checkout_completed, payment_info_submitted, product_added_to_cart, and so on — and react to their structured payloads. There is no window.dataLayer on the page to read and no DOM to scrape. Code written for the old model doesn't "mostly work" here; it does nothing.

Consent: why your numbers will legitimately drop

Plan for this conversation before it happens with a client. Web Pixels fire only when the customer has granted consent, whereas Additional Scripts frequently fired regardless. After a correct migration you should expect a measurable gap between GA4 purchase events and actual Shopify orders — that's consent working as designed, not a broken tag. The skill is telling the two apart, which is why the verification test later in this guide compares ratios over time rather than reading a single day.

The audit: inventory every tag before you touch anything

Never migrate blind. Open Settings → Checkout and the personalized upgrade guide Shopify surfaces there, then:

1. Export every snippet from the Additional Scripts and order-status boxes. Don't delete — copy them somewhere safe first.
2. Classify each snippet by destination:
   • Tracking (gtag, fbq, GTM, TikTok) → a Web Pixel
   • UI/content (banners, custom thank-you messaging) → a UI extension or app block
   • Cart/discount logic → a Shopify Function or app (see the Plus note below)
3. Audit installed apps for checkout-extensibility-compatible versions — many marketing apps now ship their own app pixel, which is the lowest-effort path.

If you manage multiple stores, query the checkoutProfile object via the Admin GraphQL API to see upgrade status across an entire client portfolio at once, instead of clicking through each admin.

Migrating tracking: from Additional Scripts to a Custom Pixel

This is the heart of the migration. Here's a typical before — raw tags pasted into Additional Scripts:

<!-- OLD: Additional Scripts box (stops firing Aug 26, 2026) -->
<script>
  gtag('event', 'conversion', {
    send_to: 'AW-XXXX/abcd',
    value: {{ checkout.total_price | divided_by: 100.0 }},
    currency: '{{ checkout.currency }}'
  });
</script>

And the after — a Custom Pixel created under Settings → Customer events → Add custom pixel. Because custom pixels run in a lax-sandbox iframe, you load the vendor library inside the pixel itself and forward standardized event data:

// NEW: Settings → Customer events → Custom pixel
// gtag is loaded inside the pixel's own sandbox, not on the page.
analytics.subscribe("checkout_completed", (event) => {
  const checkout = event.data.checkout;

  // Google Ads
  gtag("event", "conversion", {
    send_to: "AW-XXXX/abcd",
    value: checkout.totalPrice?.amount,
    currency: checkout.currencyCode,
    transaction_id: checkout.order?.id,
  });

  // Meta Pixel
  fbq("track", "Purchase", {
    value: checkout.totalPrice?.amount,
    currency: checkout.currencyCode,
  });
});

Two things to internalize: the data comes from the event payload (event.data.checkout), never from the DOM; and for custom events of your own you publish with Shopify.analytics.publish(...). For GA4 specifically, Shopify documents a Google Tag Manager custom-pixel setup if you'd rather route everything through GTM. When a marketing app already offers a maintained app pixel, prefer it — it's less code you own and patch.

Migrating UI and content: Thank you & Order status blocks

Good news for standard plans: the Thank you and Order status extension targets are available on every plan except Shopify Starter (shopify.dev). So a non-Plus store can absolutely add custom content there — through an App Store app block or a small custom extension. A minimal UI extension registers against a target in its config:

# shopify.extension.toml
[[extensions.targeting]]
target = "purchase.thank-you.block.render"
module = "./src/ThankYou.jsx"

Our build-vs-buy rule from real client work: for a typical store, a well-reviewed App Store block beats a hand-built extension on both cost and maintenance. Reserve custom checkout UI extensions for genuinely bespoke post-purchase experiences (tailored cross-sells, account linking, loyalty enrollment) where an off-the-shelf block can't deliver the UX.

Migrating logic: Shopify Scripts to Functions (and the non-Plus trap)

If — and only if — you're on Plus, your Ruby Shopify Scripts are a separate, larger migration: they can no longer be edited as of April 15, 2026 and stop executing June 30, 2026 (Shopify Changelog). The replacement, Shopify Functions, is compiled WebAssembly, not a syntax swap — budget it as real engineering, not a port.

The trap that catches non-Plus merchants: custom apps that deploy your own Functions for discounts and checkout validation are Plus-gated. On a standard plan you can't ship a private Function — you achieve the same outcomes through a public App Store app. Scope accordingly before promising a client custom checkout logic on Basic or Advanced.

What has no equivalent (the honest caveats)

Some legacy behavior simply doesn't port, and saying so up front is what separates a trustworthy quote from a painful surprise:

• The new pages can't hide individual items within a bundle the way some legacy theming could.
• Deep checkout-step customization, the full Branding API, and B2B checkout remain Plus-only.
• A handful of niche script behaviors have no one-to-one replacement and need a rethink rather than a migration.

Set these expectations before you write the statement of work, not after.

The cutover runbook

This is the sequence we run, in order:

1. Rebuild on a development store. Never prototype the migration on the live store.
2. Recreate tracking as pixels and content as blocks/extensions, mirroring the audit's classification.
3. Keep the safety net in mind. A manual upgrade can be reverted within 30 days, but only on stores created before January 6, 2025 that had pre-existing customizations (Shopify Help Center). Once the automatic upgrade runs after the deadline, there is no revert.
4. Upgrade manually, before August 26, so you control the timing instead of being auto-upgraded mid-campaign.
5. Verify end to end: place a real test order and confirm Google Ads, Meta, and GA4 each receive the event with the right value and currency.

Post-migration verification: a falsifiable monthly test

Don't trust "it looks fine." Each month, compare GA4 purchase events to Shopify's order count:

• A modest, stable gap on a steady-volume store → expected consent-driven reduction. Leave it.
• A large or growing gap → a real break. Re-check the pixel subscription and consent configuration.

A concrete acceptance criterion beats a vibe, and it's the kind of check you can hand to a client to run themselves.

Adjacent migrations not to forget

While you're in here, two related deprecations travel with this one:

• Legacy customer accounts are deprecated (announced sunset in 2026) (shopify.dev changelog). The Order status experience now lives under the new customer-accounts surface, so plan both together rather than touching the same area twice.
• Order-status pixels need the right subdomain. Consent and cookies on the new accounts surface depend on serving customer accounts from an account.yourdomain.com subdomain — miss it and order-status tracking misbehaves.

What this realistically takes

Honest effort tiers, from what we see:

• Typical Basic/Advanced store: pixels plus an order-status app block — mostly configuration, low cost, doable in days.
• Mid-size store with custom upsells or affiliate logic: genuine development to rebuild each integration as a pixel or extension.
• Plus store still on Scripts: a separate, larger Scripts-to-Functions project on its own (earlier) clock.

DIY is sensible for the first tier. The moment custom logic, multiple integrations, or a portfolio of stores is involved, the math favors a team that has done it before.

How Keplaris ships this

We run this end to end: a full tag audit, version-current pixel and extension code, a development-store rebuild, the deliberate pre-deadline cutover, and the conversion-tracking verification that proves nothing went dark. It's the difference between "should I migrate?" and "it's migrated, tested, and your tracking is intact."

If the August 26 deadline is on your calendar and you'd rather hand it to a studio that builds Shopify checkouts for a living, take a look at our Shopify E-commerce service — and see what a clean, properly tracked checkout did for revenue in our Shopify commerce case study. Let's get you migrated well before the clock runs out.