Shopify Scripts to Shopify Functions: Migration Guide After the Sunset

If your tiered discount quietly stopped applying on July 1, or cash on delivery suddenly appeared for customers in countries where you never offered it, you are looking at the Scripts sunset. Shopify switched off every remaining Script on June 30, 2026, and nothing ran in their place.

The fix is to move from Shopify Scripts to Functions: rebuild each discount, shipping and payment rule on the Function API that now owns it, with an App Store app or your own code. Once you know which API each old Script maps to, most stores can restore their logic in days. Below: that mapping, the plan limits that catch people out, a working code example, and the testing routine we use before checkout logic goes live.

What the Shopify Scripts deprecation changed

The Shopify Scripts deprecation happened in two steps. From April 15, 2026, nobody could edit or publish a Script, and from June 30, 2026 every Script stopped executing. Both dates are in Shopify’s developer changelog post announcing the sunset.

The Help Center page on transitioning from Scripts confirms that published Scripts were deactivated and must be recreated with Shopify Functions.

Shopify’s developer migration guide kept the Script Editor read-only until July 30, 2026. That window has closed too, so if nobody exported the source, you are rebuilding from evidence.

If you no longer have the Script source

This is the situation we see most often now, and it is recoverable:

• Order history. Export orders from before June and read the discount titles. “Spend $150, save 15%” in the order data tells you the rule.
• The customizations report. Shopify generated a CSV-exportable report of active Script customizations under Apps > Script Editor. If anyone downloaded it, start there.
• Your own team. Customer service usually knows which shoppers saw which options. Write the rules down as plain sentences first.

Shopify Scripts to Functions: the mapping table

Each Script type now maps to one or more Function APIs: line item scripts split three ways, shipping scripts two ways, and payment scripts map one to one. The mapping is from Shopify’s migration guide; the notes are ours.

The structural difference: a Script was one Ruby file that could change the cart however it liked. Each Function API is narrow. A discount function cannot hide a shipping rate, and a delivery customization cannot change a price. That feels restrictive for a week, then makes the logic far easier to reason about.

How Shopify Functions work (and their limits)

Shopify Functions are small WebAssembly modules that Shopify runs inside its own backend at fixed points in the cart and checkout. You write them in Rust or JavaScript, ship them inside an app, and Shopify calls them; nobody can invoke them by URL. The Function APIs reference lists the hard limits, and they shape how you write logic:

• Compiled module: 256 kB maximum.
• Instructions: 11 million for carts up to 200 lines (the limit scales above that).
• Input: 128 kB of input data and 20 kB of output.
• Input query: 3,000 bytes, a query cost of 30, and list arguments of at most 100 elements.
• Network: none by default. The optional fetch target that calls an external endpoint is limited to custom apps on Enterprise stores.

That last point hurts migrations. Teams want to “just check the ERP” from a Function, and on most stores you can’t. Put the data into metafields or app-owned metaobjects ahead of time and query it in the input.

Rust or JavaScript?

Shopify strongly recommends Rust, because it is less likely to hit limits on large carts. Our rule: JavaScript is fine for hide and rename logic over a few options. For discount logic that loops over every line in big B2B carts, we write Rust.

Discount Functions on Shopify: rebuilding line item scripts

Most line item scripts become a Discount Function, the API that now handles product, order and shipping discounts in one place. It uses cart.lines.discounts.generate.run for product and order discounts and a second delivery target for shipping discounts. According to Shopify’s Discount Function API reference, a single function can return savings across all three discount classes, and you can activate up to 25 discount functions per store.

Two behaviors differ from Scripts:

1. Functions don’t see each other. All discount functions run concurrently, and stacking follows each discount’s combination settings. A Script that applied 10% and then checked the new subtotal has to be redesigned, not translated.
2. You return candidates, not new prices. A Script edited line prices directly. A Discount Function proposes candidates with a selection strategy, and Shopify decides what applies.

A small working example (JavaScript)

Here is a typical old wholesale Script rebuilt as a Function: customers tagged wholesale get 15% off any line where they buy 6 or more units. First the input query, which tells Shopify what data to send:

query CartInput {
  cart {
    buyerIdentity {
      customer {
        hasAnyTag(tags: ["wholesale"])
      }
    }
    lines {
      id
      quantity
    }
  }
  discount {
    discountClasses
  }
}

Then the function itself, in src/cart_lines_discounts_generate_run.js:

import {
  DiscountClass,
  ProductDiscountSelectionStrategy,
} from "../generated/api";

export function cartLinesDiscountsGenerateRun(input) {
  const isWholesale = input.cart.buyerIdentity?.customer?.hasAnyTag ?? false;
  const productClassOn = input.discount.discountClasses.includes(
    DiscountClass.Product,
  );
  if (!isWholesale || !productClassOn) {
    return { operations: [] };
  }

  const targets = input.cart.lines
    .filter((line) => line.quantity >= 6)
    .map((line) => ({ cartLine: { id: line.id } }));

  if (targets.length === 0) {
    return { operations: [] };
  }

  return {
    operations: [
      {
        productDiscountsAdd: {
          candidates: [
            {
              message: "Wholesale 15% off",
              targets,
              value: { percentage: { value: "15.0" } },
            },
          ],
          selectionStrategy: ProductDiscountSelectionStrategy.First,
        },
      },
    ],
  };
}

The operation shape follows the current Discount API reference examples. Scaffold with shopify app generate extension --template discount, run shopify app function typegen after editing the query, and create the discount with the discountAutomaticAppCreate mutation, as Shopify’s discount function tutorial shows. In a real build, read the tag, threshold and percentage from a metafield so the merchant can change them without a deploy.

Delivery Customization: replacing shipping scripts

Shipping scripts that hid, renamed or reordered rates become a Delivery Customization function on the cart.delivery-options.transform.run target. Its API reference (linked from the Function APIs index) allows up to 25 active on each store, and each one returns operations like deliveryOptionHide keyed by the option’s handle.

Common rebuilds we see:

• Hide express shipping for oversized or hazmat products (read a product metafield or tag in the input query).
• Rename “Standard” to show a cut-off or a delay note for certain regions.

Two catches from the docs. A delivery customization runs in checkout but not on the cart page, order edits or subscription renewals. And PO box hiding only works for carrier-service or third-party app rates, since Shopify’s own rates may not expose the address detail. For PO boxes on Shopify-calculated rates, a Validation function that blocks the address is often the safer rebuild.

Shipping discounts (free shipping for VIPs, say) are not a delivery customization. They belong in the Discount API’s delivery target.

Payment Customization: replacing payment scripts

Payment scripts move to the Payment Customization API on the cart.payment-methods.transform.run target, which can hide, rename and reorder payment methods, and on Plus can also set payment terms. The payments functions guide lists limits that trip up old Script logic:

• You can’t rename methods whose name is a logo, such as Shop Pay, Apple Pay and Google Pay.
• Wallets can be removed from the express section but not reordered.
• Hiding a method from one specific placement only works on Plus. On other plans, hiding removes the method entirely.
• Payment terms (net 30, deposits) can only be set on Plus, and not on accelerated checkouts.
• Payment customizations don’t run in Point of Sale, and inside Shop Pay they only affect the gift card field.

The classic payment Script, “hide cash on delivery above $500 or outside the home country”, is a ten-line function or a five-minute app rule. B2B rules that faked payment terms with renamed manual methods should move to real payment terms on Plus.

Cart Transform: bundles and line edits

If your line item script built bundles or rewrote line titles and prices, Cart Transform is the new home. The Cart Transform API reference gives you three operations: lineExpand splits a bundle into its components, linesMerge combines several lines into one bundle line, and lineUpdate overrides price, title or image.

Know the limits. lineUpdate is limited to Plus and development stores. Each app can install only one cart transform per store, though functions from several apps all run. And checkout rejects all three operations when a line has a selling plan, so subscription bundles need a different design.

One gap: Cart Transform reshapes lines already in the cart. A “free gift with purchase” Script now usually becomes theme code that adds the gift plus a Discount Function that makes it free.

App, custom app or no-code: which route fits

Use an existing app when the rule is a standard hide, rename, reorder or discount pattern. Build a custom Function when the logic is specific to your business, involves pricing, or needs data no app exposes. Shopify’s Help Center says you can mix routes across customizations.

Plan facts in that table come from the Checkout Blocks Help Center page, which reserves everything except Thank you and Order status content blocks for Plus, and from the App Store listing for HidePay, whose paid plans run $3.99 to $7.99 a month (its sister app HideShip lists the same tiers).

A correction to some guides we read: delivery and payment customizations do not require Plus in themselves. Stores on any plan can use public apps that contain Functions. Plus is required for custom apps with Functions and for specific capabilities like payment terms. So if you have since dropped from Plus to Advanced, the app route still works.

One practical note on custom apps

Functions-based apps need App Bridge, and custom apps created in the Shopify admin don’t support it, according to the Help Center. Create the app in the Dev Dashboard instead. Our Shopify app development team sets these up in the Dev Dashboard from day one, and we explain the wider process in our post on custom Shopify app development.

Worked example: moving a five-Script store

Here is a hypothetical Plus store with five Scripts that went dark on June 30. Hours are our planning ranges for a developer who knows Functions, not quotes.

Add 8 to 12 hours for app setup, fixtures, tagged production testing and handover, and the job lands around 27 to 43 hours. The biggest variable is agreeing what the old rules actually were.

How to test a Function before it touches real orders

Test in layers, from unit tests to a short tagged release in production. The test and debug guide on shopify.dev covers the tools for each layer.

1. Unit tests. Vitest for JavaScript, cargo test for Rust. Fast, but not run inside WebAssembly.
2. Fixture tests. npm test in the function folder compiles the Wasm module and checks it against every JSON file in tests/fixtures/. Each fixture holds the export, target, input and expected output.
3. Dev store runs. shopify app dev streams logs and writes each execution to .shopify/logs. Copy those into your fixtures, and use shopify app function replay to rerun one while you edit.
4. Tagged production release. Shopify’s migration guide suggests tagging a few test customers (for example TESTER), checking that tag in the input query, and applying the logic only to them. Then remove it and run shopify app deploy.
5. Watch the Dev Dashboard. Every production run shows there if your app has the scopes the input query needs.

Frequently asked questions

What we’d do first

Start with evidence, not code. Pull the last six months of orders, list every discount title and every shipping or payment behavior your team remembers, and write each old Script as one plain sentence: who, what condition, what result. That list is your migration spec.

Then sort it. Hide, rename and reorder rules go to Checkout Blocks or a small Functions app this week. Anything touching price or your own data goes to a custom Function, tested with the routine above.

Moving from Shopify Scripts to Functions is less about rewriting Ruby than deciding where each rule should live. We have built Shopify stores and checkout logic for brands like Delsey, EcoFlow and Kerbholz. If you want that list turned into working Functions, our Shopify Functions and app development services are a good place to start, and our guide to checkout customization with Checkout Extensibility covers the UI side of the same checkout.