Shopify Scripts Went Dark on July 1: The Post-Sunset Audit

Shopify Scripts stopped executing on 30 June 2026. Editing and publishing had already been disabled since 15 April, so most teams treated the final date as a formality. For stores that finished their migration, it was. For everyone else, 1 July was the first day of a very specific kind of outage: nothing crashed, no alert fired, and orders kept flowing. The only thing that changed is that some of them were priced wrong.

We spent the first week of July running post-sunset audits for Plus merchants. The pattern was consistent enough to write down.

What actually stopped working

Scripts covered three surfaces, and each one fails differently now that the Ruby engine is gone.

None of these produce a failed checkout. That is the whole problem. A broken app throws a 500 and someone notices within the hour. A missing discount just looks like a customer who did not use a promo code.

Why so many teams missed one

The migrations we reviewed were rarely incomplete because of engineering failure. They were incomplete because of inventory failure. Three recurring causes:

Scripts nobody owned. The Script Editor let anyone with Plus access publish Ruby. Several of the stores we audited had scripts written by an agency that had not been engaged since 2022. Nothing in the codebase referenced them.

Conditional logic that rarely fires. A script that applies a discount only for wholesale customers ordering above a threshold might trigger twice a month. It will not show up in a spot check of last week's orders, and it will not show up in a QA pass on a development store unless someone deliberately builds that cart.

Apps that installed scripts on your behalf. Some older subscription, loyalty and bundling apps wrote line item scripts as part of their setup. If the app vendor migrated to Functions in their own release cycle, you are fine. If the app was uninstalled but the script was orphaned, or if the vendor quietly dropped support, you are not.

The audit, in order

1. Pull the historical Script inventory. The Script Editor is gone, but the record is not. Check your version control, your agency's handover documentation, and any exports taken before 15 April. If nothing exists, reconstruct from behaviour instead of code.
2. Reconcile discount totals across the boundary. Compare total discount value applied per day for the two weeks before 30 June against the two weeks after. A step change on 1 July is your line item scripts. This is the fastest signal available and it needs no code archaeology.
3. Diff your shipping rates. Open checkout with three representative carts: a light domestic order, a heavy domestic order, and an international order. Any rate that appears now and did not appear in June was being suppressed by a shipping script.
4. Diff your payment methods. Same exercise at the payment step. Watch specifically for high-fee methods you deliberately hid from low-margin carts, and for B2B gateways that were meant to be restricted to tagged customers.
5. Interview the merchandising team. They know which promotions existed. Ask what should be running this month, then verify each one end to end in a real cart.

For step two, a short query against the Admin GraphQL API gives you the reconciliation data without waiting on a report build.

// Compare discount application across the Scripts sunset boundary.
// Run once for June 16-29 and once for July 1-14, then diff the totals.
const query = `
  query OrdersInWindow($cursor: String, $search: String!) {
    orders(first: 250, after: $cursor, query: $search) {
      pageInfo { hasNextPage endCursor }
      edges {
        node {
          name
          createdAt
          totalDiscountsSet { shopMoney { amount } }
          discountApplications(first: 10) {
            edges { node { __typename allocationMethod targetType } }
          }
        }
      }
    }
  }
`;

async function windowTotals(searchWindow) {
  let cursor = null;
  let orderCount = 0;
  let discountTotal = 0;

  do {
    const res = await adminGraphql(query, { cursor, search: searchWindow });
    const page = res.data.orders;

    for (const edge of page.edges) {
      orderCount += 1;
      discountTotal += Number(edge.node.totalDiscountsSet.shopMoney.amount);
    }

    cursor = page.pageInfo.hasNextPage ? page.pageInfo.endCursor : null;
  } while (cursor);

  return {
    orderCount,
    discountTotal,
    discountPerOrder: orderCount ? discountTotal / orderCount : 0
  };
}

Compare discountPerOrder across the two windows. Seasonal variance will move that number by a few percent. A vanished script moves it by a lot, and it moves on exactly one date.

Rebuilding what the audit finds

The mapping from Scripts to Functions is close to one to one, which is the good news. The work is in the semantics, not the surface area.

• Line item scripts become Discount Functions, registered as automatic discounts or code discounts through the discount APIs.
• Shipping scripts become Delivery Customization Functions, which reorder, rename or hide delivery options returned to checkout.
• Payment scripts become Payment Customization Functions, applying the same three operations to payment methods.

The differences that catch people out are the ones nobody warns you about until testing. Functions compile to WebAssembly and run inside a strict resource budget, so a script that looped over a large cart and hit an external service has no direct equivalent. Any data a Function needs at evaluation time has to be present in the input query, which usually means moving customer tiers, contract pricing or bundle definitions into metafields or metaobjects before the Function will work at all.

That data modelling step is where most rebuild timelines actually go. We wrote about the underlying structure in our developer guide to metaobjects and metafields, and the broader migration sequencing is covered in our Scripts to Functions playbook. If you are still deciding which logic belongs in a Function at all rather than in an app or the theme, this breakdown is the shorter read.

Stopping the next silent failure

Scripts are the last deprecation of this cycle, but they will not be the last one. Two changes are worth making while the incident is fresh.

Put a floor under discount reconciliation. A daily job that compares discount value per order against a trailing seven day average, alerting on a deviation past a threshold, would have caught this within twenty four hours instead of two weeks. It costs an afternoon to build.

Then write down what your checkout actually does. Not the code, the behaviour: every rule that changes a price, a rate or a payment option, who asked for it, and where it now lives. Most stores we audit cannot produce that document, which is exactly why a deprecation with a fourteen month runway still landed as a surprise.

Frequently asked questions

Can I still see my old Scripts anywhere?

No. The Script Editor was removed and the Ruby source is not retrievable through the Admin API. If you did not export before 15 April 2026, you have to reconstruct behaviour from order history, merchandising records and checkout observation.

Will Shopify extend the deadline?

It was not extended, and the engine has already been removed. There is no rollback path.

Do Functions cost more to run than Scripts did?

Functions execute on Shopify infrastructure at no per-execution cost on eligible plans. The cost difference is development and maintenance, not runtime.

My orders look fine. Do I still need to audit?

Run at least the reconciliation in step two. Rarely triggered scripts, such as wholesale tiers or seasonal bundles, will not surface in a normal week of orders but will cost you the first time the condition is met.

How long does a rebuild take?

A straightforward percentage or tiered discount is usually a few days including testing. Logic that depends on customer segments or contract pricing takes longer, because the data model has to be built before the Function can read it.