Shopify Scripts Are Gone: Migrating to Functions Without Breaking Checkout

Shopify Scripts stopped running on 30 June 2026. If your store still relies on Ruby Scripts for line-item discounts, shipping rates or payment gating, that logic is already doing nothing, and the replacement path is Shopify Functions, either a public app built on Functions, or a custom Function if you are on Plus.

The edits were frozen earlier than the shutdown, on 15 April 2026, which is why some teams discovered the problem only when a promotion failed to fire in July.

What actually stopped

According to Shopify's migration guidance, three script types existed, and each maps to a different replacement:

We checked each script type against the Function API, and two of the six rows in the table below do not port cleanly.

The mapping is not one-to-one. One shipping script that both reordered options and knocked £3 off standard delivery becomes two Functions with two deployment targets. Teams that assumed a single swap found themselves building twice.

The behaviour change merchants notice

Scripts mutated price. Functions apply discounts. A line-item script that set a bundle component to £0 simply showed £0. The Function equivalent creates a discount allocation, which renders as a struck-through price with a discount line in checkout and in the admin order.

Totals match; presentation does not. Warn customer service before the cutover, because "why is my free item showing a discount" is a ticket you will otherwise field for a month.

Two limits that break naive migrations

Functions cannot make network requests. Every input has to come from the input query or from metafields. A script that called an external service to check eligibility has to be rearchitected: sync that data into metafields on a schedule, then read it locally.

Validation Functions see the cart, not the order history. A rule like "one per customer ever" cannot read past orders from inside a validation Function. That logic belongs in a discount Function with customer data in the input, or in Flow beforehand.

What the migration costs

Public apps cover the common patterns on any plan: tiered discounts, BOGY, spend thresholds, tag-based pricing, shipping and payment rules. For a store whose Scripts were standard promotion logic, installing an app is a week of testing rather than a development project.

Custom Functions are Plus-only and need a developer. Budget two to three days of parity testing alone, run against 20 to 40 real carts pulled from order history, including the awkward ones: the subscriber with stacked tags, the 90-line wholesale order, the cart that also carries a code.

Cutover order that works

Payment first, because a wrong payment gate is visible and reversible. Delivery second. Discounts last, in a low-traffic window, with the old script unpublished as each Function goes live and 48 hours of order watching per surface.

The limitation to state clearly: there is no rollback to Scripts. The Ruby runtime is gone, so "revert if it breaks" means reverting to a previous Function version or turning the rule off entirely.

Our verdict is to migrate anything still missing as a Function built on metafields rather than rebuilding bespoke logic. Keep the rule set small enough that one person can read it. If your discount stack includes bundles, the bundles inventory checklist covers the stock side that discount Functions do not touch, and the hidden cost of Shopify apps is worth reading before you buy a replacement suite. The Function API itself is documented at shopify.dev.

7-day free trial · all themes included · cancel anytime