Shopify Scripts stopped running on June 30, 2026, and the window to edit them closed earlier on April 15. Any discount, shipping, or payment logic you built on Scripts is now off, so the job today is finding what broke and standing up replacements.
Shopify Scripts stopped running on June 30, 2026, and the editing window closed back on April 15. If a discount, shipping rule, or payment option quietly changed at your checkout, a dead Script is the first place to look. This is the recovery guide.
What to do now that Shopify Scripts are off: check your checkout for logic that silently changed (discounts that no longer apply, shipping rules that vanished, payment methods that reappeared), then replace each dead Script with a no-code app, Shopify's native discount system, or a custom Function. Fix revenue-critical pricing first. The editing window closed April 15 and Scripts stopped executing June 30, so there is nothing left to modify, only to replace.
A merchant I know found out the hard way. A customer emailed saying their bulk discount wasn't applying at checkout. No error message. No warning in the Shopify admin. Just a discount that had silently stopped working.
They spent an hour troubleshooting before realizing what had happened: their Line Item Script, the Ruby code that had powered a tiered discount for three years, was gone. Not broken. Gone. June 30 had come and Shopify had pulled the plug.
That story isn't hypothetical, and it's no longer a warning about something coming. It's what a lot of Shopify Plus merchants are quietly living with right now, plenty of them without knowing it yet. The reassuring part: the fixes are the same whether you migrated ahead of the deadline or you're reading this after your checkout already changed.
Here's what Shopify Scripts were, why Shopify retired them, how to tell if one silently stopped on your store, and the step-by-step process to stand replacements back up.
Scripts stopped running June 30, 2026, and the window to edit them closed earlier on April 15. Shopify pushed this deadline twice and did not move it again.
Shopify Functions are the replacement. They run as WebAssembly under a hard 5ms execution cap, work on every Shopify plan, and cover the common logic (tiered discounts, BOGO, free shipping thresholds) through no-code apps, no developer required.
Start with your Scripts Customizations Report (Apps, then Script Editor). It maps every live Script in your store to a specific replacement app or Function.
The risk isn't the migration, it's the edge cases. Discount combinations, payment routing, and B2B pricing rules break silently if you don't test every cart scenario before switching a Script off.
Shopify announced the Scripts deprecation in 2024, with a June 2025 original deadline that was pushed back twice. The final timeline had two distinct dates that mattered, and as of July 1, 2026 both are behind us:
April 15, 2026: Shopify disabled the ability to create or edit Scripts in the Script Editor. From that point, any Script that was live stayed running but frozen. No fixing a bug, no adjusting a discount threshold, no tweaking a shipping rule. What was there was what you were stuck with.
June 30, 2026: All Scripts stopped executing. Completely. Discounts no longer apply, shipping rules no longer fire, payment gateway logic no longer runs. Since July 1, customers have been hitting your checkout without any of the customization you built over the years.
The Scripts that were live kept running right up to June 30. After that they stopped, and once editing locked in April there was never a way to patch them.
It was fair to ask, right up to the end, why anyone should trust this date when the last two moved. The original deadline was 2024, then it slid to August 2025, then to June 30, 2026 (shopify.dev changelog, Scripts deprecation). This time it held. The editing window closed in April as promised, the replacement platform was mature and shipping new APIs, and Shopify did exactly what it said. The stores that bet on one more reprieve are the ones now scrambling.
Scripts are small pieces of Ruby code that run in the background during checkout. They were introduced as a Shopify Plus-only feature and gave merchants a way to build custom checkout logic that wasn't possible through Shopify's standard discount and shipping settings.
There are three types. It's worth knowing which ones you're using because the migration path differs by type. If you want the plain-English primer first, start with what Shopify Scripts are and why their end matters.
Control pricing and discounts on individual cart items. Common uses: tiered pricing (buy 3, save 10%), BOGO deals, customer-tag-based discounts, bundle pricing.
Control which shipping methods appear and what they cost. Common uses: free shipping thresholds by product type, hiding carrier options, discounted shipping for loyalty customers.
Rename, reorder, or hide payment methods at checkout. Common uses: hiding certain payment options for specific countries, reordering gateways by preference, showing/hiding based on cart size.
One clarifying point on who this hits: Scripts were always a Shopify Plus feature. If you're on a standard plan, this deadline doesn't touch you directly, your checkout customization is already app-based. The exposed stores are on Plus, and the longer you've been there, the more likely a developer once wired something into a Script you've since forgotten about. That's why the audit below matters more than your memory does.
If you're not sure which types you have, jump to the audit section below before reading further. Knowing what you're working with changes everything about how you approach this.
This is the work I do with clients. Early Shopify employee, DTC co-founder, software exit, the ecosystem from all three angles. The form takes two minutes.
Shopify Functions are the new infrastructure for checkout customization. They've been in development since 2022 and are now mature enough that Shopify is comfortable making the hard cut.
The key difference for merchants: Functions run faster, work on all Shopify plans (not just Plus), and are available through apps in the Shopify App Store (the builder side of that shift is mapped in the checkout extensibility and Functions opportunity post), meaning most merchants won't need a developer at all.
The performance gap is more meaningful than it sounds. Scripts ran Ruby on Shopify's servers, with cold start overhead and variable latency that got worse under load, Black Friday was notoriously rough for stores with complex Scripts. Functions compile to WebAssembly and run in under 5ms, every time. Shopify enforces that as a hard execution budget. There's no cold start, no CPU throttling during a flash sale, no latency spike when thousands of carts hit checkout simultaneously. If your Scripts were occasionally causing checkout slowdowns, this is the fix.
The reach is also different. Scripts were locked to three surfaces: line items, shipping, and payments. Functions go further, cart and checkout validation (block checkout with a custom error when business rules aren't met), order routing to control which fulfillment location ships what, and a growing list of extension points Shopify has been shipping quarterly since 2022. A merchant running complex wholesale rules or multi-location fulfillment will find more to work with in Functions than Scripts ever offered.
On the developer side: Functions are written in JavaScript, TypeScript, or Rust, not Ruby. Shopify CLI handles compilation via its own JavaScript-to-WebAssembly toolchain (Javy), so the development experience is closer to what most Shopify developers already know. For most merchants, though, none of that matters directly. No-code apps built on Functions handle the common patterns, tiered discounts, BOGO, free shipping thresholds, payment method visibility, without anyone writing a line of code.
One note on method, because it changed the moment Scripts went off. Before June 30, the safe play was to run the Function-based replacement alongside the live Script and confirm the numbers matched before retiring the old one. That overlap is gone now, there is no live Script left to compare against. So validate replacements against your recent order history and a full set of test carts instead, which the QA section below walks through. It's a little more work than a side-by-side, and it's why the edge cases deserve real attention rather than a happy-path glance.
Any Shopify store can install a public app from the App Store that uses Functions under the hood, that's how most no-code migrations work. Only Shopify Plus merchants can deploy custom (private) Functions: proprietary logic built specifically for your store via the Functions API. If you're on a standard plan, the no-code app path is your only route for custom checkout logic. If the Scripts deadline is prompting you to think about upgrading, here's the full framework for whether Plus is actually worth it at your revenue stage.
Here's the part that explains why Shopify is willing to make a hard cut. Functions don't run Ruby on a server the way Scripts did. They compile to WebAssembly and execute inside a sandbox with two hard limits: under 5 milliseconds per run, and at most 11 million WebAssembly instructions. Go over either budget and Shopify aborts the Function and ignores its output (shopify.dev, About Shopify Functions).
That sounds restrictive. It's the whole point. Because every Function is guaranteed to finish in single-digit milliseconds, Shopify can run your custom logic inside the live checkout path without risking the page stalls that abandon carts. Scripts carried no such guarantee. Under Black Friday load, a complex Script could add latency at the exact moment your checkout could least afford it.
The performance is not theoretical. When the team behind Discount Kit moved onto the newer WebAssembly discount API, a typical run dropped roughly 30%, from about 610,000 instructions to 430,000 at the 75th percentile, and a single discount code can now trigger multiple effects with up to 25 discount Functions running at once (Shopify Partners, Discount Kit case study, 2025).
For most merchants, none of this is something you touch directly. The no-code apps that replace your Scripts are already engineered to stay inside the budget. But it reframes what's happening here: Shopify isn't deprecating a feature to make your life harder. They're moving checkout customization off a system that was never safe to run at their scale and onto one that is.
There's an upside hiding in the cut. Scripts only ever reached three surfaces: line items, shipping, and payments. Functions reach further. You can validate the cart and block checkout with a custom message when a business rule isn't met, customize delivery and pickup options, route orders to specific fulfillment locations, and adjust payment presentation, none of which Scripts could do. Shopify has been shipping new Function APIs on a steady cadence since 2022, so this isn't a like-for-like swap that quietly costs you capability. For most stores it's a net gain in what checkout can do.
The cruel part of this deadline is that nothing announces itself. When a Script stops, checkout still loads, orders still go through, and the Shopify admin shows no error. The only signal is that carts start behaving like the customization was never there. So before you replace anything, confirm what actually broke.
Since July 1, these are the symptoms that point straight at a dead Script rather than a bug somewhere else:
Discounts: a tiered, BOGO, bundle, or customer-tag discount no longer applies at checkout, or the cart total is suddenly higher than it should be for a qualifying order. Customer emails about "the discount isn't working" are the classic first flag.
Shipping: a free-shipping threshold stopped kicking in, a carrier option you used to hide is showing again, or a loyalty shipping rate reverted to full price.
Payments: a payment method you deliberately hid is back on the checkout, gateways are in the wrong order, or an option is appearing for a country or cart size it shouldn't.
B2B and wholesale: a logged-in wholesale buyer sees retail pricing, negotiated tiers are gone, or invoice/net-terms options a customer relied on have disappeared. This one is the most expensive to miss and the least visible.
The fastest confirmation is to place a test order for each scenario a Script used to handle, or pull a handful of orders placed since July 1 and compare what customers paid against what the Script would have charged. If the numbers diverge in exactly the way the Script used to correct, you've found your gap. Prioritize by money: anything that changes what a customer pays gets fixed first, cosmetic payment ordering can wait.
Now map what you had, so you know the full list rather than only the pieces customers happened to complain about. A surprising number of merchants discover Scripts they forgot about, set up years ago by a developer and quietly running until June 30.
In your Shopify admin, go to Apps > Script Editor. If you see the "Replace your Shopify Scripts" banner, click it. This opens your personalized Shopify Scripts Customizations Report, a generated page that lists every Script that was live in your store, organized by type, with recommended replacement apps for each one. The report stays available after the deadline precisely so you can still see what you need to rebuild.
You can also navigate directly to Settings > Checkout > Scripts and export the report as a CSV.
The Customizations Report is worth spending 10 minutes in. Shopify has done the work of mapping your specific Scripts to the apps and Functions APIs that can replace them. It's not a generic list, it's tailored to what's actually running in your store.
What you're looking for in the audit: which Script types you were running (Line Item, Shipping, Payment), what each one did, and whether it was business-critical or vestigial. Some merchants find Scripts that hadn't been relevant in two years, which is a gap you can simply close and move on from. Others find their entire discount strategy was sitting in one Script file, which is now the top of your fix list.
Write it down as you go. For each Script, capture three things: what it does in one plain sentence, which carts or customers it affects, and whether anything downstream depends on its output. That short inventory is exactly what you'll hand to an app's setup screen or a developer's brief, and it's what turns a vague sense of dread into a checklist you can actually close out.
Once you know what Scripts you're running, the migration decision is actually pretty simple. There are three ways to go, and which one fits depends on what you're replacing and how complex it is.
For the most common Script use cases (tiered discounts, BOGO, free shipping thresholds, hiding or reordering payment methods) there's a no-code app that handles it. These apps are built on Shopify Functions under the hood, so they're Shopify-approved replacements, not workarounds.
Custom discount, shipping, and payment rules without code. Good general-purpose replacement for most Line Item and Shipping Scripts.
No-code interface for discount, payment, delivery, and validation Functions. Strong for merchants with multiple active Scripts.
Campaign builder for custom discounts, bundles, and shipping rules. Good for promotional logic that changes frequently.
Focused on the most common discount Script patterns. Well-suited for gift-with-purchase and tiered discount logic.
Your Scripts Customizations Report will surface apps specific to what's running in your store, so use that as your primary source. The apps above are a starting point, not an exhaustive list.
Some Scripts were built to handle genuinely custom logic, deep integrations with third-party systems, unusual pricing structures, logic that's tightly coupled to your business rules. A no-code app won't recreate that.
For those cases, a Shopify developer can build custom Functions using Shopify's Functions API. The developer experience is different from Scripts (WebAssembly instead of Ruby), so make sure whoever you hire is familiar with the current Functions platform specifically, not just Shopify development generally.
Here's the one upside of reading this after the deadline: the calendar pressure is off. There is no cutoff left to beat, so you don't have to force a rushed custom build. The right sequence is to put a no-code stand-in live immediately for anything revenue-critical, so customers pay the correct price today, then scope the proper custom Function rebuild as a deliberate 2 to 4 week engagement rather than a scramble. A Functions-fluent developer is worth waiting a couple of weeks for if the alternative is a fragile rush job on logic your business depends on.
Many stores with 3 or more active Scripts will find that some can go to no-code apps, one or two need custom development, and a couple are actually unused and can be retired. Map your Scripts against all three outcomes before you commit to any one path.
A real shape this takes: a Plus apparel store I looked at had five Scripts. Two were standard, a tiered loyalty discount and a free-shipping-over-$75 rule, and both went straight to a no-code app. One hid a payment method for international carts, also an app. One was a wholesale price override tied to customer tags, and that needed a custom Function. The last, a flash-sale Script left over from a 2023 promotion, had been dormant for more than a year and was simply retired. Five Scripts became one app subscription, one small dev engagement, and one deletion. That distribution is typical.
For most merchants, the honest answer is: the price of an app subscription and an afternoon of testing. The panic around this deadline makes it feel like a budget event. For standard Script logic, it isn't.
This is where most stores land. Functions-based discount, shipping, and payment apps typically run somewhere in the range of $10 to $50 a month, and several cover basic rules on a free tier. If your Scripts did the usual things, your all-in cost is that subscription plus the time to re-enter your thresholds and test checkout. No invoice from a developer at all.
If you need proprietary logic rebuilt, a developer fluent in the Functions API is the cost, and it's rarely the build itself. With the deadline behind you, the calendar is no longer the enemy: you can book the right developer for a proper 2 to 4 week engagement instead of paying a premium for a rush. Your immediate move is a no-code stand-in to keep checkout correct today, with the bespoke work scheduled deliberately after.
Stores with several Scripts usually split the work: some go to apps, one or two need a developer, and a couple turn out to be unused and get retired. Every Script you retire instead of replace is cost avoided outright. Map all three outcomes before you spend a dollar.
Map one app to one job straight from your Customizations Report, then stop. The common over-spend here is panic-installing three overlapping apps that each do part of what one would handle. If you're rethinking your whole stack while you're in here, here's what actually belongs in a Shopify stack at each revenue tier.
The one cost nobody budgets for is doing nothing. If Scripts powered your pricing, they've already switched off, and every promotion and tiered price has reverted to default. The downside isn't a $30 app, it's the revenue you lose selling at the wrong price for every day the gap stays open.
Most Scripts map to a Function one for one. A handful don't, and those are exactly where complex stores get hurt. Know which of these apply to you before you assume an app has you covered.
Line item and shipping Scripts that read the discount applied to a cart leaned on a method that only ever returned a single discount code. Shopify's newer discount model handles combinable, stackable discounts differently, so any logic that branched on "which code is applied" may not translate directly (Shopify Help Center, Scripts limitations). If customers can stack a code on top of an automatic discount, test that exact cart before you trust the replacement.
Scripts often guarded commercial rules that never showed up on the storefront: negotiated price tiers, net payment terms, account approvals, restricted products, fulfillment limits. Now that this logic has dropped, checkout still loads, but the wrong buyer can see the wrong price or a payment method they were never supposed to have. In B2B that isn't cosmetic, it's a contract problem. The buyer expecting invoice terms and their negotiated tier needs to see exactly that today, and if a Script was guarding it, that protection is already gone. Rebuild these first.
If you run subscription logic or market-specific pricing through Scripts, confirm the replacement respects the subscription contract and the presentment currency, not just the base price. A discount interacting with a subscription's billing cycle, or a promotion that should fire in one market only, is the kind of thing a quick happy-path test sails right past.
The simpler the Script, the cleaner the swap. The more it encoded rules unique to your business, the more this is a build, not an install.
Across the migrations I've watched, the failures cluster, and the two biggest now are the same: assuming nothing broke because checkout still loads, and skipping QA on the edge cases (Shopify Help Center, Transitioning to Functions). Here's the full list, in the order they tend to bite.
A dead Script throws no error. The page renders, orders process, the admin looks fine, and the only tell is that carts price and ship as if the customization never existed. Don't wait for a customer to email you. Place test orders for every scenario a Script used to handle, and check recent orders against what should have been charged.
Payment and shipping logic has to be checked across every combination: domestic under your threshold, domestic over it, international, and mixed carts. Miss one and you can show a payment method to a customer who should never see it. Shoppers try combinations you never planned for.
Apps replace the common pattern, not your exact configuration. Re-enter your thresholds, customer tags, and rules by hand and confirm each one. Don't assume the app's defaults match what your Script was quietly doing three years ago.
If any Script needs custom Function work, the bottleneck is the calendar, not the code. With the deadline already passed, the play is a no-code stand-in live now to keep checkout correct, and the custom rebuild booked as a proper engagement rather than left as an open wound on your pricing. If you line up a developer, brief them off your Customizations Report so no time is lost on scoping.
Some Scripts tagged orders, routed fulfillment, or set values that fed your 3PL, ERP, or email flows. Map what consumed each Script's output, not just the Script itself, or you'll fix checkout and quietly break a report or a shipping rule nobody notices until it's wrong.
The deadline has passed, so this isn't a countdown anymore, it's a cleanup. The steps below work whether your checkout is visibly broken or you just want to confirm nothing slipped through. Protect revenue-critical logic first, then work down to the cosmetic.
Open the Customizations Report at Apps > Script Editor and export the CSV. Then place a test order for each scenario your Scripts handled to see what's actually broken. Money-affecting gaps first.
For each Script, ask two questions: was it business-critical, and was the logic standard or custom? High-impact standard logic → app. High-impact custom → dev. Low-impact → leave it retired.
Start with the recommended apps in your report. Test on staging, then push live. Run checkout through every scenario the old Script handled, and confirm the numbers before you call it fixed.
If a Script needs custom Function development, put the closest no-code stand-in live now to keep checkout correct. With no deadline left to beat, book the proper rebuild as a deliberate engagement, not a rush.
Check the edge cases before you sign off: unusual discount logic, shipping rules that behave differently in production, payment ordering quirks, B2B pricing. Real checkout, real products, every combination.
If discounts or pricing are already firing wrong, triage hard. Replace your revenue-critical logic first, the discounts and pricing that directly change what customers pay, even if that means a rougher no-code stand-in you refine later. A live checkout charging the right prices today beats a perfect rebuild that ships next month. Shipping tweaks and payment-display polish can follow. What you cannot do is leave pricing logic dark while the wrong totals keep going out the door.
June 30, 2026 was the hard cutoff, and the window to edit Scripts closed earlier on April 15. Shopify extended this deadline twice, first from 2024, then from August 2025, and it did not move again. Any Script that was live has now stopped executing, so its discount, shipping, or payment logic no longer runs at checkout.
Usually not. Functions run on every Shopify plan through no-code apps that cover the common patterns: tiered discounts, BOGO, free shipping thresholds, and payment-method visibility. Only proprietary or deeply custom logic needs a developer building directly on the Functions API.
They're separate systems. Checkout extensibility, the checkout.liquid and additional-scripts sunset, hit Plus stores on August 28, 2025, with non-Plus stores due August 26, 2026. Shopify Scripts are a different feature that stops on June 30, 2026. Many stores need to handle both.
Measurably. Functions compile to WebAssembly and run under a hard 5ms cap and an 11 million instruction budget, with no cold starts. One migrated app cut its instruction count by about 30%. Scripts ran Ruby server-side with variable latency that got worse under peak load.
That's the real risk area. Line item and shipping Scripts that read a single applied discount code don't map cleanly to combinable discounts, and B2B rules like negotiated pricing and payment terms need careful rebuilding. Test stacked-discount and wholesale carts before you disable anything.
Scripts were always a stopgap. Ruby code running in a sandboxed environment on Shopify's servers, doing things the platform was never built to handle at the volume merchants were pushing it to. The fact that it worked as well as it did, for as long as it did, is genuinely impressive. But Shopify was always going to replace it with something native to how checkout actually runs at scale.
Functions are that replacement, not a better workaround, actual infrastructure. If you migrate well, your checkout gets faster, your discount and shipping logic becomes easier to modify without calling in a developer, and you're building on a platform Shopify is actively investing in. If you haven't migrated, your checkout is already running without the logic you built, and it stays that way until you replace what stopped. That's the whole equation.
One thing worth noting for anyone who's been in the Shopify ecosystem long enough: the extension points for Functions are still growing. Cart and checkout validation, order routing, fulfillment location rules, none of that existed with Scripts. Merchants who make this transition now are moving onto a platform that will keep getting more capable, not less.
If there's one mindset shift to carry out of this, it's that platform deadlines like this one aren't interruptions to the work, they are the work. The Shopify ecosystem rewards merchants who move with the platform's direction and quietly taxes the ones who build against it. Scripts to Functions is this year's version of that lesson. The next one is already on its way, and the stores that treat migrations as routine maintenance spend far less time firefighting than the ones who wait for a customer email to tell them something broke.
Your Customizations Report: Shopify Admin → Apps → Script Editor → Replace Shopify Scripts
Shopify's official migration guide: help.shopify.com, Transitioning from Scripts to Functions ↗
Functions API docs (for developers): shopify.dev, Migrating from Shopify Scripts ↗
I've helped Shopify merchants navigate platform transitions like this for over a decade, from the early days of the partner ecosystem to today's Functions cut-over. If your Scripts situation is complex, or you want a second opinion before you commit to a migration path, I'm happy to take a look.