Blog · Guide

Shopify Scripts deprecation: the 2026 migration checklist

April 15, 2026: editing and publishing new Scripts is locked. June 30, 2026: every Script stops executing — permanently. If your wholesale, VIP, or subscriber pricing depends on Scripts, here's exactly what to migrate, where Shopify Functions and public apps replace it, and how to test before the cutoff.

8 min read · Updated May 2026

The deadline, in two dates

Shopify announced the Scripts deprecation in 2024 and extended the cutoff once. As of the most recent communication, the schedule is:

  • April 15, 2026 — Editing locked. You can't create new Scripts or edit existing ones in the Script Editor app. Scripts that already exist continue to run.
  • June 30, 2026 — Execution stops. All Shopify Scripts cease executing, regardless of plan. After this date, the Script Editor and any logic inside it is dead code.

Both dates are firm. Plan to be off Scripts well before April 15 — once editing is locked, you can't tweak a Script that's misbehaving while you're mid-migration.

What Shopify Scripts actually does (and why it's going away)

Scripts is a Ruby-based runtime that lets merchants customize cart behavior, line item discounts, shipping methods, and payment gateway choices at checkout. It runs server-side, only on Shopify Plus, and only on checkouts that haven't been upgraded to checkout extensibility.

It's being deprecated for two reasons:

  1. Checkout extensibility is replacing checkout.liquid as the only supported checkout customization model. Scripts requires the legacy checkout, and the legacy checkout itself is going away.
  2. Shopify Functions, the WebAssembly-based replacement, runs on every plan (not just Plus), is sandboxed for performance, and works at every checkout — Shop Pay, draft orders, the Shop app, all of it. Scripts only ever ran on the classic web checkout.

The migration paths

Every Script you have today maps to one of four migration paths. Pick the lowest-friction option that solves the use case.

Path 1: Native Shopify discounts

Since 2024 Shopify supports automatic discounts targeted to customer segments directly in the admin, no app required. If your Script is doing something simple — "give VIP customers 10% off" or "add free shipping for customers in the loyalty segment" — native discounts probably cover it.

This is the cheapest, most boring path. Use it whenever you can.

Path 2: A public app built on Functions

For pricing logic that's more complex than a flat % off — tiered pricing per customer tag, quantity breaks per tier, subscriber price lock at signup, multi-segment exclusivity — you'll want an app that's already implemented the Function for you.

Picking the right app matters: a few apps still rely on Scripts internally and are themselves migrating. Ask the vendor directly: "Does your app depend on Shopify Scripts in any code path?" Anything other than a flat "No" is a yellow flag.

Disclosure: TagTier is one of these. We use the Shopify Admin API, App Proxy, and a theme block — no Scripts dependency anywhere, so the June 30, 2026 deadline doesn't affect TagTier merchants. If your Script is mapping customer tags to prices, we're a 1:1 replacement; see our features and pricing.

Path 3: A custom Function

If your Script does something genuinely unique to your business — say, a custom shipping rate calculation against a third-party rates API — you'll need to build a custom Function. This requires a developer (or your existing dev team), a Shopify Partner account, and a deploy pipeline.

The Function model is well-documented and the local-dev experience is decent (shopify app dev hot-reloads against a dev store). Budget 1–4 weeks of dev time depending on complexity.

Path 4: Re-architect the use case

Some Scripts shouldn't be migrated at all — they were always workarounds. The classic example: a Script that simulates wholesale by stuffing a discount onto every order from tagged customers. The right replacement isn't another piece of code; it's the native B2B catalog model (now on every paid plan as of April 2026) or a tag-based pricing app, depending on whether you have ≤3 or 4+ pricing tiers.

The migration checklist

Run through this sequence well before April 15, 2026. Most stores can complete it in an afternoon; complex stores with custom Functions take 1–4 weeks.

1. Inventory your Scripts

In the Shopify admin, go to Apps → Script Editor. List every Script: name, what it does, and which customer segments / line items / shipping methods it touches. Shopify also publishes a "Shopify Scripts customizations report" that auto-categorizes your Scripts and suggests replacement paths — pull it and use it as your starting checklist.

2. Categorize each Script

Script typeMost likely path
Flat % off for a customer segmentNative discount
Tag-based pricing tiers (wholesale, VIP, etc.)Public app (e.g., TagTier)
Volume / quantity breakPublic app or Function
Subscriber-specific pricingPublic app integrated with your subscription tool
Custom shipping rate against an APICustom Function
Hide a payment method for certain cartsNative payment customization (Functions)
Old "wholesale via discount code" hackRe-architect as native B2B or tag-based pricing

3. Test the replacement on a development store

Before you touch production: clone your store config to a dev store, install the replacement (native discount config, public app, or custom Function), and validate the cart math at every checkout — Shop Pay, draft orders, the Shop app, the regular web checkout. Test with a sample customer in each affected segment.

This is the step most migrations skimp on. Don't.

4. Run Scripts and the replacement side-by-side in production

Scripts and Functions can coexist. Deploy the replacement, leave the Script running for 1–2 weeks, and monitor:

  • Order line item prices match what the customer expected
  • No double-discounting (Script and Function both fired)
  • Refunds and partial fulfillments use the resolved price
  • Subscription renewals (if applicable) match signup price

5. Disable the Script

When you're confident, disable the Script in the Script Editor. Don't delete it yet — keep it around as documentation of the old behavior for 30 days.

6. After April 15, 2026: cleanup

Once editing is locked and you've confirmed the Function-based replacement is stable in production, delete the Script. Document the migration in your internal runbook so the next dev who joins doesn't go looking for the Script.

Common gotchas

"My discount code stacking broke after migration"

Native Shopify discount stacking rules are stricter than what some Scripts allowed. If your Script let a customer combine a tier price and a promo code, you'll need to explicitly allow that combination in your discount settings, or pick an app that handles stacking the way you want.

"Subscriber prices changed at renewal"

If you used Scripts to set subscription pricing, the renewed subscription was getting whatever your Script returned at renewal time — not the price the customer originally signed up for. Most Function-based subscription pricing apps lock the price at signup. Verify this behavior on your replacement.

"My custom shipping rates broke"

Shipping rate Functions have stricter request/response shapes than Scripts did. If you call out to a third-party rates API, expect to add caching and timeout handling — Functions have execution limits Scripts didn't.

"Functions are slower than my Script"

They shouldn't be — Functions execute on Shopify's WebAssembly runtime which is generally faster than the Ruby Scripts sandbox. If you're seeing slowness, the bottleneck is usually a synchronous external API call from inside a Function. Cache aggressively.

If you can't finish migration by June 30, 2026

You have three choices, in order of preference:

  1. Strip the Script-dependent feature temporarily. A store that's missing wholesale pricing for a week is recoverable; a store with a broken checkout isn't.
  2. Switch to a Functions-native public app that does close-enough to what your Script did. Most pricing/discount Scripts have a public-app equivalent within a day's evaluation.
  3. Pay for a developer to build a custom Function on a rush schedule. Budget 1–4 weeks; this is the most expensive option.

The one path that doesn't work is "wait and hope." On July 1, 2026, your Script returns nothing.

Where TagTier fits

If your Scripts are doing tag-based pricing — wholesale tiers, VIP discounts, subscriber pricing, staff codes that shouldn't leak — TagTier is built specifically for this migration. No Scripts dependency, install in 20 minutes, free for development stores so you can prove it works before going live.

Real-world example: See how this pattern played out for a real merchant in our case study, read the story →

Try TagTier on your dev store →

Further reading


Related on TagTier