Checkout extensibility migration
Move off Additional Scripts without losing your conversion tracking.
Shopify turned off Additional Scripts for non-Plus stores on 26 August 2026 and retires Ruby Scripts on 30 June 2026. Each script is mapped to its replacement, whether that is a Web Pixel, a UI extension or a Function, then order reporting is checked end to end.
Project pricing
Quoted from the scope, with the estimate broken down by part.
Send the brief and get a number back.
Describe the projectThe deadline has passed and the tracking is already wrong
Additional Scripts stopped running on non-Plus stores on 26 August 2026, and Shopify Scripts on Ruby retire on 30 June 2026. Nothing on the storefront breaks visibly when this happens, which is the problem. Orders keep coming in, the thank-you page still loads, and the only signal is that Google Ads, Meta and your affiliate network quietly stop agreeing with your Shopify reports. By the time somebody notices, the bidding algorithms have been optimising against incomplete data for weeks.
What the migration covers
An inventory of what was in there
Every script in the field is read and classified: analytics, ad pixels, affiliate postbacks, subscription logic, custom fields. Some have an obvious replacement, some are dead code from an app removed years ago, and knowing which is which is most of the work.
The replacement, per script
Each surviving script moves to where the platform now expects it: a Web Pixel extension for tracking, a checkout UI extension for interface changes, a Function for discount and delivery logic, or a server-side event when the browser cannot be trusted with it.
Proof that the numbers came back
A real test order is placed and followed all the way through: the conversion in Google Ads, one non-duplicated purchase event in Meta, the sale in the affiliate dashboard. Checkout runs in a sandbox now, so the old browser debugging tricks do not attach and this has to be verified at the destination.
Why it is done this way
Mapping, not lifting and shifting
Pasting old JavaScript into a pixel extension does not work: the sandbox has a different data model, a different event timing and no access to the DOM. Every script has to be rewritten against the checkout events that exist now, and the Liquid variables it used have to be remapped to their equivalents in the new payload.
Verified at the destination, not at the source
A pixel that fires is not a conversion that arrives. Duplicate purchase events, missing order values and currency mismatches all look fine from the store side and wrong in the ad account. The deliverable here is the confirmation in the receiving system, which is the only place the answer actually lives.
How it runs
You send the contents of the Additional Scripts field, or grant access so it can be read directly. A free audit tool on this site gives you the first read in a browser if you would rather look yourself.
You get a written per-script plan: what it did, what replaces it, what cannot be replaced and what that costs you.
The replacements are built on a development store or a duplicated theme, so nothing changes on the live store while the work happens.
Test orders are placed and each destination system is checked for the event, in the right currency, exactly once.
The change goes live, then the same checks run again against real traffic for a few days.
Background
What actually changed in the Shopify checkout
From one text field to an extension model
For years the Additional Scripts field was where everything went: analytics, pixels, affiliate tags, small interface tweaks. It ran as raw JavaScript on the order status page with access to Liquid variables and the DOM. Checkout Extensibility replaces that with a sandboxed model where each concern has its own place: Web Pixels for tracking, UI extensions for the interface, Functions for logic. The upside is that checkout cannot be broken by a third-party script any more. The cost is that everything written for the old model has to be rebuilt rather than moved.
Why the failure is silent
When Additional Scripts stopped running there was no error, no warning banner and no visible change on the storefront. Orders continued as normal. The only symptom was in systems outside Shopify: fewer conversions in Google Ads, missing purchase events in Meta, unattributed sales in affiliate dashboards. Smart Bidding and similar algorithms keep spending against whatever data they receive, so a tracking gap turns into wasted budget long before anyone links the two.
The parts that are easy to get wrong
Three failures repeat across stores. Purchase events fired twice, because both the app and a hand-written pixel report the same order. Order value reported as zero, because the field holding revenue was never mapped in the new payload. Currency mismatches on multi-market stores, where the checkout reports in the presentment currency and the ad platform expects the shop currency. All three look fine from inside Shopify, which is why verification has to happen in the receiving system.
What a migration should leave behind
You get working tracking and a written record of it: which script did what, what replaced it, which ones were dropped and why. Most stores accumulated that field over years and several agencies, and nobody remaining knows what half of it was for. Writing it down is what stops the same audit being paid for again in two years.
Related services
Describe the project
Tell us what you have and what should change. You get a scope and a price back, not a discovery call.
Questions
Checkout migration, asked and answered
No. The scripts have stopped running, so the loss is ongoing rather than upcoming, but nothing was deleted. The field can still be read and every script still has a replacement path.
Often yes, and where an app covers your case you will be told so rather than sold a build. Apps handle the standard analytics and pixel cases well. What they do not cover is custom logic, affiliate postbacks with your own parameters and anything that read a variable specific to your store.
Past data stays as it is. What changes is that events start arriving again from the day the replacement goes live. Where events were missing for a period, that gap stays visible in the ad platform and is worth annotating so nobody reads it as a performance drop.
Those retire on 30 June 2026 and move to Shopify Functions, which is a different job from pixel migration: discount, shipping and payment logic rewritten in the platform runtime with an admin interface to configure it. It is often the same project, so both get scoped together.
A store with a handful of standard scripts is usually days. Stores with subscription logic, several affiliate networks or bespoke checkout behaviour take longer, and the estimate comes with the audit rather than before it.