Shopify Scripts Are Going Away. Here's Exactly What to Do Before June 30, 2026.

Shopify Scripts is a Ruby-based execution environment that lets stores run custom logic at checkout. It launched in 2019 and gave Plus merchants a way to build discount rules, shipping overrides, and line item modifications that Shopify's native features couldn't handle at the time.

In June 2022, Shopify released Shopify Functions — a newer, faster execution layer built on WebAssembly. Functions run in under 5 milliseconds, work across more checkout touchpoints, and don't require a Plus plan. Scripts, by comparison, run on a legacy Ruby runtime that Shopify is shutting down entirely.

The deprecation is complete, not partial. On June 30, 2026, Shopify deactivates the Scripts runtime. There's no graceful degradation. Scripts don't return errors — they simply don't run. Your checkout logic that depends on them silently stops working that day.

April 15, 2026 is a separate and earlier cutoff: after that date, you can no longer edit or publish Scripts through the Shopify admin. That means no emergency fixes, no last-minute adjustments. Whatever your Scripts contain on April 15 is what they'll contain until they stop executing on June 30.

There are two separate deadlines and they mean different things.

April 15, 2026 — Edit cutoff. After this date, you cannot save changes to existing Scripts or publish new ones. Your Scripts are locked in place. If you discover a bug in a Script after April 15, you can't fix it. If you need to adjust a discount rule after that date, you can't do it through Scripts.

June 30, 2026 — Execution cutoff. This is the hard deadline. On this date, Shopify shuts down the Scripts runtime entirely. Scripts don't produce errors — they simply don't execute. Any checkout logic running through Scripts stops working without warning to the customer.

The practical implication: you have until April 15 to finish any work in the Scripts editor itself. After that, your migration has to happen entirely through Shopify Functions. The edit cutoff means you can't use Scripts as a safety net while you build the Functions replacement. You need to plan the cutover before April 15, not after.

Shopify Scripts live in the Scripts editor inside your Shopify Plus admin. Here's how to find every Script your store is currently running.

1. Go to Shopify admin → Apps → Scripts. This opens the Scripts editor. Every Script your store has ever created appears here — active, inactive, and drafts.
2. Filter by status: Active. Only active Scripts execute at checkout. Inactive or draft Scripts do not run and don't need migration. Start with the active ones.
3. Document each active Script. For each one, note the Script type (Discount, Shipping, Line Items), the logic it contains, and whether it references customer tags, product handles, or external conditions.
4. Test each Script against the triage framework. Not every Script requires a Functions build. Some can be replaced by Shopify's native Automatic Discounts, Quantity Rules, or B2B Catalog features — no development required. Others need a custom Functions build in Rust/WASM. A few may be dead code that can simply be removed.

The number of active Scripts and their complexity determines your migration scope. A store with two simple percentage-off discount Scripts is a different problem than a store with seven Scripts handling tiered wholesale pricing and shipping overrides.

Every active Script falls into one of three migration paths. The right path depends on the Script's logic and what Shopify's native features can now handle natively.

Native replace. Shopify has expanded its native discount and shipping features significantly since Scripts launched. Many Script-based discount rules — fixed-amount discounts, percentage-off, buy-X-get-Y, free shipping thresholds — can now be replicated with Shopify's Automatic Discounts, Discount Combinations, or Shipping rules with no development work. If your Script falls into this category, you configure the replacement directly in the Shopify admin.

Functions build. Scripts with complex logic — tiered pricing based on quantity, customer-tag-driven wholesale pricing, multi-condition bundle rules, carrier rate manipulation — don't have a native equivalent. These require a Checkout Functions rebuild in Rust, deployed through a custom Shopify app. This is the technical migration path and the one that takes the most time to scope, build, and test.

Remove. Some Scripts are ghost code. They were created for a campaign years ago, a test that never launched, or a feature that's since been handled by an app. These can be deprecated with no replacement needed. Removing them reduces checkout complexity without any rebuild work.

The triage step — classifying every Script before writing a line of code — is what determines whether your migration is a one-day admin task or a two-week engineering engagement.

A Shopify Functions migration has four distinct phases: triage, schema design, logic build, and deployment. The exact scope depends on your Script's complexity, but the process is the same for a simple percentage-off rule and a multi-tier wholesale pricing system.

The triage phase identifies exactly what your Script does and whether any part of it can be replaced natively. A tiered discount Script that applies 10% off for 5+ units and 20% off for 10+ units, for example, may be fully replicable with Shopify's Quantity Rules — no Functions code needed. Knowing this before you start saves significant build time.

The Functions build phase requires Rust (compiled to WebAssembly) and a custom Shopify app to host the Function. The Function reads checkout state via a GraphQL input query, applies your pricing logic, and returns a list of discount operations. Unlike Scripts, which run on a central runtime, Functions execute at the Shopify infrastructure level — faster, more reliable, and scoped to your store only.

Deployment requires the Shopify CLI and a merchant-installed custom app. The Function is version-controlled, testable with local input JSON files, and activatable without impacting live checkout until you're ready.

Scripts run at checkout — they're not in your theme files. But the migration often surfaces a related problem: your theme may contain code that was added by apps that managed your Scripts-based discounts, or UI elements that referenced discount logic that's now changing.

When you uninstall a Scripts-related app as part of your migration, the app's checkout logic disappears. But the app's theme code — JavaScript files, Liquid snippets, CSS references, app embed blocks — often stays in your theme after uninstall. This residual code adds HTTP requests, JavaScript parse time, and DOM nodes to every page load, even though the app it supported is gone.

This is the ghost code problem. It's worth auditing your theme during the Scripts migration, not after. The migration is a natural point to clean up every app dependency that's no longer needed, not just the Scripts-specific ones.