Migrating Shopify Scripts to Functions: a practical guide

Updated July 22, 2026 · 8 min read

Shopify Scripts — the Ruby snippets that Plus stores ran through Script Editor for over a decade — reached end of life on August 28, 2025. Scripts no longer run at checkout, and Script Editor is gone. Its replacement is Shopify Functions: sandboxed WebAssembly modules that run inside Shopify’s checkout, on every plan, not just Plus.

If you still have a store that depended on Scripts logic — or a merchant asking you to rebuild theirs — this guide maps each common Script pattern to its Functions equivalent and walks through a migration that doesn’t break checkout on the way.

What replaces what

Scripts came in three flavors, and each has a direct Functions counterpart:

The biggest conceptual difference: Scripts were code you pasted into your own store. Functions are shipped inside apps. You either build and deploy a tiny app that owns your function, or you install an app whose functions are configurable. There is no “paste Ruby into the admin” path anymore.

The two migration paths

Path 1: build a custom Function

A developer writes the function in Rust or JavaScript, wraps it in a Shopify app, and deploys it to your store. This is the right call when your Script logic was genuinely unusual — say, pricing driven by an external ERP feed. Budget for real engineering: the function itself is small, but you now own an app, its hosting, its API-version upgrades (Shopify retires API versions on a fixed schedule), and its testing story. What used to be a paste-and-forget snippet becomes a piece of software you maintain.

Path 2: use an app with configurable rules

For the patterns that made up the vast majority of real-world Scripts — volume tiers, Buy X Get Y, customer-tag pricing — you don’t need custom code. Discount apps built on Functions expose these as rules you configure in minutes, and the app vendor absorbs the maintenance burden. This is the path we built DiscountForge for, so the examples below use it — but the mapping applies to any Functions-based app.

Rebuilding the four most common Scripts

1. Tiered / volume discounts

The classic if quantity >= 10 then 15% off ladder. As a rule: define quantity or spend thresholds and the discount at each tier, scoped to products, collections, or the whole cart. What Ruby expressed in 40 lines becomes a table with three rows.

2. Buy X Get Y (BOGO)

“Buy 2, get the cheapest free” was one of the most-copied Script templates. As a rule: pick the trigger products and quantity, the reward products, whether the cheapest or a specific item is discounted, and a per-cart cap so a 12-item cart doesn’t hand out 6 freebies unless you want it to.

3. Customer-tag (VIP / wholesale) pricing

Scripts read customer.tags to give VIPs or B2B buyers their price. Functions can’t read tags directly at checkout — the standard workaround is mirroring tags into a customer metafield the function can see. DiscountForge does this sync automatically; you just write the rule as “customers tagged wholesale get 20% off”.

4. Stacking and exclusivity logic

Scripts often ended with glue code deciding which promotion wins. In the Functions world this is handled by discount combination classes (whether product, order, and shipping discounts can stack) plus your rules’ own conditions. Watch this area closely in testing — it’s where most migrations subtly change checkout totals.

A migration checklist that won’t break checkout

1. Inventory your Scripts. List each script, what it did, and which promotions still matter. Retire the dead ones now — most stores find half their Scripts were for campaigns that ended years ago.
2. Map each one to a Functions path: configurable rule (path 2) or custom build (path 1).
3. Rebuild in draft. Recreate each rule without activating it.
4. Verify parity before going live. Run known carts through the new logic and compare against what the old Script produced. DiscountForge has a built-in simulator for exactly this: feed it a cart, see which rule fires and the resulting total — and when a discount doesn’t apply, a trace of why.
5. Cut over one promotion at a time, not all at once. Activate a rule, place a real test order, check the order’s discount lines in admin.
6. Monitor the first week. Watch for support tickets about totals and spot check orders. Conflicts between apps’ automatic discounts are the usual culprit.

FAQ

Do Functions require Shopify Plus?

No — that’s the upside of the migration. Discount functions run on every Shopify plan, so logic that used to be Plus-only is now available to any store via an app.

Are Functions slower than Scripts?

No. Functions are compiled to WebAssembly and execute inside Shopify’s infrastructure with strict instruction limits — they add no meaningful latency to checkout, and there’s no external server call involved.

Can I just keep discount codes instead?

For simple cases, native Shopify discounts may be enough. Scripts users typically migrated because they needed automatic, conditional logic — tiers, tags, exclusions — which is exactly what Functions-based rules restore.

Try the no-code path

DiscountForge rebuilds tiered, BOGO, and customer-tag Scripts as rules on Shopify Functions, with a simulator to prove parity before anything touches your live checkout. If your Script doesn’t fit one of our templates, email support@discountforge.app and we’ll tell you honestly whether we cover it or you need a custom build.