If you still have Meta, TikTok, GA4 or any other tracking code firing from a script tag on your Shopify store, the window to migrate is closing. Shopify blocked new script tag creation on 1 October 2026. On 1 March 2027, it stops injecting any script tags into storefronts at all. The replacement, Web Pixels API, behaves differently enough that a lift-and-shift rarely works first time.

Where things stand right now (October 2026)

Your existing script tags still run. That is the trap. You can open your store, see pixels firing in the browser, decide this is a 2027 problem and move on. It is not.

Since 1 October 2026, the scriptTagCreate and scriptTagUpdate mutations return a user error, and the ScriptTag REST Admin API rejects POST and PUT. The scriptTags query and scriptTagDelete still work, which is useful for auditing but not for fixing anything. The deprecation applies to all API versions, so pinning an older one buys you nothing.

The practical effect: your tracking is frozen. If you need to change a Meta pixel ID, add a conversion event, swap in a fresh TikTok account or hotfix a broken parameter during BFCM, you cannot do it on a script tag. Any app that still relies on script tags for new installs is also broken, which is why Shopify now shows a dismissible banner when you install one.

That timing matters. 1 October landed roughly seven weeks before Black Friday 2026. The question is not "do I have until March" but "can I tolerate frozen tracking through the biggest sales period of the year".

The two-stage deprecation and why the gap is dangerous

Shopify split this into two dates deliberately. The five-month gap between them is where most stores will quietly break.

Stage one: creation is frozen

From 1 October 2026, you cannot create or update script tags via Admin API. Existing tags continue to run. Apps that were already installed and had already created their script tag still function. New installs of apps that use script tags fail at the tag creation step, which usually manifests as the app appearing to install correctly but no events firing.

The reinstall trap

If a merchant uninstalls and reinstalls an app that uses script tags after 1 October, the app cannot recreate the tag. The store loses tracking silently. There is no banner, no email, no error at checkout, just an empty events feed.

Stage two: injection stops on 1 March 2027

On 1 March 2027, Shopify stops injecting script tags into storefronts entirely. Every tag you have, working or not, goes dark on the same day. Any pixel, affiliate tracker, chat widget, A/B test tool or custom analytics installed via a script tag stops firing. If the migration is not complete by then, your attribution data pauses on 28 February and resumes whenever you finish the work.

Script tags stopped running on the Order Status page earlier for Plus stores (28 August 2025) and for everyone else this August (26 August 2026), alongside the removal of Additional Scripts, the Thank You page script field and the Order Status page script field from non-Plus plans. If your checkout tracking is already broken, that is why.

The two migration paths Shopify prescribes

Shopify's guidance treats this as a per-script decision rather than a per-app one. The rule is straightforward: if a script collects analytics or conversion data, it becomes a web pixel. Everything else becomes an app embed block in a theme app extension.

App embed blocks for non-analytics scripts

App embed blocks are the right home for anything that renders UI, modifies the DOM or needs to run in the storefront's main execution context. Chat widgets, review displays, pop-up builders, personalisation overlays, A/B test runners and loyalty widgets all belong here. The merchant toggles them on in the theme editor, which gives them a visible switch rather than a hidden script injection.

Web Pixels API for tracking and conversion data

Anything whose only job is to send events to an analytics or ad platform becomes a web pixel. Meta, TikTok, Pinterest, GA4, Klaviyo tracking and custom conversion scripts all go here. Shopify emits a typed event stream (page_viewed, product_viewed, product_added_to_cart, checkout_started, checkout_completed and so on) and your pixel subscribes to the ones it needs.

The split between app pixels and custom pixels matters for who does the work. App pixels, shipped by a developer via a web pixel extension, update automatically for merchants. Custom pixels, created in Settings → Customer events, are the merchant's responsibility to write, test and maintain. If your Meta pixel came from the official Meta Shopify app, the developer handles the migration. If someone on your team pasted the Meta base code into theme.liquid three years ago, that is now a custom pixel you need to build yourself.

What the sandbox actually restricts

Web pixels do not run where your old script tags ran. They execute inside a sandboxed iframe (a lax sandbox for custom pixels, with allow-scripts and allow-forms), and that sandbox is deliberately restrictive.

Two restrictions catch teams out:

  • No DOM access. Any script that scraped the page for product metadata, read hidden form fields, pulled values from the shopping cart drawer or wrote tracking elements into the page will not work. The sandbox cannot see the parent document.
  • Limited event payloads. The checkout_completed event ships a defined set of order and customer fields. Anything beyond that, such as customer lifetime order count, first-order flag, custom line item properties or subscription versus one-off purchase type, is not in the payload by default. Teams migrating from checkout.liquid scripts routinely discover their tracking depended on enriched fields the sandbox does not provide.

Diagram comparing script tag unconditional firing model with the consent-gated Web Pixels API sandbox model

The browser methods you do get (analytics.subscribe(), plus browser for cookie, localStorage and sessionStorage access that executes asynchronously in the top frame, and init for a page snapshot at render) cover standard pixel work. They do not cover the edge cases that were previously "just read it off the page".

GTM and the missing data layer

Shopify has no native dataLayer. This is the single most common surprise for teams coming from Magento, WooCommerce or any bespoke stack where GTM read ecommerce events from a global object. You can import your GTM container into a Shopify custom pixel and the container initialises correctly, but your triggers never fire because the dataLayer they listen for does not exist.

The bridge pattern looks like this inside a custom pixel:

javascript
analytics.subscribe("checkout_completed", (event) => {  window.dataLayer = window.dataLayer || [];  window.dataLayer.push({    event: "purchase",    ecommerce: {      transaction_id: event.data.checkout.order.id,      value: event.data.checkout.totalPrice.amount,      currency: event.data.checkout.currencyCode,      items: event.data.checkout.lineItems.map((item) => ({        item_id: item.variant.product.id,        item_name: item.title,        price: item.variant.price.amount,        quantity: item.quantity,      })),    },  });});

You subscribe to each Shopify event you care about and push a GTM-shaped object. Your existing tags inside the container then fire as they did before. It is more work than a lift-and-shift, but it preserves your tag library.

Get plain-English guides like this in your inbox.

One short email a month. WordPress, Shopify, SEO, no fluff. Unsubscribe in one click.

We never share your email.

This is the detail that quietly tanks reported conversion volume, and it is almost absent from Shopify's own migration docs.

A script tag fired on page load without asking permission. If your legal setup was correct, your consent management platform blocked the script until consent was granted, but the firing mechanism itself was unconditional. A web pixel is different: it fires when Shopify's pixel manager decides a visitor's consent state permits it. That condition is now owned by Shopify's consent framework, which reads from the customer privacy API.

For stores serving EU, UK or Californian traffic, tags that previously fired for 100% of visitors now fire for whatever share of visitors grant consent. If your consent banner has a low opt-in rate, your pixel volume will fall after migration. The pixel is not broken. Your tracking just became compliant in a way it may not have been before.

Two things to do before you migrate:

  • Check your consent mode configuration against the customer privacy API, not against the banner widget alone.
  • Reconcile against orders in Shopify admin after launch, not against pre-migration pixel volume. The orders are the ground truth; pixel volume is the view through the consent filter.

Server-side tracking as a complementary layer

Web pixels run in the browser, which means ad blockers, Safari ITP and the growing share of users on privacy-first browsers will suppress a portion of your events regardless of consent. The way to recover that signal is server-side forwarding: read the order from Shopify's server via the Order webhook and send it to Meta's Conversions API, TikTok's Events API and Google Ads Enhanced Conversions directly.

Deduplication is the critical detail. When the browser pixel and the server-side event both report the same purchase, both need to carry the same event_id so the destination merges them rather than counting twice. We cover the pattern in detail in fixing conversion tracking with server-side GA4, and the same approach applies to Meta and TikTok.

Server-side is not a replacement for Web Pixels. It is the second layer that catches what the browser loses. Treat them as a pair.

Your migration checklist before March 2027

Seven-step migration checklist on a clipboard with completed upper steps checked in green and a March 2027 deadline calendar looming behind it

A pragmatic order of operations, assuming you are reading this after 1 October 2026 with script tags still live:

  1. Audit. Run the scriptTags GraphQL query against your store. List every tag, which app or human created it, and what it does. Split into "collects data only" (becomes a pixel) and "does something in the storefront" (becomes an app embed block).
  2. Separate app pixels from custom pixels. For every entry that came from an app, check the app listing for a Web Pixels update. Most major apps (Meta, TikTok, Pinterest, Klaviyo, Google) have shipped one. If so, install the updated version and remove any manually pasted code.
  3. Rebuild manual tracking as custom pixels. For anything pasted into theme.liquid, checkout.liquid or Additional Scripts, create a custom pixel in Settings → Customer events, subscribe to the right customer events and send to your destinations.
  4. Rebuild your GTM data layer inside a custom pixel if GTM is central to your stack. Do not try to make your old container work without the bridge.
  5. Validate consent behaviour. Open the pixel debugger with consent granted and denied. Confirm firing matches expectation in both states. Expect lower reported volume post-launch.
  6. Add server-side forwarding for your top two or three paid channels before BFCM.
  7. Delete the old script tags with scriptTagDelete once replacements are confirmed working. Do not leave zombies in place.

The BFCM question

If you are not confident you can complete steps one through six before Black Friday, prioritise your highest-revenue channel first. One working pixel on Meta is more valuable than three half-migrated pixels across Meta, TikTok and Google.

This migration looks like a developer ticket until the attribution data arrives in your reporting dashboard. It is actually a joint piece of work between whoever owns Shopify and e-commerce development on your side and whoever owns paid media, because the trade-offs are commercial as much as technical. If you also run complex catalogues or wholesale alongside DTC, the same custom pixel work interacts with how you handle B2B and trade pricing on Shopify, and if you are weighing a replatform entirely, our comparison of Shopify Plus vs WooCommerce for high-volume stores is a useful companion read.

The brands that get through 1 March 2027 cleanly will be the ones that treated October as the real deadline and used the five-month gap to validate, not to procrastinate. If you want a second pair of eyes on where your tracking stands, see how we've approached complex Shopify builds and get in touch.