Back to blog

Shopify Development

Shopify Scripts Sunsets on 30 June: Your Functions Migration Checklist

June 4, 2026 · 12 min read

On 30 June, Shopify Scripts stop running. Every line-item discount, shipping rule and payment gateway tweak still living in the Script Editor will cease to execute on that date — not deprecated, not read-only, switched off. If your Plus store relies on Scripts for pricing logic, you have 27 days to replace it.

We understand the scepticism. This deadline has slipped before, and plenty of merchants quietly concluded it would keep slipping. Everything Shopify has done since says otherwise: checkout.liquid is already gone, the Script Editor stopped accepting new installs long ago, and Shopify Functions has had years of investment as the designated replacement. The runway ends this month.

This is the migration guide for the brand that has been putting it off. We have moved several Script-heavy Plus stores onto Functions over the past two years, and the work is more mechanical than you fear, provided the audit starts this week rather than next.

---

Who is affected, and what breaks on the day

Scripts were always a Plus-only feature, so if you are on a standard Shopify plan you can stop reading, though if the sunset has you re-evaluating whether Plus still earns its fee, that is a separate and worthwhile conversation. For Plus merchants, three families of logic are on the chopping block.

Line-item scripts are the big one: tiered pricing, customer-tag discounts for VIP and wholesale segments, automatic gift-with-purchase, bundle maths. Shipping scripts hide, rename, reorder or discount delivery rates based on cart contents or destination. Payment scripts gate payment methods: hiding cash on delivery above a threshold, or surfacing invoice payment only for tagged B2B customers.

On 1 July, none of it runs. Carts price at the base price, every shipping rate displays raw, and every payment method shows for every customer. Your VIP tier pays full price and your B2B accounts see a credit card form.

Nothing errors and nothing alerts you; checkout simply behaves as if the logic never existed. That failure mode is margin leak and conversion damage at the same time, and the brands it hurts most are the ones who find out from a confused customer email on the second of July.

"The Ruby sitting in your Script Editor is probably the only written specification of your pricing logic that exists. Export it before you lose access to it."

---

Audit your Scripts inventory this week

Do not start by writing Functions code. Start by establishing exactly what you are replacing, because in the audits we run, somewhere between a quarter and a third of Script logic turns out to be dead weight: promotions with hardcoded 2023 dates, half of an A/B test nobody ended, a wholesale rule for a channel the brand exited. Migrating dead logic wastes the one thing you do not have, which is time.

The audit is a few hours of focused work:

---

Mapping Scripts concepts to Shopify Functions

Functions cover the same three surfaces Scripts did, but the boundaries sit in different places. The mapping below is where every migration plan should begin.

The three Script types and their Functions counterparts. Note the split in the middle row: shipping scripts that change prices migrate to a different API than shipping scripts that hide or rename rates.

That middle row is the mapping mistake we see most often. Delivery Customization cannot change a rate's price; it only hides, renames and reorders. A shipping script that knocked £3 off standard delivery for subscribers needs a shipping discount through the Discount API instead, so one Ruby file frequently becomes two functions with different deployment targets.

All of these live inside an app rather than the admin. If you already went through checkout extensibility, the app you built for your checkout UI extensions is the natural home for your functions too: one codebase, one deploy pipeline, one place to look when checkout behaves oddly.

---

What actually changes for your team

The technical port is the smaller half of this migration. The bigger shift is operational: Scripts were edited inline in the admin and published instantly; Functions are compiled code, deployed through a CLI, living in a repository.

The operational trade: you lose instant inline edits and gain an actual software development lifecycle around your pricing logic.

The loss of quick edits is real and you should plan for it. A merchandiser can no longer nudge a free-shipping threshold mid-promotion from the admin. The fix is to design for it: build your functions to read their configuration from metafields, so the code defines the rule and the merchant edits the values. Thresholds, percentages and tag lists become settings rather than source code, and most day-to-day changes stop requiring a deploy at all.

In return you get things Scripts never offered. Pricing logic with a git history. The ability to unit test a discount rule against forty cart fixtures before it touches production. A review step between "intern edits Ruby" and "checkout changes for every customer". For any brand where Scripts had become load-bearing revenue infrastructure, this is the upgrade those scripts always deserved.

You are trading convenience for engineering discipline, and on balance the trade is a good one.

---

What has no clean Functions equivalent

Most Scripts port cleanly. A few patterns do not, and it is better to know which before week two of three.

Scripts changed the price itself; Functions apply discounts. A line-item script that set a bundle component to £0 simply showed £0. The Functions equivalent produces a discount allocation, which renders as a struck-through price and a discount line in checkout and in the order admin. The totals match but the presentation differs, and your customer service team will field questions if nobody warns them. Where the bundle presentation genuinely matters, look at the Cart Transform API, which can merge components into a single bundle line — a different tool, but often the better model for what the script was faking.

The single mega-script. Plenty of stores have one sprawling Ruby file where discount, shipping and payment concerns share helper methods and mutable state. Functions force a separation: one function per surface, each with its own input query. Shared logic either gets duplicated or extracted into a module both functions import. Budget time for the untangling, not just the translation.

Genuinely weird one-offs. Every long-lived Script Editor contains at least one hack — a hardcoded SKU exception from a 2022 collab, a rule that only made sense alongside a theme feature that no longer exists. The honest workaround for most of these is deletion. Functions also enforce input size and instruction limits; across the migrations we have run that has bitten exactly once, on a wholesale cart with hundreds of lines and a quadratic loop, and the fix was leaner logic rather than a different platform.

---

The three-week plan

Twenty-seven days is enough for a typical Plus store with a handful of live scripts, and it even leaves a buffer. Here is how we would structure it, starting Monday.

A 27-day runway split into three working weeks, with discounts — the highest revenue risk — cut over last and monitored hardest.

A word on the parity testing itself: it only works if the fixture set is honest. Pull twenty to forty real carts from recent order history rather than inventing tidy examples — include the subscriber with stacked tags, the wholesale order with ninety lines, the gift-with-purchase cart that also carries a discount code. Diff subtotals, shipping and tax against the matching production order, and record every mismatch with a reason. Most differences turn out to be presentation rather than money, but you want that established in a spreadsheet before cutover, not argued about in a support thread afterwards.

Two rules make the cutover safe. First, never run a script and its replacement function on the same surface at the same time; an automatic discount stacking on top of a still-published line-item script will double-apply, and you will give away margin in the exact week you were trying to protect it. Unpublish the script, activate the function, verify, move on.

Second, retire your scripts yourself rather than letting the platform do it. A controlled cutover on 24 June with someone watching the order feed beats an uncontrolled one at midnight on the 30th with nobody watching anything.

On language choice: pick JavaScript unless you already have Rust in-house. Performance is rarely the constraint for typical cart logic, and your team's ability to maintain the code in eighteen months matters more than shaving microseconds now.

---

Gotchas from real migrations

These are the three issues that have actually cost time on migrations we have been close to: none fatal, all annoying, all cheaper to know about in advance.

---

Treat the deadline as a forcing function

There are two ways to spend the next three weeks. One is a grudging like-for-like port that gets you to 1 July with identical behavior and nothing learned. The other treats the sunset as the excuse to do what should have happened years ago: delete the dead rules, write down the live ones, and put your pricing logic somewhere it can be tested, reviewed and rolled back.

The second path costs perhaps two extra days and pays for itself the first time a promotion goes wrong and you can see exactly what changed, when, and who approved it. It also leaves you positioned for the rest of the Functions catalog — cart validation, cart transforms, fulfillment constraints — none of which Scripts could ever touch. We have mapped where each of these sits in the wider stack in our guide to checkout components.

Twenty-seven days is enough. It will not be enough in two weeks.

If you are staring at a Script Editor full of undocumented Ruby and a calendar that suddenly looks short, start with the audit. And if you want a second pair of eyes on what you find, that is exactly the kind of thing we look at in an audit of our own.