Shopify Scripts to Functions migration

If you are on Plus and still have Scripts, this is not a refactor you get to schedule at leisure. Scripts are tied to checkout.liquid, and checkout.liquid is gone. Anything still running as a Script stops applying at that point, which in practice means discounts silently not applying and shipping rates showing at full price.

What Scripts did and what replaces them

There were three kinds of Script, and each one maps to a different Function type.

Line item scripts handled product and order discounts: buy one get one, percentage off a collection, tiered spend thresholds, customer-tag pricing. These become discount functions. Shopify has consolidated product, order and shipping discounts into a single discount function API, which is a genuine improvement over maintaining three separate ones.

Shipping scripts renamed, reordered and hid delivery options. These become delivery customisation functions. The common cases are hiding express shipping for heavy or restricted items, renaming methods to something a customer understands, and reordering so the sensible default is first.

Payment scripts hid or reordered payment methods. These become payment customisation functions. Hiding cash on delivery above an order value, or hiding a method for a particular market, are the usual jobs.

Cart Transform has no Script equivalent, and it is the interesting one. It lets you change what is in the cart before checkout: expanding a bundle SKU into its components so inventory draws down correctly, merging component lines into a single bundle line, or updating a line's presentment price. Brands that faked bundles with a hidden product and a lot of Liquid can now do it properly.

What actually changes

The logic is usually the smallest part of the job.

Scripts were a text field in the Shopify admin. You wrote Ruby, saved, and it ran. Functions are compiled to WebAssembly, written in Rust or JavaScript, deployed through the Shopify CLI as part of an app, and versioned. That means a repository, a deployment step and an app that has to exist and stay installed. For a brand with no development process this is the real change, not the syntax.

Functions also run under limits Scripts did not have. There is an instruction budget and an input size cap, and the input is a GraphQL query you define rather than the whole cart object. A Script that looped over every line item and every variant metafield needs restructuring, not translating. In practice this is a good discipline, because it forces the query to state exactly what the logic depends on.

The other difference worth knowing is that discount functions run through Shopify's discount system, so they interact with discount codes and automatic discounts in ways Scripts did not. Combination rules, which discounts can stack with which, are now configuration rather than code. Stacking behaviour that was implicit in a Script has to be made explicit.

What usually goes wrong

Three things, repeatedly.

Discount stacking is the first. Scripts applied in sequence and the last one won. Functions combine according to rules you set. Brands that ran several overlapping promotions find the behaviour changes unless the combination rules are set to match.

Currency and markets is the second. Functions receive presentment currency, and logic written against shop currency gives wrong answers in every market but the home one. If the store sells internationally this needs testing per market, not once.

The third is testing. Scripts could be tested in the admin against a live cart. Functions need a development store, seeded carts and a deliberate test matrix. Budget for that.

Timeline

A store with two or three straightforward discount Scripts is 2 weeks. A store with tiered B2B pricing, customer-tag logic, bundles and market-specific rules is 4 weeks. The variable is how much of the logic was doing something Functions do natively versus something that needs redesigning.