Shopify Scripts Are Off: A Functions Migration Playbook for Plus (September 2026)
Shopify disabled creating and editing Scripts on April 15, 2026, and Scripts stopped executing entirely on June 30, 2026. Shopify has confirmed the deadline will not move again. If your Plus store still has discount logic, shipping rules, or payment method gating that lived in a Ruby Script, that logic is not running anymore, and your checkout is quietly falling back to Shopify defaults. The replacement, Shopify Functions, is not a port of the same code. Functions are compiled WebAssembly modules that run inside Shopify's own infrastructure, and the migration is an architecture change, not a copy and paste. This playbook covers what actually broke, how Functions differ, and the order to rebuild in so the highest revenue logic comes back first.
Shopify Scripts Are Off: A Functions Migration Playbook for Plus (September 2026)
Shopify Scripts stopped executing on June 30, 2026. That was the second of two deadlines: on April 15, 2026 Shopify disabled the ability to create or edit Scripts, and on June 30 the runtime went dark for good. Shopify has stated the cutoff will not extend again. If your Plus store still carried custom discount logic, shipping rate rules, or payment method gating inside a Ruby Script, that code is no longer running, and checkout is applying Shopify's default behavior in its place. Depending on what the Script did, that can mean missing tiered discounts, wrong shipping options, or payment methods that should be hidden showing up at checkout.
This is not a warning about an upcoming deadline. It is a recovery playbook for a deadline that has already passed, built around the fact that Shopify Functions are a different architecture, not a drop in replacement.
What Changed Under the Hood
Scripts were interpreted Ruby. They ran in a sandbox that Shopify maintained alongside the checkout, and you wrote them in the admin. Functions are compiled artifacts. You write them in a language that compiles to WebAssembly, the Shopify CLI compiles that code to a Wasm module, and Shopify loads and executes the module inside its own core infrastructure at defined points in the commerce lifecycle. The practical effect is that a Function runs in under 5 milliseconds every time, including during peak traffic, because it is a statically compiled binary executing natively rather than an interpreted script in a separate environment.
| Dimension | Shopify Scripts (retired) | Shopify Functions |
|---|---|---|
| Language | Interpreted Ruby | Rust, JavaScript, AssemblyScript, any Wasm target |
| Execution | Sandbox alongside checkout | Compiled Wasm inside Shopify core |
| Deployment | Edited in admin | Compiled and deployed as part of a Shopify app |
| Input model | Script reads cart context | GraphQL input query returns typed JSON |
| Limits | Runtime sandbox limits | 11 million instruction budget per invocation |
| Status | Off since June 30, 2026 | Current platform standard |
The most important structural difference is the input model. A Function declares what data it needs through a GraphQL input query. Before Shopify calls your logic, it runs that query and hands your module the resulting JSON, whose shape matches the query. You do not have ambient access to the whole cart the way a Script did; you request the fields you need and Shopify passes exactly those. That is faster and safer, and it means porting a Script starts with rewriting its data access, not its business rules.
The Order to Rebuild In
Not every Script carried equal revenue weight, and the recovery order should follow the money, not the code base layout.
Start with anything that gates payment methods or applies compliance rules, because a Script that hid an ineligible payment option or blocked a restricted product is now failing open. That is a correctness and sometimes a legal problem, not just a merchandising one, so it comes first.
Second, rebuild discount logic that Scripts handled, especially tiered pricing, volume breaks, and automatic promotions tied to cart composition. When these fall back to defaults, customers either lose a discount they were promised or receive one they should not, and both erode trust and margin. Discount Functions are the most mature part of the Functions surface, so this work is well trodden.
Third, restore shipping and delivery customization: custom rate logic, method renaming, and hiding rates that should not appear for a given cart. These are visible at checkout and directly affect conversion.
For each, the migration is three concrete steps. Write the GraphQL input query that returns the cart data the rule needs. Implement the rule in a Wasm target language. Deploy it as part of a Shopify app and wire it to the relevant checkout extension point. We covered the checkout extensibility surface these Functions attach to in our checkout extensibility guide, which is worth reading alongside this if your Scripts touched the checkout UI as well as its logic.
The Constraint That Trips Teams: The Instruction Budget
Functions run inside an 11 million instruction limit per invocation. Exceed it and Shopify rejects your Function's output and falls back to default behavior, which is the exact failure mode you are migrating away from. This is a real constraint for logic that loops over large carts or complex discount matrices. The instruction budget is why language choice matters more than it did with Scripts, and it is why teams with heavy logic should default to a Wasm native language rather than JavaScript, whose runtime overhead eats into the budget. That trade off deserves its own treatment, and we go deep on it separately.
The design implication is to push work into the input query rather than into the module. Every field you can have Shopify compute or filter before your code runs is instruction budget you keep for the actual rule. Fetch narrowly, compute minimally, return early.
If You Are Also Rethinking the Platform
Some teams reached the Scripts cutoff already questioning whether Shopify's checkout model fits their roadmap at all, particularly enterprise brands running complex B2B pricing that strained even the old Scripts. A forced migration is a reasonable moment to ask the larger question. If you are weighing a deeper move rather than a like for like port, the trade offs between staying on Plus, going headless, and comparing against other enterprise platforms are laid out in our SFCC versus Shopify Plus versus headless comparison and in our replatforming guide for teams leaving Salesforce Commerce Cloud. For most teams the answer is to rebuild the logic in Functions and keep moving, but the migration is the right time to check that assumption rather than defer it another year.
When This Applies to Your Stack
If your Plus store predates 2026 and you have not audited it since June, do that first. Pull the list of Scripts that existed before the shutoff, map each to the checkout behavior it controlled, and check whether that behavior is currently correct in a test order. Anything that is now wrong is a live revenue or compliance issue, not a backlog item. Then rebuild in the payment, discount, shipping order above, pushing data access into input queries and watching the instruction budget.
Contra Collective rebuilds Scripts logic as production Shopify Functions for Plus merchants, including the app packaging, checkout extension wiring, and the performance work to keep complex rules inside the instruction budget. If your team is staring at a checkout that quietly reverted to defaults, or wants the migration done as part of a broader headless move, we can scope and execute that.
FAQ
Can I still use Shopify Scripts in any form?
No. Scripts stopped executing on June 30, 2026, after editing was disabled on April 15, 2026, and Shopify has confirmed the deadline will not extend. Any remaining Script logic is not running.
Do I have to rewrite Scripts in Rust?
No, but language choice matters. Functions can be written in any language that compiles to WebAssembly, including Rust, AssemblyScript, and JavaScript. Rust and other Wasm native languages leave more of the 11 million instruction budget for your logic, which matters for complex rules.
What happens to checkout if a Function exceeds the instruction limit?
Shopify rejects the Function's output and applies default behavior for that invocation. That is the same fall back you get from a missing Script, so staying inside the budget is a correctness requirement, not just an optimization.
Is migrating to Functions the same as going headless?
No. Functions are the current standard for custom checkout logic on any Shopify store, headless or not. A headless move is a separate, larger decision, though the forced Functions migration is a reasonable moment to evaluate it.
How do I know which of my Scripts broke?
Audit the Scripts that existed before the shutoff, map each to the checkout behavior it controlled, and place a test order to confirm whether that behavior is currently correct. Anything wrong is now running Shopify defaults.
Sources
More from the lab.
The Cloud Security Alliance's Agentic Transaction Security Framework: A Compliance Blueprint for AI Checkout
Agentic checkout is shipping faster than the compliance infrastructure meant to govern it. Shopify defaulted agent checkout on for a million merchants, Stripe and OpenAI's Agentic Commerce Protocol is live, and Google extended Universal Cart with holiday specific checkout tooling this month, all while the Cloud Security Alliance's Agentic Transaction Security Framework, structured around five control areas including explicit mapping to PCI DSS v4.0.1 and PSD2/PSD3 strong customer authentication, remains the clearest attempt to define what secure actually means for a transaction an agent initiates rather than a human clicking buy. This post breaks down what the framework actually requires and where it intersects with the agentic checkout paths your storefront is probably already exposed to.
Shopify Functions in Rust vs JavaScript: WebAssembly Performance and When Each Wins (September 2026)
Shopify Functions can be written in any language that compiles to WebAssembly, and the two most common choices, Rust and JavaScript, are not close on performance. JavaScript Functions run about three times slower than Rust, because the JavaScript runtime itself has to be bundled into the Wasm module, while Rust and AssemblyScript compile more or less directly to Wasm instructions. That gap would be academic if Functions had generous limits, but they do not: Shopify enforces an 11 million instruction budget per invocation, and blowing past it means Shopify rejects your output and falls back to default behavior. For simple discount rules the language does not matter. For complex logic over large carts, it decides whether your Function runs at all. This is the trade-off, with real numbers and a concrete pattern for staying inside the budget.
Shopify Checkout Components vs Going Headless: Composable Checkout on Plus (2026)
Shopify's Summer 2026 Edition made Checkout Components generally available on Shopify Plus, and it quietly redraws the build versus buy line for enterprise checkout. For years the choice was binary: accept Shopify's hosted checkout with the customization limits of checkout extensibility, or go fully headless and own the entire storefront including the checkout, taking on the PCI scope, the maintenance, and the risk that comes with it. Checkout Components is the middle path: composable, custom checkout built from Shopify's own primitives, running on Shopify's infrastructure, without going headless. For a large brand that wants a differentiated checkout but does not want to own a payment surface, that is a meaningful new option. This post reads Checkout Components against a full headless build on the axes that actually decide enterprise architecture, PCI scope, upgrade path, performance, and total cost of ownership, and gives a straight framework for choosing.