Shopify Scripts to Functions Migration: Hydrogen Playbook (55 Days to June 30, 2026)

31 days left. If your Hydrogen storefront still relies on Shopify Scripts for checkout discounts, shipping rates, or payment logic, the clock is louder than the changelog made it sound.

April 15, 2026 already locked the door on new Script edits. June 30, 2026 turns Scripts off completely. There is no extension. Shopify said it twice in two changelog entries and shipped a final compatibility unlock on April 30 to clear the last migration blocker.

This is the focused playbook every other 2026 update treats as a side note. Code diffs. Architecture trade-offs. Hydrogen-specific cart wiring. The actual migration — not the bullet-point version.

Status update — May 30, 2026: 31 days to the cutoff. The first public production receipt landed this week — Tom Rees at WIRO (a Shopify Premier Agency) posted that the team shipped a 1,500+ line Le Col Scripts → Functions migration. That's the scope signal teams negotiating internal estimates can finally point at: a mid-size DTC brand with a serious cycling apparel catalog took an agency team a full migration cycle to land. If your internal estimate was "a sprint or two," the WIRO receipt is the reality check. Move now.

The First Public Production Receipt: WIRO / Le Col

Most of this post is the playbook. Before you dig in, here's the one piece of social proof that wasn't available when I first wrote this in early May.

On May 29, 2026, Tom Rees — eCommerce Strategy at WIRO, a Shopify Premier Agency — posted his monthly agency retro. The headline detail:

"Le Col Shopify Scripts to Functions migration, 1,500+ lines of code, handled brilliantly by dev & QA team."

Le Col is a UK cycling apparel brand on Shopify Plus. WIRO is a Premier-tier agency that knows the platform well. The 1,500-line scope reads as the converted code surface — not just the original Script line count, but the Rust/JS Function equivalents, their input GraphQL queries, the configuration UI for the embedding app, and the test suite that proves parity.

Three things that scope tells you:

1. The migration is not a one-sprint job for a serious catalog. 1,500+ lines, dev + QA in lockstep, a full migration cycle. If your internal estimate to the leadership team was "we'll knock this out in a sprint," the WIRO receipt is the public number you can point at when you ask for a realistic budget. A mid-size DTC catalog with multi-tier discounts, shipping rules, and payment restrictions easily compounds into four-figure line counts once you account for the embedding app, schema queries, and parity tests.

2. Agency-led migrations are landing now, in-house teams should be at parity by mid-June. Premier agencies operate on a 4-6 week sprint cadence for engagements this size. WIRO landing in May means agency-led projects that started in March or April are converging. In-house teams that started later need to compress the same work into less time — which means more weekend deploys, tighter QA windows, and less canary buffer.

3. The work is doable. It is also not trivial. "Handled brilliantly" is agency-speak for the work was hard and the team executed. Treat that as the honest baseline. Plan for unexpected behavior differences between the Script and Function execution model, plan for cart-fixture drift between staging and production, and plan for at least one round of post-deploy adjustments after you cut over.

The rest of this post is the playbook the WIRO team would have been working from. If your team is closer to a migration plan than a migration commit, start here.

The 60-Second Version

April 15, 2026 — editing and publishing new Scripts is already disabled.
April 30, 2026 — Shopify shipped multi-product-discount-per-line in API 2026-04. This was the final Scripts-parity gap. Now you can migrate.
June 30, 2026 — every active Script stops executing. Customers see undiscounted carts. Shipping rates go default. Payment rules disappear.
Replaces it: Shopify Functions — Rust or JavaScript compiled to WebAssembly, running on Shopify's checkout infrastructure.
What Hydrogen teams must verify: Your storefront probably does not call Scripts directly. But your cart and checkout flows depend on the discount, shipping, and payment behavior they produced. After June 30, that behavior is gone unless you ported it.

If your team has not started yet, you have roughly two release cycles. Read the rest. Then start.

What Actually Breaks for Headless Stores on July 1

Hydrogen storefronts often assume the cart they fetch is the cart Shopify will charge. That assumption is wrong on July 1 if any of these are still in production:

A line-item Script that applies a tiered discount based on customer tags, cart contents, or product metafields.
A shipping Script that hides, renames, or reprices delivery options based on cart conditions.
A payment Script that restricts gateway availability based on order totals or customer attributes.

After June 30:

The cart your Hydrogen frontend renders is correct. The checkout your customer hits will not apply the same discounts. Conversion drops. Support tickets spike.
Shipping logic falls back to your raw Shopify shipping zones. International customers may suddenly see options you spent weeks hiding.
Payment restrictions revert. Fraud surface widens.

None of this is dramatic on the surface. That is exactly why teams miss it. The storefront keeps rendering. The metrics quietly degrade.

Why the April 30 Changelog Mattered More Than It Read

Most teams scrolled past this one: "Multiple product discounts can apply on a single cart line." It looks like a discount stacking note.

It is the migration unlock.

Until April 30, 2026, you could not stack multiple product discounts on the same line item via Functions. Scripts handled this natively because Ruby scripting had no execution-shape constraints. Functions, running as sandboxed WASM, were stricter. That gap is exactly what stalled some of the most complex Scripts migrations — multi-tiered loyalty stacks, BOGO promotions layered with subscriber discounts, agency-built bundle rules.

API version 2026-04 closes the gap. The combinesWith field on DiscountAutomaticBasic now lets multiple product discounts apply to the same cart line. Combined with metaobject access in Functions (also shipped in 2026-04), the architectural blockers most teams cited as "we'd migrate but Functions can't do X" are gone.

If you put the migration on the back burner because Functions could not match Script behavior — re-evaluate this week. The platform caught up.

The Migration in Five Steps

1. Inventory your Scripts

Use the Shopify Scripts customizations report from the Help Center to pull every active Script. Categorize:

Line-item Scripts → Discount Functions
Shipping Scripts → Delivery customization Functions
Payment Scripts → Payment customization Functions

Cross-reference each Script with your Hydrogen cart code. Anywhere your storefront reads cart.lines[].discountAllocations, cart.deliveryGroups, or computes its own checkout summary — flag it. That is where the silent break will happen.

2. Pick the runtime

Functions support Rust and JavaScript. The trade-off is real:

Rust — faster cold starts, stricter type system, smaller WASM bundles. Better for high-throughput stores.
JavaScript — easier for teams already writing Hydrogen. Slower compilation but lower learning cost.

For most agency-built Hydrogen stores, JavaScript is the right call. You already have the runtime expertise. Performance differences matter at the top end of cart volume, not the median.

3. Port discount logic

Scripts ran on Ruby. They could mutate cart lines arbitrarily. Functions return a structured Operations array — additions, modifications, returns of discounts — that Shopify applies for you.

The pattern shift looks like this:

// Old Script (Ruby) — arbitrary mutation
Input.cart.line_items.each do |line_item|
  if line_item.product.tags.include?("loyalty")
    line_item.change_line_price(line_item.line_price * 0.9, message: "10% Loyalty")
  end
end
Output.cart = Input.cart

// New Function (JS) — structured operations
export function run(input) {
  const discounts = input.cart.lines
    .filter(line => line.merchandise.product.hasAnyTag)
    .map(line => ({
      targets: [{ cartLine: { id: line.id } }],
      value: { percentage: { value: 10 } },
      message: "10% Loyalty"
    }));
  return { discounts, discountApplicationStrategy: "FIRST" };
}

javascript

Same business outcome. Different mental model. The Function declares intent. Shopify enforces the math, the combinability rules, and the cart line resolution.

4. Update Hydrogen cart rendering

This is the headless-specific step every generic guide skips.

Functions apply discounts at the checkout layer, not the cart layer. Your Hydrogen storefront's cart query needs to read the resolved discount allocations from cart.discountAllocations and cart.lines[].discountAllocations — not compute them locally.

Audit your Hydrogen cart for:

Hardcoded discount math (e.g., manually multiplying unitPrice * 0.9 somewhere in a <CartLine> component).
Custom price-display logic that ignores discountAllocations.
Subtotal calculations that do not subtract discountAllocations[].discountedAmount.

The fix in most cases is two lines — read from the Storefront API response, do not recompute. But finding all the places that recompute is the slow part.

5. Test in checkout draft mode, then ship

Shopify lets you deploy Functions to a draft state for staged rollout. Use it.

For each migrated Script:

Deploy the Function in draft mode.
Run live test orders covering every condition your Script handled.
Verify discount allocations appear correctly in both the Hydrogen cart and the Shopify checkout.
Promote to production only after parity is confirmed.

Aim to have all Functions in production by June 1 at the latest. That gives you four weeks to catch edge cases before the Scripts cutoff. Pushing migration into late June leaves no buffer.

The May 2026 Compounding Problem

The teams I am seeing get hit hardest are not the ones who ignored the Scripts deadline in isolation. They are the ones who let three migrations stack on top of each other in the same release window.

If your Hydrogen storefront is on a version older than 2026.4, you are also looking at:

Mandatory Storefront API proxy (April 9) — custom getLoadContext setups break if the storefront instance is not supplied to Hydrogen's request handler.
Backend consent mode (April 9) — the _tracking_consent cookie is gone. window.Shopify.customerPrivacy.backendConsentEnabled = true is the new default and changes how analytics data flows.
Storefront Catalog MCP → UCP (April 22) — every Shopify store is now an agent-readable endpoint by default. Hydrogen storefronts that still serve raw HTML to product detail pages without structured product data are losing the AI-visibility moat that ships for free with up-to-date Hydrogen.

Sequence the work. Do the Scripts → Functions migration in parallel with the Hydrogen 2026.4 upgrade, not after it. Your testing surface overlaps — the same checkout flows that need Functions parity testing also need consent mode and Storefront API proxy verification. One QA cycle covers all three if you sequence right. Two QA cycles is what happens when you treat them as separate sprints.

What This Says About Where Shopify Is Heading

The Scripts deprecation is part of a pattern across the entire 2026-04 release wave:

Scripts → Functions = controlled, sandboxed execution environment
Storefront API proxy mandate = controlled, server-side data access
Backend consent mode = controlled, server-side privacy state

Shopify is migrating every customizable surface from "merchant-defined runtime code" to "merchant-defined declarative configuration that Shopify executes." The trade-off is less raw flexibility, more reliability and security guarantees.

For Hydrogen teams, this is good news disguised as a deadline. The platform is absorbing infrastructure complexity that used to be your problem. Your job becomes building the differentiated frontend on top of a more predictable backend.

But that only works if you finish the migration. Unported Scripts on July 1 are not "deprecated." They are dead.

Where Weaverse Fits

A clean Scripts-to-Functions migration is mostly a Functions exercise. But the Hydrogen-side cleanup — the cart rendering audit, the price-display logic, the subtotal recalculation — is where most of the time gets burned.

Weaverse Pilot ships with cart and checkout components already wired to read discount allocations from the Storefront API correctly. No hardcoded discount math. No custom subtotal recomputation. The pattern your Functions migration assumes is already the pattern Pilot uses.

Scaffold a new Pilot project:

npx @weaverse/cli@latest create --template=pilot

bash

If your team is migrating an existing Hydrogen storefront and using AI coding tools — Claude Code, Cursor, Copilot, Windsurf, Gemini CLI — install the open-source Shopify Hydrogen Skills:

npx skills add Weaverse/shopify-hydrogen-skills

bash

The skills give your AI agent commerce-aware context for Functions integration patterns, cart line discount allocation rendering, and the API 2026-04 cart shape. Less hallucination on the migration. Faster ports.

The Bottom Line

31 days. Three categories of Scripts. One execution model change. The first public production receipt is now on the board (WIRO / Le Col, 1,500+ lines).

This week: Pull your Scripts inventory. Map each to a Function equivalent. Confirm your Hydrogen version — if you are below 2026.4, sequence the upgrade in the same sprint.
By June 10: Have every Function deployed in draft mode and tested against a real cart fixture suite.
By June 20: Promote everything to production. Verify Hydrogen cart rendering matches under load.
June 30: Scripts stop executing. If you missed a port, you find out from your customers.

The April 30 multi-product-discount-per-line update was the last Scripts-parity unlock. There is no longer a "but Functions cannot do X" excuse worth holding the migration on. The blockers are gone. The deadline is not.

Build for the platform Shopify is becoming, not the one you started on.