Shopify Scripts no longer run. Shopify’s Help Center says Scripts were deprecated on June 30, 2026, and any still-published Script was deactivated. If your store relied on Ruby Scripts for tiered discounts, shipping rules or hidden payment methods, that logic

has to be rebuilt as Shopify Functions, either with an app or with custom code.

This guide covers what changed, how to inventory what you had, which Function API replaces which Script type, how to test without risking live checkouts, and where a migration usually goes wrong. We write it from the perspective of an engineering team that reviews and repairs Shopify code for a living.

TL;DR

  • Editing and publishing new Scripts ended April 15, 2026, and all Script execution ended June 30, 2026. There is no rollback to Scripts.
  • Start from Shopify’s generated customizations report in the Script Editor app. It lists every Script and points to a replacement app or a Function API tutorial.
  • Functions are not Scripts with new syntax. They are backend logic Shopify calls at set targets, fed by a GraphQL input query, and they favor Rust or JavaScript compiled to WebAssembly.
  • Test on a development store first, then activate the replacement and deactivate the old logic. Do not run both blindly.
  • Public apps with Functions work on any plan. Custom apps with Functions require Shopify Plus.

Table of Contents

What actually changed, and when

Scripts were small Ruby programs, written in the Script Editor, that ran during checkout. Shopify’s own reference splits them into three types: line-item Scripts for cart-price and line-item discounts, shipping Scripts for shipping methods and shipping discounts, and payment Scripts for renaming, hiding or reordering payment gateways.

The timeline, per Shopify’s changelog:

Date What happened
April 15, 2026 You could no longer edit or publish new Scripts
June 30, 2026 All Script execution ended

There is a second, related change that trips people up. Additional scripts and checkout.liquid are separate from Script Editor Scripts, and they were retired on a different schedule. Shopify’s documentation says checkout.liquid and additional scripts were sunset for the Thank you and Order status pages on August 28, 2025, and script tags on those pages are sunset for non-Plus stores on August 26, 2026. Stores still depending on them must move to checkout extensions. If you were not sure which of these two systems your store used, you are not alone. Check both.

Checkout extensibility vs. Scripts: how they fit together

People search for “checkout extensibility vs. Scripts” as if it were a straight swap. It is not. Think of it as three layers:

So Scripts map to Functions for business rules, while checkout.liquid and additional scripts map to checkout UI extensions and pixels for the visual and tracking side. A Function has no URL you can call. Your app supplies configuration and deployment, and Shopify calls the Function when the relevant event happens. That is a real mental shift for anyone who wrote Scripts by editing code in the admin.

If you are weighing which checkout tool fits a given requirement, our walkthrough on choosing a Shopify checkout customization approach goes through the options.

Step 1: Inventory what your Scripts did

Do not start by writing code. Start by finding out what you had.

Shopify documents the path: in the admin go to Apps, then Script Editor, and open Replace Shopify Scripts to view the generated customizations report. For each customization you can see the name, description and source links, plus recommended apps or linked Function API tutorials for recreating it.

Export or screenshot that report before you touch anything else. Before you change checkout configuration, it is also sensible to take a full store snapshot, and backup plugins for Shopify are one way to do that.

Then build a simple sheet with one row per Script:

  • What it did in plain English (“free shipping over $75 for retail customers, not for wholesale”)
  • Which customer tags, products, collections or countries it touched
  • Who on your team depends on it (marketing runs a promo on it, support quotes it)
  • Whether anyone can still explain why it exists

That last column matters. In audits, a surprising share of old Scripts turn out to be stacked patches: a discount rule, plus a fix for the rule, plus a fix for the fix. Migration is the moment to delete what no longer earns its place.

Step 2: Map each Script to a Function API or an app

Shopify’s Function API documentation lists use cases such as custom delivery options, new discount types, and cart or checkout validation. In practice the mapping looks like this:

Script type Typical logic Where it goes now
Line-item Script Tiered pricing, buy X get Y, B2B tag discounts Discount Function
Shipping Script Hide, rename or reorder rates, free shipping thresholds Delivery customization Function, plus discount logic for shipping discounts
Payment Script Hide or reorder gateways by country, cart or customer Payment customization Function
Cart checks (often hacked into Scripts) Block checkout under a minimum Cart and checkout validation Function

Some rules do not map one-to-one. A “free gift at threshold” is a good example: it needs the gift added to the cart and then discounted, which usually means combining a cart transformation with a discount. Plan for a few of your Scripts becoming two moving parts.

Where Functions can do more than Scripts

Scripts had hard walls. Shopify’s limitations page says they could not access metafields or Liquid cart attributes, could not add cart items or increase item prices, and could not increase shipping-rate prices. Functions read their data through an input query, so a migration is a chance to drive rules from metafields instead of hard-coded product IDs. That alone removes a whole class of “someone renamed a collection and the discount broke” incidents.

Five limitations of Shopify Scripts

Shopify also notes Scripts could behave unexpectedly in non-primary currencies and directs merchants to Functions for those carts. If you sell in multiple currencies, test those carts specifically.

Step 3: Buy an app or build a Function

This is the real decision, and it comes down to how unusual your rules are.

Use an app when the rule is common: percentage tiers, free shipping thresholds, hiding a payment method for a country. Shopify’s rule here is simple. Stores on any plan can use public apps from the Shopify App Store that contain Functions. Configuration is quick, and someone else maintains the code.

Build custom when your logic combines several conditions, depends on your ERP or customer data, or an app would force you to bend the business to fit. The catch: only Shopify Plus stores can use custom apps containing Function APIs, and some Function capabilities are Plus-only.

A rough test we use with clients:

  1. Can you describe the rule in one sentence with no “except when”? An app probably covers it.
  2. Does the rule need data an app cannot see, such as warehouse stock tiers or contract pricing? Build.
  3. Are you paying for three apps to emulate one Script? Consolidate into one custom Function.

Cost deserves a clear-eyed look before you commit. Our piece on what a Shopify app really costs covers the budget traps for founders and CTOs.

Step 4: Build it the way Shopify expects

If you are going custom, the mechanics are well documented. Shopify CLI scaffolds a Function extension with shopify app generate extension, which produces the essential configuration, schema, input-query and code components.

A few things to know before writing logic:

  • Language. Functions can be written in any language that compiles to WebAssembly, with templates and client libraries for Rust and JavaScript. Shopify strongly recommends Rust for performance with large carts.
  • Performance is a checkout issue. Functions run in purchase-critical paths, and Shopify warns that delays can hurt backend processing and prevent purchases. A slow Function is a lost order, not a lag in a report.
  • Keep the input query lean. Request only the fields the rule needs. Every extra field is more data to deserialize on every cart change.
  • Make ties deterministic. Scripts often “worked” because of iteration order. A buy-two-get-one rule needs an explicit tie-break (cheapest item, then lowest variant ID, for example) or two identical carts can discount differently.

This is also where code quality shows. Plenty of teams are now generating first drafts of Functions with AI assistants. That is fine for a prototype, but a Function that compiles is not a Function that survives a cart with 80 line items. We cover the security side of app code in Shopify app security checks.

Step 5: Test without touching live checkout

Shopify’s migration workflow is to test the replacement app or manual Function customization first, then deactivate the Script it replaces. Since Scripts have already stopped, the equivalent for you is: validate on a development store, then activate on production deliberately and watch it.

Shopify’s testing guide recommends combining Shopify testing, local execution and unit tests. On a dev store, shopify app dev gives you preview with live rebuilding, and execution logs appear in the terminal and the Dev Dashboard. shopify app logs streams filtered logs.

Here is the test matrix we build for each rule:

  • Happy path: the exact scenario marketing wrote the rule for.
  • Boundaries: one cent under and over a threshold, quantity one below the trigger.
  • Stacking: the rule combined with discount codes, automatic discounts and gift cards.
  • Customer types: guest, logged-in retail, tagged wholesale.
  • Geography and currency: every market you sell to, including non-primary currencies.
  • Big carts: 50 or more line items, to catch performance problems early.
  • Empty and odd carts: subscriptions, digital goods, items with no weight.

Write these as unit tests where you can. Then run a short list by hand on the dev store, and a smaller one on production right after activation.

Step 6: Go live, then watch

Activation is not the finish line. For the first week:

  • Compare daily order value, discount totals and shipping revenue against the same weekdays before the change.
  • Read Function execution logs for errors and timeouts.
  • Give support a list of what changed, so they recognize a cart that behaves differently.
  • Set alerts on checkout conversion. A silent failure shows up as a drop in completed checkouts, not as an error message. Our Shopify site alerts page explains one way to catch that.

Common migration mistakes

Porting line by line. Ruby loops over line items do not translate into Function logic. Rewrite from the business rule, not the code.

Forgetting the non-Script customizations. Additional scripts, checkout.liquid edits and script tags are a separate migration to checkout extensions, and their sunset dates are different from Scripts.

Installing three apps that fight. Overlapping discount apps can produce combinations nobody intended. Decide the precedence on paper first.

Skipping documentation. The person who wrote the original Script has often left. Write the rules down this time, in the sheet from Step 1.

Treating the deadline as the goal. The deadline has passed. The goal is accurate pricing and a checkout you trust. Rushed replacements are where margin leaks.

Our perspective

Most migration guides treat this as a language conversion: Ruby in, JavaScript out. In our experience that is the smallest part of the work. The hard part is that nobody remembers what the Scripts were for.

We approach it the way we approach any code audit. First, find out what the code actually does and what the business needs it to do. Second, delete what is dead. Third, rebuild what remains as simply as possible, because simple Functions are fast, cheap to maintain and easy to hand to the next developer. We lean on experienced engineers for the design and use AI tooling to speed up the repetitive parts, then review every line before it goes near a checkout.

Our perspective — overview diagram

We also see a new pattern: founders who used an AI assistant to generate a replacement Function over a weekend and now cannot tell whether it is right. That is a legitimate place to start. It just needs a second pair of eyes before it handles real orders. A short review of the logic against your rule sheet catches most problems.

One firm opinion: do not custom-build what a well-maintained public app already does. Save your budget for the rules that make your business different.

— Chad

Getting help with the migration

If you want a second opinion before you ship, we offer a Senior Developer Review starting at $449 and an Ecommerce Assessment and Shopify Audit starting at $299. Both are one-off engagements. For stores that need custom Plus builds, bespoke Shopify work starts at $12,000, and you can see everything on our pricing page. If a Function was written by an AI tool and you are unsure it is safe, our Vibe Check is a fixed $449 review of exactly that. For broader Shopify and AI engineering work, see our services.

FAQ

Can I still use Shopify Scripts?

No. Shopify’s Help Center states that Scripts were deprecated on June 30, 2026, and that Scripts still published on that date were deactivated and no longer work. You need to recreate the behavior with a Shopify Functions app or a custom Function.

Do I need Shopify Plus to use Functions?

Not for every case. Stores on any plan can use public apps from the Shopify App Store that include Functions. Building your own custom app with Function APIs requires Shopify Plus, and some Function capabilities are Plus-only.

What is the difference between checkout extensibility and Scripts?

Scripts were Ruby code that changed discounts, shipping and payment options. Checkout extensibility is Shopify’s supported way to customize checkout, and Functions are the backend-logic part of it. Visual and tracking customizations move to checkout extensions, while pricing and rule logic moves to Functions.

How do I find out which Scripts my store had?

Open Apps, then Script Editor in your Shopify admin, and choose Replace Shopify Scripts. The generated report lists each customization with its name, description and source links, plus suggested apps or tutorials for rebuilding it.

Should I write Functions in Rust or JavaScript?

Both are supported through Shopify’s templates and client libraries. Shopify strongly recommends Rust for performance, especially with large carts. JavaScript is quicker to start with, so it suits simple rules on smaller carts.

Sources