Shopify stopped running Scripts on 30 June 2026. If your checkout stopped applying a discount, shipping rule or payment rule on 1 July, a script was doing that job. It now needs a replacement, or a decision to drop it.
This article is for:
- Shopify Plus teams that had custom Scripts for discounts, shipping or payment rules
- Technical leads deciding between a public app and custom Functions
- Store owners who inherited a store and are not sure what the old scripts did
This article is NOT for:
- Stores that never used the Script Editor
- Teams who only need a standard discount code, which the admin handles without any code
What changed, with dates
Shopify's developer changelog (9 April 2026) lists two dates:
- 15 April 2026: editing and publishing new Scripts was no longer possible.
- 30 June 2026: all Scripts stopped executing entirely.
Shopify's replacement is Functions. A Function is a WebAssembly module that receives JSON from a GraphQL input query you define and returns a JSON list of operations for Shopify to carry out. It runs inside Shopify's own checkout flow, not on your server.
Rebuild map: where each old script goes
Scripts were grouped by what they changed. The replacement depends on that, not on how the Ruby was written.
| Old script did | Rebuild as | Check first |
|---|---|---|
| Cart or line item discounts | Discount function | Does a public app already do this? |
| Changed the price of a shipping rate | Discount function (delivery discount) | Is the new price a discount, or a different carrier rate? |
| Hid, renamed or reordered shipping options | Delivery customization function | Does the rate come from the carrier or a rate table? |
| Hid or reordered payment methods | Payment customization function | Which gateways are live? |
The three-question rule we use before writing any code:
- Did the script change money, availability or wording? If it only changed wording or ordering, it is the cheapest to rebuild and the easiest to drop.
- Does a public app already cover it? Stores on any plan can use public apps that contain Functions.
- Would the store notice if it stayed off? If nobody can name the last order it affected, do not rebuild it.
The tradeoff we make
We prefer one custom app with several small Functions over one large Function. The cost is more moving parts to deploy and version. The gain is that a bug in a shipping rule cannot break your discount logic, and each Function stays small enough to meet Shopify's limits.
Those limits are the part Ruby scripts did not have. Shopify documents them as fixed and dynamic:
- Compiled binary: 256 KiB
- Runtime linear memory: 10 MiB
- For carts up to 200 line items: 11 million instructions, 128 kB of input, 40 kB of output
Shopify recommends Rust for performance. Its guidance says JavaScript is fine for prototyping but you should expect to hit the instruction limit sooner. For a public app, a large cart, or heavy logic, choose Rust.
What breaks in production
- The old script's behaviour was never written down. The most common finding is a rule nobody remembers. Run the Shopify Scripts customizations report before deciding what to rebuild.
- Plan access is different from Scripts. Stores on any plan can use public apps that contain Functions, but custom apps with Function APIs are limited to Plus stores. Check the store's plan before quoting a custom build.
- Large carts. A Function that works with 5 line items can run out of instructions at 200. Test with a realistic worst-case cart using Shopify CLI, which can run a Function locally.
- No dynamic code. The App Store does not allow apps that edit and run Function code dynamically, so rules that used to be edited live in the Script Editor now need a deploy or a configuration field backed by metafields.
- External calls. The fetch target that calls an outside service is limited to custom apps on Enterprise stores. The usual workaround is to pre-load data with metafields or cart attributes.
When the opposite call is right
Do not write a custom Function when a public app does the same job and your rules are standard. A tiered discount, a free-shipping threshold or a payment filter by country is usually an app install plus configuration, not a build.
Do not rebuild a script that has not affected an order in a long time. Dropping it is a valid migration outcome, and it removes a thing to maintain.
How we scope this
A typical migration for us is an audit of every old script, a decision per script (rebuild, replace with an app, or drop), then the build and a test with realistic carts. We scope it as a fixed project of 4 to 6 weeks, and the code lives in your own repository from day one. If you want that done for your store, see our Shopify development service.
Further reading
- Shopify Flow or a Custom AI Agent: Who Owns Which Job
- What Shopify Development Services Include
- Shopify MCP and AI Agents
For the automation side of checkout and operations, see Shopify automation.
