Shopify Scripts Replacement for Margin Rules (2026)
Shopify Scripts turns off June 30, 2026. If your margin or discount logic lives in Ruby, here is what breaks and how to replace it, with or without a developer.
Shopify Scripts turned off on June 30, 2026. If any of your margin, discount, or shipping logic lived in a Ruby Script, it stopped running that day, silently, with no error and no warning. That date has passed, so the question now isn't whether to move, it's whether you already have and just haven't checked.
If you want the general migration overview, we covered that in Shopify Scripts stopped working: find what silently broke. This piece is narrower on purpose: what to do about the margin and discount rules specifically, since that is the part native Shopify cannot replace.
Here is what actually breaks, what your replacement options are, and how to choose, including the honest case for building it yourself.
What Scripts did, and what dies with it
Scripts let you run custom Ruby at checkout to change line items, discounts, shipping, and payment options. Plenty of Shopify Plus stores quietly built real logic on it: tiered discounts, promo guardrails, shipping rules, sometimes a rough attempt at protecting margin.
When Scripts switches off, that logic is gone. Not migrated, not warned, gone. Anything you relied on Ruby to enforce at checkout reverts to native Shopify behavior, which means no custom discount logic and no concept of your cost or margin at all.
If you are not sure whether you have Scripts in play, check the Script Editor app on your store before June. A surprising number of merchants inherited Scripts from an agency build years ago and forgot.
The replacement options
Two real paths, plus the do-nothing trap.
Shopify Functions. This is Shopify's official replacement. Functions run on a WebAssembly runtime instead of Ruby, and they are genuinely more capable in some ways. The catch: Functions are developer territory. You write them, you test them, you deploy them, you maintain them as Shopify's APIs evolve. If you have engineering capacity and want to own the logic, this is the right answer.
A no-code enforcement layer. An app that does the checkout-time logic for you, configured in a dashboard instead of code. This is the right answer if you want margin and discount rules running without a dev cycle, especially if what you actually care about is protecting margin rather than building bespoke checkout behavior.
The do-nothing trap. Letting Scripts lapse and falling back to native discounts. This is a choice too, and for some simple stores it is fine. If your Scripts only did "10 percent off if X in cart," native automatic discounts can probably cover it. If your Scripts were doing anything to protect margin, native Shopify has no replacement for that, because it cannot see your cost.
Where margin rules specifically land
This is the part most migration guides skip. Scripts could not really enforce a profit floor or MAP without a developer hand-coding the math in Ruby, and even then it could not see your true landed cost. So if margin protection is your goal, "migrate your Scripts to Functions" is not quite the right framing. The honest framing is: this is your chance to put real margin enforcement in, since you are touching checkout logic anyway.
Here is how the three approaches compare for margin work specifically:
| Capability | Shopify Scripts | Shopify Functions | No-code enforcement layer |
|---|---|---|---|
| Available after June 30, 2026 | No | Yes | Yes |
| Custom discount logic | Ruby | WASM (you build) | Configured |
| Margin floor enforcement | Manual Ruby, no real cost | You build it | Yes |
| MAP enforcement | Manual Ruby | You build it | Yes |
| Sees true landed cost | No | Only if you wire it | Yes, via ERP sync |
| Decision latency | ~30 to 50ms | Low | Under 10ms |
| Who maintains it | You | Your devs | The vendor |
To be clear about my bias: I build one of the no-code layers, so weigh that. But the comparison above is the real trade space, and if you have the engineering team and want full control, Functions is a perfectly good call.
How to choose
A few honest questions.
Do you have a developer who will own checkout logic for the long run? If yes, Functions is viable and gives you total control. If no, a no-code layer will be less painful.
Is your goal custom checkout behavior, or protecting margin? If it is margin, the deciding feature is whether the tool can see your real cost. Native cannot. Scripts could not. Functions can if you wire it up. A purpose-built layer does it out of the box, and the accurate version pulls live cost from your ERP, like NetSuite COGS.
How close is June 30? The closer it gets, the more a fast install matters. A no-code layer can be live in shadow mode in about 48 hours and fully enforcing in roughly three weeks, with no checkout code changes. A Functions build is a real project on your roadmap.
FAQ
Is June 30, 2026 the real deadline? Yes. Shopify Scripts is being sunset on that date. Plan to have a replacement running before it.
Can Shopify Functions enforce a margin floor? It can if your team builds that logic and feeds it real cost data. It does not do it out of the box, and it has no native concept of your COGS.
What is the fastest path if I just want to stop unprofitable orders? A no-code enforcement layer, because there is nothing to build. See how to stop unprofitable orders in Shopify Plus.
Did I lose data if I didn't migrate before Scripts stopped working? No data was lost. Your Scripts logic stopped executing on June 30, 2026, and the behavior simply disappeared, silently. If you haven't put a replacement in since, that gap is still open today.
The Scripts sunset is annoying, but it is also a free excuse to fix something Scripts was never good at: enforcing margin on real cost. Do not just port the old logic. Put in the rule you actually wanted.
See a no-code margin layer running on your store: start a free trial. Or start with the foundation, real-time checkout margin enforcement for Shopify Plus.