Shopify Scripts stop executing on June 30, 2026, and every custom discount, shipping, or payment rule you built in the Script Editor stops applying on that date. The replacement is Shopify Functions, which run your logic server-side inside checkout. You have three ways to get there: hire a developer to write Functions, pay an agency to do it, or rebuild rule-based discount logic in a no-code Functions app. The urgent part is that the failure is silent. A Script that stops firing, or a migrated rule that does not match a cart, does not throw an error and does not notify you. It just quietly charges full price until a customer complains.
This guide explains what Scripts did, why Shopify is retiring them, what Functions actually are, why "migrating my Script" is really up to three separate migrations, the silent-failure trap and exactly how to test around it, what a no-code app can and cannot cover, and an honest breakdown of when you still need a developer.
What is happening to Shopify Scripts, and when?
Shopify Scripts are being sunset. According to Shopify's developer documentation, "Shopify Scripts will be sunset on June 30, 2026. All existing Shopify Scripts will stop functioning after this date." There are two dates that matter, and the first one has already passed:
- April 15, 2026: editing and publishing new Shopify Scripts is no longer possible. Per the Shopify developer changelog, after this date you cannot create or change a Script at all.
- June 30, 2026: all Shopify Scripts cease to execute entirely. Whatever discount, shipping, or payment logic lives in a Script simply stops running.
If your store still relied on a Script on July 1, 2026, that logic is already offline as you read this. The customizations did not error out or roll back to a safe default. They went quiet. That is the single most important thing to understand about this deadline: it is not a loud failure you will notice from a dashboard alert. It is an absence.
Shopify also ships a tool to help you scope the work. The Shopify Scripts customizations report helps you identify which of your current customizations can be transitioned to Functions or public apps. If you have not run it, that is step one.
IMAGE PLACEHOLDER (Image 1): The Scripts sunset timeline
Suggested visual: A clean 16:9 horizontal timeline on a white background with three milestone markers in violet and deep gold. Marker one, "April 15, 2026 - editing ends" in gold. Marker two, "June 30, 2026 - Scripts stop executing" in violet with a small red "silent" tag. A trailing arrow labeled "Shopify Functions" continues past the last marker. Flat, minimal, sans-serif labels, no photography.
What did Shopify Scripts do, and why is Shopify retiring them?
Shopify Scripts were small Ruby programs that ran in the Script Editor app and customized three parts of the buying flow: cart and line-item discounts, shipping rates, and payment methods. A merchant on Shopify Plus could write a Script that gave a tiered discount, hid a shipping option for certain addresses, or reordered payment methods at checkout. Scripts were powerful precisely because they were arbitrary code: if you could express it in Ruby, you could do it.
Shopify is replacing them with Shopify Functions. Per the migration documentation, "With Shopify Functions, these customizations are now handled through dedicated Function APIs that offer better performance and flexibility." Functions run on Shopify's own infrastructure inside the checkout pipeline, which makes them faster and more scalable than the older Scripts model, and it means the same logic applies whether a buyer checks out on the cart page, the checkout page, or an accelerated wallet like Shop Pay.
The tradeoff is that Functions are not a text box you paste Ruby into. They are developer artifacts: you scaffold them with the Shopify CLI, write the logic in Rust or JavaScript, define a GraphQL input query, and deploy them through an app. That shift, from "merchant writes a Script" to "developer ships a Function," is the whole reason this migration is a project and not a checkbox.
What are Shopify Functions, and why do they usually need a developer?
Shopify Functions let you extend or replace parts of Shopify's backend logic with custom code that runs during checkout. There are dedicated Function APIs for the things Scripts used to do, including a Discount Function API, a Delivery (shipping) Customization API, and a Payment Customization API.
Two properties of Functions matter for your migration plan.
Functions run server-side, once
A Function runs inside Shopify's checkout, not in your theme. That is a genuine upgrade over discount methods that calculate a total in theme JavaScript on the cart page and then disagree with what checkout charges. Because the Function is the single source of truth, the cart preview and the final charge are the same computation. This is also why a correctly built Function applies identically across Shop Pay, Apple Pay, and Google Pay, which skip the cart page entirely.
Functions are built, not configured, by default
Writing a Function from scratch is a developer task. You need the Shopify CLI, a language toolchain, and familiarity with the Function's input query and result shape. There is a nuance worth knowing on plan availability: according to Shopify's Functions availability documentation, "Stores on any plan can use public apps that are distributed through the Shopify App Store and contain functions. Only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs." In plain terms: a public app from the App Store can bring Functions to any plan, but a bespoke, custom-built Function is a Plus-only path. That distinction is what makes a no-code Functions app attractive to non-Plus merchants who used to lean on a developer.
The good news is that once a Function is deployed inside an app, the merchant configures it from the admin without touching code. As Shopify put it when Functions launched, "merchant end users never have to touch a line of code when modifying their customizations." The code is written once; the settings live in the admin.
Why is "migrating my Script" actually three separate migrations?
Here is the detail that surprises people, and it comes straight from how merchants describe the work on the Shopify community forums. A single Script file could touch discounts, shipping, and payment logic all at once. Functions deliberately split that into separate, independent Function types.
- Discount logic (tiered pricing, BOGO, order and product discounts, stacking rules) maps to the Discount Function API. Shopify's unified Discount Function API can apply savings across all three discount classes, product, order, and shipping, from a single function.
- Shipping and delivery logic (renaming, reordering, or hiding delivery options) maps to the Delivery Customization Function API, a completely separate function.
- Payment logic (renaming, reordering, or hiding payment methods) maps to the Payment Customization Function API, a third separate function.
So the sentence "I need to migrate my Script" often means migrating up to three different things, configured and deployed independently. A no-code discount app can rebuild the first bucket. It does not reach the shipping and payment buckets, which is exactly why you have to inventory your old Script before you assume any single tool covers it. Split the work by surface first, then choose a path for each surface.
IMAGE PLACEHOLDER (Image 2): One Script becomes three Functions
Suggested visual: A 16:9 diagram. On the left, a single labeled box "One Shopify Script (Ruby)" in slate. Three arrows fan out to the right to three separate boxes: "Discount Function" in violet, "Delivery Function" in gold, "Payment Function" in slate-blue, each with a small "deployed independently" caption. Clean flat vector, brand colors violet and gold, no photography.
The silent-failure danger, and how to test for it
This is the part that costs merchants real money, and it deserves its own section because it applies both to the deadline itself and to every rule you rebuild.
A Shopify Function is either well-formed and running, or it is misconfigured and silent. There is no visible in-between state. A Function whose conditions do not match a given cart does not fire, does not error, and does not alert you. That is by design: the same silence you get from a Function working correctly (it correctly did nothing for a cart that should not qualify) is the silence you get from a Function that is broken (a typo in a threshold, a rule scoped to the wrong collection, a tier that never triggers).
Merchants working through this migration describe the same experience on the Shopify community forums: a rule quietly stops applying a discount, and the merchant only finds out because a customer complains about being charged full price. No error, no alert, nothing in the order logs. The store had been running on a broken setup for weeks before anyone noticed.
The only reliable defense is to test both directions before you trust a rule live:
- Build a should-fire cart. Assemble a real cart that meets every condition of the rule, place a draft or test order, and read the checkout summary line by line. Confirm the exact discount you expect is present, at the amount you expect.
- Build a shouldn't-fire cart. Assemble a cart that deliberately does not qualify, for example one item below your quantity threshold, and confirm the discount correctly stays off.
A Function that fires when it should not is just as costly as one that silently never fires. You are not done testing until you have watched the rule both apply and correctly decline. Run the should-fire cart through Shop Pay too, so you confirm the accelerated path agrees with the standard checkout.
One more preservation step while you are here: keep your old Script source now. Once the Script Editor is fully retired, its stored code becomes unrecoverable from Shopify. Export or copy your Script source today, even if you are not ready to rebuild it yet, so you have a reference for whatever replaces it.
Can a no-code app migrate my Scripts? What it covers and what it does not
For the discount surface specifically, a no-code Functions app can absorb a large share of what merchants used Scripts for. If your Script logic reduces to rules, that is, "when the cart looks like X, apply discount Y", a configuration-driven app can usually rebuild it without a developer. That covers a lot of common ground:
- Tiered and volume discounts, such as "buy 3 or more, save 15 percent."
- Buy X Get Y and BOGO logic, including repeat tiers like "buy 6 get 2, buy 9 get 3."
- Explicit stacking and combination rules between offers.
- Scheduled start, end, and instant pause on a campaign.
What a no-code discount app cannot do is equally important to say plainly, because assuming otherwise is how migrations fail silently:
- Arbitrary custom code. If your Script ran a bespoke pricing formula or a one-off condition that does not reduce to a rule any builder exposes, no discount app can express it. That logic still needs a developer to write a custom Function.
- Shipping and payment customizations. Those are separate Function types (delivery and payment). A discount-only app does not reach them. A developer migrates those independently.
- Anything outside a rule-based discount configuration. If it was not fundamentally "conditions in, discount out," a configuration screen is the wrong shape for it.
The honest test is simple: write down, in one sentence, what each piece of your old Script did. If the sentence is a rule about discounts, a no-code app is a strong candidate. If it is a formula, a shipping change, a payment change, or something you cannot phrase as a rule, budget for a developer on that piece.
Run this migration reliably with Stackable
If your Script's discount logic was rule-based, tiers, BOGO, stacking, and scheduling, Stackable rebuilds exactly that surface on native Shopify Functions with no code, and it is honest about its edges.
- It rebuilds rule-based discount logic, including volume and tiered pricing, BOGO, explicit discount stacking, and scheduled start, end, and pause, as configuration you edit in the admin rather than Ruby you maintain.
- The math runs inside a Shopify Function, so cart, checkout, and Shop Pay compute one identical total. There is no theme-versus-checkout drift, which is a common failure mode of older discount setups.
- A cart simulator lets you run both a should-fire and a shouldn't-fire cart before you go live, so you catch a silent misconfiguration in a preview instead of in a customer complaint.
- It is honest about scope. Stackable does not run arbitrary custom code, and it does not touch shipping (delivery) or payment customizations. Genuinely bespoke logic and those two separate Function types still need a developer.
Install Stackable free and rebuild your rule-based discount logic on Functions before it silently costs you a sale at usestackable.com/pricing. 🚀
Worked example: a migration checklist you can follow today
Use this sequence to turn "my Script broke" into a controlled migration. The table maps a typical multi-purpose Script to its destinations.
Then work the steps in order:
1. Inventory the old Script before you build anything
Open the Script Editor while you still can and write one sentence per behavior. Run Shopify's Scripts customizations report to confirm nothing is hiding. Export the Ruby source and store it somewhere safe, because it becomes unrecoverable once the editor is retired.
2. Split the inventory by surface
Sort each behavior into discount, shipping, or payment. This tells you immediately which pieces a no-code discount app can take and which pieces need a developer. Do not assume one tool covers all three.
3. Rebuild the rule-based discount pieces without code
For every behavior that reduces to "conditions in, discount out," recreate it in native Shopify discounts or a Functions-based discount app. Set combination rules explicitly if offers are meant to stack.
4. Hand the non-rule pieces to a developer
Bespoke formulas, delivery customizations, and payment customizations go to a developer or agency to build as their own Functions. Give them your exported Script source as the specification.
5. Test every rebuilt rule both ways
For each rule, run a should-fire cart and a shouldn't-fire cart. Read the checkout summary line by line. A rule is not migrated until you have seen it both apply and correctly decline.
6. Verify the accelerated checkouts
Run your should-fire cart through Shop Pay. Because Functions compute server-side, a correctly built rule applies identically. This is your last check that nothing depends on theme code that wallets skip.
IMAGE PLACEHOLDER (Image 3): Test both directions before you trust it
Suggested visual: A 16:9 split illustration. Left panel labeled "Should-fire cart" shows a checkout summary with a green discount line correctly present. Right panel labeled "Shouldn't-fire cart" shows a checkout summary with the discount correctly absent and a green checkmark. A center caption reads "A silent rule never errors - test both." Brand colors violet and gold, flat vector, no photography.
The bottom line
- Shopify Scripts stop executing on June 30, 2026, and editing already ended on April 15, 2026. Any Script still in use is now offline.
- The failure is silent. A Script that stopped, or a migrated rule that does not match a cart, never errors and never alerts you. It just charges full price.
- Functions are the replacement, running server-side inside checkout, but writing one from scratch is a developer task, and custom Functions are a Plus-only path.
- One Script often becomes three migrations: discount, delivery, and payment Functions, each deployed independently.
- A no-code Functions app can rebuild rule-based discount logic (tiers, BOGO, stacking, scheduling). It cannot do arbitrary code, shipping, or payment customizations.
- Keep your old Script source now. It becomes unrecoverable once the Script Editor is retired.
- Test every rebuilt rule with a should-fire and a shouldn't-fire cart, and read the checkout summary line by line, including through Shop Pay.
Related articles
- Migrating off Shopify Scripts: the full rescue path, what rebuilds without code, and what still needs a developer.
- How discount stacking works in Shopify: why native applies only the highest discount, and how to combine offers correctly.
- Volume discounts and quantity breaks: rebuild tiered pricing that counts the same product, not the whole collection.
- Discount stacking, done right: the three per-class combine switches, with a live cart simulator.
- Shopify's 100-product limit on Buy X Get Y: run 3-for-2 across a full catalog after you migrate.
- Stackable pricing: plans, the free tier, and what each includes.
