Shopify Scripts Are Ending June 30, 2026 — Migrate to Functions Now

Shopify Scripts officially shut off on June 30, 2026. If your Plus store still runs custom discount, shipping, or payment logic in the Script Editor, that logic is gone — silently, permanently, and at the worst possible time of year. The replacement is Shopify Functions, and most brands are not ready.

This is the most consequential platform shift on Shopify Plus since the move off checkout.liquid. Here is what Functions actually are, why Shopify killed Scripts, and how to migrate without breaking your conversion rate.

The deadline, in plain terms

• August 28, 2025 — Shopify stopped allowing new installations and edits to Scripts. Existing Scripts kept running.
• June 30, 2026 — Scripts are fully end-of-life. Any logic still living in the Script Editor stops executing on this date.
• No grace period. If you wake up on July 1, 2026 with broken discounts, broken shipping rules, or broken bundle logic, the only fix is a Function rewrite.

If you are on Shopify Plus and have not yet inventoried your Scripts, that audit is the single most urgent technical task on your roadmap.

What Shopify Functions actually are

A Shopify Function is a small piece of code — written in Rust, JavaScript, or TypeScript, compiled to WebAssembly (Wasm), and executed by Shopify's own runtime at well-defined moments in the storefront and checkout flow.

Three things to be precise about, because the internet is full of bad explainers:

1. Functions do not run on AWS Lambda, Cloudflare Workers, or any third-party serverless platform. They run on Shopify's own purpose-built Wasm runtime, embedded in the same infrastructure that serves your storefront. There is no cold start, no external network hop, no per-invocation billing.
2. Python is not a supported language. Shopify experimented with broader language support and pulled it back. The supported toolchain today is Rust, JavaScript, and TypeScript via the Shopify CLI.
3. Functions are pure. Each invocation receives a typed input, returns a typed output, and cannot make external HTTP calls or persist state between runs. That constraint is what makes them fast.

Where Functions can run today

Function area	What you customize	Replaces
Discounts	BOGO, tiered, hidden VIP, bundle pricing	Line item Scripts, third-party discount apps
Cart & Checkout Validation	Block checkout when business rules are violated	Validation logic in checkout.liquid
Cart Transform	Bundle, expand, or hide cart line items	Bundle apps, manual SKUs
Delivery Customization	Rename, reorder, hide, or sort shipping methods	Shipping Scripts
Payment Customization	Rename, reorder, or hide payment methods	Payment Scripts
Order Routing	Choose which location fulfills which item	Custom middleware
Fulfillment Constraints	Force items to ship together or separately	3PL workarounds

Every column on the right is something a Plus merchant historically paid for — in app subscriptions, custom checkout dev, or operational duct tape. Functions consolidate it into versioned code in your repo.

Why Shopify killed Scripts

Scripts were a 2016-era solution to a 2026 problem. Four reasons they had to go:

• Performance. Ruby Scripts ran inline on the checkout request and could blow the latency budget on a heavy cart. Wasm Functions execute in microseconds, bounded by a hard 5 ms budget per invocation.
• Surface coverage. Scripts only worked at checkout, and only on Plus. Functions cover discounts, delivery, payments, cart transform, fulfillment, and validation — and several Function types are available on non-Plus plans through apps.
• Security. Scripts had loose isolation. Wasm gives Shopify a sandbox model that can be reasoned about per-invocation.
• Checkout Extensibility. The new checkout (UI Extensions + Functions) is incompatible with the old checkout.liquid + Scripts world.

This is not a soft deprecation. The new model is the only model.

Scripts → Functions: the migration map

Old Script type	Function replacement	Notes
Line item Script (BOGO, tiered, percent off)	Discount Function	Most common; rewrites cleanly.
Shipping Script (rename, hide, reorder rates)	Delivery Customization Function	Same logic, typed I/O.
Payment Script (hide Apple Pay over $X)	Payment Customization Function	Same logic, typed I/O.
Bundle logic via line item Scripts	Cart Transform Function	Bundles are now a first-class primitive.
Validation in checkout.liquid	Cart & Checkout Validation Function	Plus the relevant UI Extension for messaging.

A clean migration is not a one-to-one port. Plan to redesign, not just re-translate.

What a real Function looks like in production

A Discount Function in TypeScript that gives logged-in customers tagged vip an automatic 15% off:

import type { RunInput, FunctionRunResult } from "../generated/api";
import { DiscountApplicationStrategy } from "../generated/api";

const NO_DISCOUNT: FunctionRunResult = {
  discounts: [],
  discountApplicationStrategy: DiscountApplicationStrategy.First,
};

export function run(input: RunInput): FunctionRunResult {
  const isVip = input.cart.buyerIdentity?.customer?.hasAnyTag === true;
  if (!isVip) return NO_DISCOUNT;
  return {
    discounts: [{
      message: "VIP 15%",
      targets: [{ orderSubtotal: { excludedVariantIds: [] } }],
      value: { percentage: { value: 15.0 } },
    }],
    discountApplicationStrategy: DiscountApplicationStrategy.First,
  };
}

Three commands ship it:

shopify app generate extension
shopify app function run
shopify app deploy

Limits to design around

• 5 ms execution budget per invocation. Pre-compute heavy work into metafields.
• 256 KB compiled Wasm max.
• No external HTTP, no persistent storage. Functions are pure.
• Typed I/O generated from a GraphQL schema.

What breaks on June 30, 2026 if your team does nothing

• Tiered discounts configured in Script Editor.
• Hidden VIP pricing keyed off customer tags.
• Shipping rate logic.
• Payment method gating.
• Bundle pricing assembled inside line item Scripts.

Carts will check out. The logic just won't fire. The first symptom is usually a margin hit finance flags two weeks later.

A 90-day migration plan

Weeks 1–2 — Inventory. Export every Script. Document trigger, inputs, output, business owner. Tag as critical or cosmetic.

Weeks 3–4 — Map and design. For each critical Script, decide its Function replacement. Identify which need a Checkout UI Extension for messaging.

Weeks 5–10 — Build and stage. Implement Functions in a single Shopify app. Test against synthetic carts and historical orders. Stage in a development store.

Weeks 11–12 — Cut over. Activate Functions in production, deactivate the corresponding Scripts the same day, monitor checkout conversion, AOV, and discount usage for two weeks before removing old Scripts.

When Shugert gets involved

We migrate Plus brands off Scripts every month. The pattern: a one-week audit deliverable that lists every Script, its replacement Function, the risk profile, and a fixed-scope build estimate. Migration runs as a fixed-bid sprint inside our Shopify development engagement or as part of an ongoing retainer.

FAQ

Do Shopify Functions run on AWS Lambda?

No. Functions run on Shopify's own WebAssembly runtime, hosted inside Shopify's infrastructure. There is no AWS, Cloudflare, or third-party serverless layer involved.

Can I write a Function in Python?

No. Shopify supports Rust, JavaScript, and TypeScript. Earlier experimental Python support was removed and is not coming back.

Do Functions cost extra?

There is no per-invocation fee. You pay for development time and the Shopify CLI-based app that hosts them.

Are Functions only for Shopify Plus?

No. Many Function types are available across plans, especially through public apps. Custom private Functions are most common on Plus and Enterprise.

What happens to my Scripts on June 30, 2026?

They stop running. Storefronts and checkouts continue to work, but any business logic that depended on a Script silently no longer fires.

Further reading

• Shopify Functions documentation
• Checkout Extensibility migration overview