Shopify Functions: What You Can Customize Now That Scripts Are Going Away

For years, the honest answer to "can we customise Shopify checkout?" was mostly no, and the workarounds were ugly. Scripts gave Plus merchants a way to bend discount and shipping behaviour, but they were a layer bolted onto a checkout that wasn't designed to be modified.

Functions changed the answer. They're custom logic that runs inside Shopify's own backend at the moment a decision gets made — what discount applies, which delivery options appear, whether this payment method shows, whether this cart is allowed to proceed. Not a script sitting on top of the checkout. Part of how the checkout works.

Two things follow from that, and they matter differently depending on where you are.

If you're on Plus running Scripts: Scripts are being retired as part of Shopify's move to Checkout Extensibility, and migration to Functions is work you need on a roadmap rather than a wishlist. This is the deadline-driven half of the article.

If you're not on Plus: Functions are the most defensible single reason to upgrade — and only if you genuinely need logic native settings can't express. Most stores that think they need custom discount code actually need a better-configured discount, which is free.

Shopify's checkout and extensibility roadmap has moved repeatedly, including deprecation timelines. Confirm current dates and capabilities on Shopify's developer documentation rather than relying on any article's stated timeline.

Functions cover specific decision points in the purchase flow. The main ones:

The pattern: Functions govern logic and rules, not appearance. If you want to change how checkout looks — add a field, insert content, change layout — that's Checkout UI Extensions, a different mechanism, and the pairing is covered in Shopify checkout setup. People conflate them constantly and then scope the wrong project.

The other thing worth naming: Functions run server-side on Shopify's infrastructure. That means they're fast, they don't add front-end weight, and they can't be bypassed by a customer manipulating the browser — which matters when the logic is enforcing a business rule rather than suggesting one.

If you're a Plus merchant with Scripts in production, this is the section that matters.

Scripts were Shopify's earlier customisation layer, written in Ruby and running on the legacy checkout. Functions replace them as part of the broader move to Checkout Extensibility and away from checkout.liquid. The direction has been clear and consistent even as specific dates have shifted.

What migration actually involves:

• Inventory what you're running. Most Plus stores have Scripts nobody documented, written by a developer who's moved on, doing something nobody can fully explain. Finding out what exists is genuinely step one.
• Decide what still needs to exist. Some Scripts encode rules that stopped mattering years ago. Migration is a good moment to delete rather than port.
• Rebuild, don't translate. Functions aren't Ruby and the architecture differs. This is a rewrite against different primitives, not a syntax conversion.
• Test the combinations. Discount logic interacts — stacking rules, edge cases at thresholds, behaviour with gift cards and returns. This is where migrations break, and it breaks in production on the highest-volume day.
• Don't do it during peak. Same rule as every other migration.

The risk of leaving it: when a deprecated system finally stops working, your discount logic stops applying or your shipping rules stop enforcing, in checkout, live. That's not a graceful degradation. Treat it as a scheduled project rather than something to handle when it breaks.

The broader checkout migration context sits with checkout customization specialists.

Before treating Functions as a reason to upgrade, check whether you need them at all. Most stores don't, and the ones that do usually know exactly why.

Try native first. Shopify's built-in discount system handles a great deal — automatic discounts, codes, combinations, thresholds, buy-X-get-Y. Shipping settings handle zones, weight and price-based rates, and free shipping thresholds. The setup guides are Shopify discounts setup and shipping setup. A large share of "we need custom discount logic" conversations end when someone configures the native discount properly.

Then check apps. Many discount, bundle and shipping-rule apps exist precisely because merchants needed logic beyond native settings, and plenty run on Functions themselves. Buying an app that already solved your problem beats commissioning a build — the same judgement that separates a Shopify specialist from a generalist, covered in expert vs generalist developers.

Genuine Functions territory:

• Pricing logic depending on customer attributes, contract terms or account-specific rules
• B2B rules — minimum quantities, restricted combinations, account-based pricing tiers
• Delivery or payment rules conditional on product properties like weight, hazard class or licence requirements
• Bundle logic where the cart representation itself needs to change
• Rules that must be enforced server-side because the business depends on them holding

If none of those describe you, Functions aren't your reason to move to Plus. The wider question of whether you've genuinely outgrown your setup is in signs you've outgrown your Shopify setup.

Enough to scope a project and evaluate a developer, without needing to write any yourself.

Functions are code, deployed as apps. They're written in languages compiling to WebAssembly — commonly Rust or JavaScript — and deployed through a Shopify app, either a custom app for your store or a public one. That means a Functions project has an app lifecycle: development, deployment, versioning, updates.

They run server-side and fast. Shopify enforces performance limits, which is why Functions don't slow checkout the way front-end scripts do.

They're configurable after deployment. Good Functions are built so the rules are adjustable through settings rather than hard-coded, which means your team can change a threshold without a developer. Ask for this explicitly — a Function with hard-coded values means a ticket every time a rule changes, which is the same trap as a hard-coded theme.

What this implies for hiring: this isn't general Shopify work. A developer excellent at Liquid themes may never have shipped a Function. Ask for Functions specifically — what they've built, in what language, and how they handled testing discount interactions. Vagueness there is your answer.

Ongoing ownership matters too. A Function is code you now own, needing maintenance as Shopify's APIs evolve. Establish who maintains it before the build, not after the developer disengages.

Cost. Functions development is specialist Plus work and priced accordingly — the ranges by project type are in Shopify Plus development cost. A single well-scoped Function is a contained project; a suite of interacting discount and validation rules with a Scripts migration behind it is a substantial engagement.

Where projects go wrong:

• Building before checking native. The most expensive avoidable mistake, and it happens because the developer was asked to build rather than asked whether to build.
• Hard-coding the rules. Guarantees a developer ticket every time a threshold changes.
• Not testing interactions. Discounts stack, conflict and behave oddly at boundaries. Test combinations, not just individual rules.
• Forgetting the edge cases. Returns, partial refunds, gift cards, draft orders, subscription renewals — all touch discount logic and all surface later.
• No documentation. Exactly how stores end up with Scripts nobody understands. Don't recreate that problem with Functions.
• Treating it as a one-off. Functions need maintenance as APIs change.

Who to hire: Shopify Functions development experts for the build, checkout customization for wider checkout work, and Plus consulting if you're still deciding whether the upgrade is justified. Regional lists: United States, United Kingdom, Australia, Canada, Germany.

If you're on Plus with Scripts in production, inventory them this quarter and put the migration on a roadmap. That's a scheduled project now or an outage later.

If you're evaluating Functions as a reason to move to Plus, configure your native discounts properly first and check whether an app already solves it. If the requirement survives both tests, it's real — and Functions are the right answer.

For a Scripts audit, a Functions build, or an honest read on whether you need either, browse Shopify Functions development experts or Plus consulting specialists. Free matching, verified experience, no commissions.

Related guides on checkout, Plus and custom development:

• Shopify Functions Development Experts — custom discount, delivery and validation logic
• Checkout Customization Experts — the wider checkout migration and extensibility picture
• Shopify Checkout Setup — configuration before customisation
• Shopify Discounts Setup — what native discounts already handle
• Migrating to Shopify Plus — whether the upgrade is justified
• Shopify Plus Development Cost — project ranges for Functions and checkout work
• Signs You've Outgrown Your Shopify Setup — where checkout limits sit among your constraints