Shopify Scripts Sunset: What Breaks on June 30 and How to Fix It

These are the most common. They run on cart-add, cart-update, and at checkout, mutating line item prices or applying cart-level discounts. The Shopify Scripts API exposed Input.cart.line_items and let scripts mutate prices via methods like change_line_price.

Real examples we have seen:

• Automatic 10% off for every line item if the customer’s tag includes vip.
• A “buy two, get one half off” rule keyed off SKU prefix.
• A subscription-discount overlay that applied an additional percentage to recurring orders.
• A B2B price tier where customers tagged wholesale_50 got prices from a separate metafield-backed price list.

Shopify Scripts could hide, rename, or reprice shipping methods at checkout. The most common use cases:

• Hide overnight shipping for items above a weight threshold.
• Rename a generic carrier to something branded.
• Apply free shipping over a customer-specific threshold (different for retail vs B2B).
• Hide international shipping for restricted-region SKUs.

After June 30, the shipping logic reverts to whatever Shopify’s native shipping rules express. If your native rules were configured assuming the Script would filter, you will see methods appear that you assumed were hidden. Conversely, branded carrier names revert to defaults.

The least visible until they break. Payment Scripts could hide payment methods based on cart contents, customer, or amount. Examples:

• Hide cash-on-delivery for international destinations.
• Hide a specific gateway above a certain order value.
• Restrict store credit redemption to tagged customers.

Some Plus merchants moved beyond the standard Scripts API into the older custom checkout layer that the Shopify Plus Checkout Scripts product enabled. This is the deepest customization category and the one most likely to have been forgotten. If your store has a checkout.liquid file or custom checkout snippets that piped data through legacy hooks, those break the same day. The migration target for this layer is Checkout Extensibility, which is a different surface entirely.

Shopify’s official replacement is a two-product story. Shopify Functions replaces the price-mutation, discount, and validation work that Line Item Scripts did. Checkout Extensibility replaces the UI customization and any custom checkout pages that used the legacy checkout layer. The two products are independent, and most Scripts migrations need both.

After dozens of Scripts audits, almost every Plus store falls into the same five patterns. We map them on day one of the audit, then estimate the migration scope from there.

A customer tagged tier_gold gets 15% off the entire cart. The Script reads Input.cart.customer.tags, checks the tag, and applies a cart-level discount.

Migrates to: A Discount Function that reads the customer’s tags via the GraphQL discount input, checks for the tag, and returns a discount value. The Function is installed via a custom app. The customer-tag-to-discount mapping moves to either the Function’s hardcoded logic, a metafield on the customer, or a config-app interface.

Buy SKU X, get SKU Y free. The Script inspects line items, detects the trigger, and adjusts the target line price to zero.

Migrates to: A Discount Function with cart-line input. Slightly trickier because Functions have stricter input contracts and you cannot iterate over the cart with the same flexibility as Ruby. The audit often surfaces that the original Script also handled edge cases (what if the customer has two of SKU X, do they get two free Y?) and those rules have to be re-expressed precisely.

Hide cash-on-delivery if the shipping address is outside a list of approved countries.

Migrates to: A Payment Customization Function. The input includes the cart’s delivery address, the country, and the available payment methods. The Function returns a list of hide operations. This is one of the cleaner migrations.

Customers tagged wholesale get free shipping over $500, retail customers get free shipping over $150.

Migrates to: A Delivery Customization Function that inspects the customer tags and cart total, then either hides paid rates above the threshold or renames the free rate. The native Shopify shipping config also needs review; some of this logic can move to native shipping profiles, reducing the Function’s surface area.

A checkout.liquid file that adds a custom field at checkout, calls out to a third-party API for tax-ID validation, and conditionally renders a banner.

Migrates to: A full Checkout Extensibility project. New custom field via the extensibility API, new validation app, new banner extension, new server-side hook for the third-party call. This is the migration that takes weeks, not days.

This is the methodology we use on day one of every Shopify Plus audit, whether for a Scripts migration specifically or as part of a broader Shopify Plus audit. It is the first half of the Shopify Teardown.

1. Script inventory. Pull every active script from Plus admin > Apps > Shopify Scripts. Capture the title, type (line item, shipping, payment), the Ruby source, the last-modified date, and the author. We have seen stores with eight active Scripts where the team thought they had two. Half of them were written by a contractor in 2019 who is no longer reachable.
2. Revenue impact per Script. Tie each Script to a revenue line. Run a query against the order history filtered by discount codes, customer tags, or cart compositions that match the Script’s logic. The customer-tier Script driving $40K/month in tagged-customer revenue is a P0 migration. The “hide overnight shipping for hazmat” Script that fires twice a month is a P3.
3. Functions feasibility check. For each Script, confirm the replacement Function can express the same logic. Some Ruby patterns (long iteration, mutable state, complex string parsing) do not translate one-to-one. Roughly 15% of Scripts we audit need a logic redesign, not just a port.
4. Checkout Extensibility audit. Walk the live checkout flow at desktop and mobile. Note every customization: custom fields, banners, branded content, third-party widgets. Anything that lived in checkout.liquid or referenced a legacy Plus-only checkout hook needs to migrate to Extensibility, regardless of whether it touched Scripts.
5. Native rule cleanup. Many Scripts existed because the native Shopify rule did not exist at the time. Today, several Script patterns can move to native discount automations, native shipping profiles, or native checkout customizations, with no Function code required. The audit catches these and saves the merchant migration cost.
6. Test plan. Migration is the easy part. Testing every cart permutation against the new logic is where stores actually break. We build a test matrix: SKU combinations, customer tags, cart totals, shipping regions, payment method availability. Every combination gets a “before” expected state and an “after” expected state, then the migration is verified against the matrix.
7. Deployment cutover plan. Functions are app-scoped, so the cutover involves installing a custom app, deploying the Function, enabling it, and then disabling the legacy Script. Order of operations matters. Get it wrong and discounts apply twice for a window.
8. Rollback plan. Plus admin still allows re-enabling Scripts during the migration window (until June 30). After that, the Scripts feature is gone and rollback means re-enabling old code paths in your app, not flipping a Script back on. Plan the rollback before cutover, not during.

Three failure patterns keep showing up in Plus stores that rushed the migration. None of them are intentional. All of them are expensive.

A team migrates the Discount Function, deploys it, marks the ticket closed. Three weeks later, finance notices margin compression on tagged-customer orders. The Function deployed but never actually got attached to a discount automation in the admin. It was running in code, but Shopify never asked it to apply. The fix is one admin toggle. The lost margin during those three weeks is gone.

The audit catch: end-to-end test against a real test customer, not a code review. The Function only matters once Shopify is invoking it.

The merchant migrates the Line Item Script to a Function but forgets to disable the original Script. For a window, both apply. Customers get the discount twice. The store loses 10-30% of margin on every affected order until someone notices.

The audit catch: cutover plan with a hard sequence (deploy Function → verify test customer → disable Script → re-verify). Most teams skip the re-verify.

This one is specifically painful. A B2B customer wholesale account had a Script applying customer-tag pricing. Migration to a Function went fine. But the existing B2B account history (open invoices, draft orders, saved carts) had been calculated against the Script’s prices. After the cutover, importing old invoices into the new B2B account schema produced different totals because the Function expressed the rule slightly differently in edge cases. Finance had to manually reconcile every open invoice.

Three things, in this order. None of them require a contract or a vendor commitment.

1. Pull the Script inventory. Log into Plus admin > Apps > Shopify Scripts. Screenshot or export every active Script. Note title, type, last-modified date.
2. Map each Script to a revenue line. This is the conversation that surfaces P0 vs P3. The customer-tier Script driving $40K/month is not the same priority as the shipping rule that fires twice a month.
3. Decide who is doing the migration. If you have an in-house Shopify dev with Functions experience, they need to start this week. If not, the Teardown engagement is built exactly for this scope: 30 calendar days, fixed price, find $75,000 a year in recoverable revenue or refund.

1. Will Shopify just push the Scripts deprecation date back?
   Shopify has not pushed it. They have communicated the date consistently since 2023. The Functions and Checkout Extensibility products are mature. Plan as if the date holds.
   
2. Can I keep my Scripts running by upgrading to a higher Plus tier?
   No. The Scripts product is being removed entirely. Plus tier does not change it.
   
3. Are Shopify Functions free?
   Yes. There is no per-Function fee from Shopify. You need a custom app to host them, which is a development cost (not a Shopify subscription cost). If you build Functions in-house, the marginal Shopify cost is zero. If you contract it out, the cost is the agency’s bill.
   
4. Do I need to migrate checkout.liquid even if I do not use Scripts?
   Yes, if your store still uses checkout.liquid. Checkout Extensibility is a separate sunset that affects all Plus merchants with the legacy checkout layer, not just Scripts users. The deadline differs slightly but is in the same window. Audit both.
   
5. How long does a typical Scripts-to-Functions migration take?
   For a mid-sized Plus store with 4-8 active Scripts and a custom checkout, 3 to 5 weeks of engineering time. Smaller stores with one or two Scripts can finish in 1 to 2 weeks. Larger stores with legacy checkout.liquid plus 12+ Scripts plus B2B-account history coupling are 6 to 10 weeks.
   
6. What is the Shopify Scripts API replacement for reading customer tags?
   In a Discount Function, the customer is exposed via the GraphQL input under customer.metafields and customer.id. Tags specifically are accessible via metafields if you mirror them, or via the discount automation’s customer-segment filter, which is configured outside the Function. The pattern is different from Scripts’ direct customer.tags access; the audit surfaces every place this matters.
   
7. Is there an automated tool that converts Scripts to Functions?
   No, and we are skeptical of anything claiming to do this. The semantic gap is too large. The migration is a port, not a transpile.