Shopify Scripts sunset: what to check after 30 June

On 30 June 2026 Shopify turned Shopify Scripts off. No banner went up at checkout. No email went out. The cart still added up. A discount quietly stopped applying, and the order shipped at full price.

A Script was a small Ruby program that ran in checkout. Ruby is a programming language. Scripts ran on Shopify Plus stores only. Plus is Shopify’s enterprise plan. Scripts changed line prices, hid delivery rates and hid payment methods.

That date has passed, so the job has changed. You are no longer preparing for a deadline. You are confirming that nothing on your store still depends on a Script.

The short answer. Shopify Scripts stopped running on 30 June 2026. If a discount, delivery rate or payment method now behaves differently, a Script used to control it. Export your Scripts customizations report and place one test order per rule. Rebuild each rule you still want as a Shopify Function or app. Retire the rest.

Sources: Shopify Scripts and the Script Editor app, transitioning to Shopify Functions, Shopify Functions APIs, checkout.liquid.

This guide is for the person who owns checkout rules

This is for the operator or engineer of a Plus store. The store ran at least one Script before 30 June 2026. You may have migrated in the spring. You may have done nothing. Either way, you need to know what is live today.

It is not for a store that never used Scripts and never edited checkout.liquid. Nothing here applies to you. It is also not a Functions tutorial. Shopify’s own docs cover the code.

If a rule needs custom code, list the systems it reads from first. The build itself is custom Shopify Functions work. Then see Shopify integrations and custom apps to scope the build. For the rebuild steps, read the Scripts to Functions migration guide.

The sunset ran in two steps, and both have passed

Shopify announced the plan in a changelog (its public list of product changes) on 12 March 2026. Editing and publishing new Scripts ended on 15 April 2026. All Scripts stopped executing on 30 June 2026 (Shopify changelog).

Shopify’s Help Center says Scripts still published “have been deactivated and no longer work” (Help Center). There is no plan tier that keeps them alive. The product was removed, not locked behind a higher plan.

checkout.liquid had its own dates. Liquid is Shopify’s template language. The checkout.liquid file used to render checkout pages. It is now unsupported for the information, shipping and payment steps. The thank you and order status pages were sunset on 28 August 2025. Script tags on those pages were sunset for Plus stores on the same day. For stores not on Plus, they are sunset on 26 August 2026 (shopify.dev).

So for a Plus store, every date on this page is behind you. A custom field, banner or third-party call that lived in checkout.liquid is not running now.

Five checks that confirm nothing still depends on a Script

Do these in order. Each takes an afternoon or less.

1. Open your Scripts customizations report and export it. Shopify generates it for you. It lists the Scripts that were active before the sunset, in sections for payment gateways, shipping and product discounts. You can export it as a CSV file (Help Center).
2. Mark each row: rebuilt, replaced, retired or unknown. Every row needs one of those four words and a named owner. An unknown row is your risk list.
3. Place a real test order in each customer tier. Use a tagged wholesale customer, a retail customer and a guest. Compare the price, the delivery rates and the payment methods against what the rule used to do.
4. Read every native discount, delivery and payment setting as if no code sits behind it. Many were set loose because a Script tightened them later. With the Script off, the loose setting is now the whole rule.
5. Walk the live checkout on a phone and a laptop. If checkout.liquid once added fields or banners, write down what is missing.

The output is a short list of rules with a status and an owner. Sort it by the orders each rule touched, not by how old the rule is.

Each rule has four possible endings

The sunset forces one decision per rule, not one decision per store. Rebuild the rule as a Function. Install an app that already does it. Move it to a native Shopify setting. Or drop it and accept the margin change.

The fourth answer is more common than teams expect. Many Scripts were written because no native rule existed at the time. Check native settings first. Every rule you retire is one you never have to test again.

A Shopify Function is the replacement. It is code that you bundle into an app and install on the store. Checkout extensibility is Shopify’s name for this app-based way of changing checkout. Shopify’s report links each Script to a recommended app or a Functions guide where one exists (Help Center).

Some stores use the sunset to rebuild the whole pricing model instead of porting rule by rule. That is a replatform decision. The Shopify migration services page shows how that is scoped.

Functions run under hard limits your Ruby never had

A port stops being a port here. A function is code compiled to WebAssembly. That is a compact format Shopify can run fast inside checkout. The limits are published, and they are tight.

Source: Shopify Functions limits. A function also gets a fixed input. It cannot read the whole store. Data it needs must come from metafields or cart attributes. Metafields are custom fields on products and customers.

You no longer edit a script in the admin and press save. You build an app, put the function in it, and install the app. Then you attach the function to a discount or a checkout setting. Teams miss that last step.

Three ways a migrated store still loses money

You may think this is finished because the team migrated in the spring and the tickets are closed. Three failures survive a migration that looked clean. Each needs a named owner.

The function was deployed but never attached. A discount function only runs once it is tied to a discount in the admin. Deploying the app is not enough. A correct function can sit idle while every tagged customer pays full price. Only a real test order catches it, not a code review.

The native rules were built around a filter that is gone. The check above covers this. Delivery profiles and payment settings were often loose on purpose. For example, a Payment Script that hid cash on delivery outside your delivery countries is gone. The full method list now shows on every order.

B2B balances were priced by the Script. Open invoices, draft orders and saved carts were costed under the old Ruby. For example, a function that rounds an edge case differently gives a different total. Finance then reconciles by hand. Name who reviews each change before it ships.

Ownership is the part nobody writes down. Functions live in an app. Someone owns that app, its deploys and its alerts. Pick that person now. If nobody on your team can own it, a Shopify Plus agency for Scripts replacement can take on the build and the ongoing engineering.

Facts checked October 2026, re-check by 5 April 2027. Dates and limits come from the Shopify pages linked above.

Sources, checked 5 October 2026. Shopify Scripts and the Script Editor app, transitioning from Shopify Scripts to Shopify Functions, Shopify Scripts deprecation changelog, Shopify Functions, checkout.liquid.