Shopify Scripts stop executing on June 30, 2026. That is not a soft deprecation or a "we recommend you migrate" notice. It is a hard kill date. Every discount script, every payment customisation, every shipping rule you built over the past five years will simply stop running. No fallback. No grace period.
If you are a VP of Engineering or CTO at a brand doing $10M+ on Shopify Plus, and your checkout relies on Scripts, you have weeks to act. Not months. Weeks.
This is the enterprise playbook for migrating to Shopify's checkout extensibility framework. We will cover the technical architecture, the deadlines you cannot miss, the budget you need, and the mistake most agencies make that turns a straightforward migration into a six-month money pit.
The Deadline Map: What Dies and When
Shopify's checkout extensibility migration is not one event. It is a rolling series of deprecations that started in 2024 and concludes in August 2026. Here is the complete timeline:
| Date | What happens | Impact |
|---|---|---|
| August 13, 2024 | checkout.liquid removed for Information, Shipping, and Payment steps | All stores. Already done. If you had custom checkout UI on these steps via Liquid, it is gone. |
| April 15, 2026 | Scripts can no longer be edited or published | You cannot deploy new Scripts or modify existing ones. Lock-in begins. |
| June 30, 2026 | All Shopify Scripts stop executing | Every line-item discount, shipping customisation, and payment rule built with Scripts dies. |
| August 28, 2025 | checkout.liquid, Additional Scripts, and script tags removed for Thank You and Order Status pages (Plus stores) | Post-purchase tracking pixels, upsells, and custom thank-you logic using legacy methods break. |
| August 26, 2026 | Same removal for Basic, Shopify, and Advanced plan stores | Shopify auto-upgrades the store and strips legacy code. No grace period. |
The critical date for Plus merchants: June 30, 2026 is your hard wall. If your checkout logic relies on Scripts, you have until then to migrate to Shopify Functions. There will be no third extension. Shopify has already pushed this deadline twice.
The New Architecture: What Replaces What
Shopify's checkout extensibility framework has four pillars. Each replaces a different piece of the legacy system:
| Legacy system | Replacement | What it does |
|---|---|---|
| Shopify Scripts (line-item discounts) | Shopify Functions (Discount APIs) | Product discounts, order discounts, discount combinations. Runs as WebAssembly with 5ms CPU budget. |
| Shopify Scripts (shipping) | Shopify Functions (Delivery Customization) | Rename, reorder, or hide shipping options at checkout. |
| Shopify Scripts (payment) | Shopify Functions (Payment Customization) | Rename, reorder, or hide payment methods based on cart contents or customer attributes. |
| checkout.liquid (custom UI) | Checkout UI Extensions | Inject trust badges, upsells, loyalty widgets, custom fields into checkout. Native Shopify design components only. |
| Additional Scripts / script tags (tracking) | Web Pixels (Customer Events API) | Analytics, conversion tracking, and marketing pixels. Sandboxed execution. |
| checkout.liquid (branding) | Checkout Branding API | Colours, fonts, corner radius, logo placement. Full visual control without touching Liquid. |
Shopify Functions: The Technical Reality
Shopify Functions are the backbone of the new checkout logic layer. They replace Scripts with a fundamentally different architecture: instead of interpreted Ruby running in Shopify's sandbox, Functions compile to WebAssembly (Wasm) and execute at the edge with strict resource constraints.
Available Function APIs (2026-04 version)
- Discount Functions: Product discounts, order discounts, and discount combinations. The most common migration path from Scripts.
- Cart Transform: Line expand (bundles into components), line update (price/property changes), and line merge (combine lines). Critical for subscription and bundle architectures.
- Cart and Checkout Validation: Enforce minimum/maximum quantities, block checkout on custom conditions (geo-restrictions, product compatibility rules).
- Fulfillment Constraints: Restrict which locations can fulfil specific items. Force same-location fulfilment for multi-warehouse operations.
- Delivery Customization: Rename, reorder, or hide shipping options based on cart contents, customer tags, or delivery address.
- Payment Customization: Rename, reorder, or hide payment methods. Essential for B2B (showing Net 30 only to approved companies) or restricting COD by region.
Runtime Constraints
This is where enterprise brands get caught. Functions are not a general-purpose compute environment. They have hard limits:
- 5ms CPU per invocation. Your logic must complete in 5 milliseconds. Complex conditional trees with many SKU lookups can hit this ceiling.
- 250KB output cap. The response payload cannot exceed 250KB. Relevant for discount Functions that return many line-item modifications.
- No external network calls. Functions cannot call external APIs. All data must be available via metafields, metaobjects, or the input query.
- Deterministic execution order: Cart transforms run first, then discounts, fulfilment constraints, delivery customisation, shipping discounts, payment changes, and finally validation.
Shopify Functions: CPU budget per invocation
We treat 3ms as the ceiling, not 5ms. That headroom is what stops a Function failing silently as your catalogue grows.
The "no network calls" constraint is the one that trips up most agencies. If your current Scripts pull data from an external pricing engine or CRM, you cannot replicate that pattern in Functions. You need to pre-sync that data into Shopify metaobjects and query it natively. The 2026 update allowing Functions to read app-specific metaobject entries directly (without API calls) makes this viable, but the data architecture must be designed upfront.
The Mistake Most Agencies Make
Here is the pattern we see repeatedly: a brand hires an agency to "migrate Scripts to Functions." The agency treats it as a 1:1 translation exercise. Take the Ruby Script, rewrite the logic in Rust or JavaScript (targeting Wasm), deploy, done.
This fails for three reasons:
- Scripts accumulated organically. Most Shopify Plus stores have 5-15 Scripts that were added over years by different developers. They interact in unpredictable ways. A "loyal customer" discount Script might conflict with a "bundle" discount Script, and the resolution order was never documented. Migrating each Script in isolation without understanding the interaction model produces a checkout that behaves differently from what customers expect.
- Functions have a different execution model. Scripts ran sequentially in the order you configured them. Functions run in parallel within their category, with Shopify's own resolution logic determining how multiple discount Functions combine. You cannot replicate Script execution order semantics in Functions. You have to redesign the discount architecture.
- The checkout UI changed. If your Scripts had user-facing side effects (showing a "you saved $X" message, displaying tiered pricing in the cart), those UI elements no longer exist. You need Checkout UI Extensions to replicate them. This is a separate workstream that the "just migrate Scripts" scope misses entirely.
The correct approach is not "migrate Scripts." It is "redesign checkout logic for the extensibility framework." The output might look nothing like the input, and that is fine. What matters is that the customer experience and business rules are preserved.
The Living Ecosystem Difference
Traditional agencies treat checkout extensibility migration as a one-time project. Scope it. Build it. Deploy it. Invoice it. Walk away.
The problem: Shopify ships quarterly API versions. New Function APIs appear. Existing APIs gain capabilities. The checkout UI extension component library expands. The platform you migrated to in July 2026 will have materially different capabilities by January 2027.
In our living ecosystem model, checkout extensibility is not a project. It is an ongoing system that appreciates:
- AI monitors every checkout session. Conversion rate by step, error rates, payment method distribution, average completion time. Anomalies are flagged within hours, not discovered in a monthly report two weeks later.
- New Shopify capabilities are evaluated proactively. When Shopify ships a new Function API or checkout component, we assess whether it enables a better implementation of your existing logic or unlocks new checkout experiences. You do not need to track Shopify's changelog yourself.
- Function performance is monitored continuously. If a discount Function starts approaching the 5ms ceiling due to catalogue growth (more SKUs means more metaobject lookups), we optimise it before it starts failing in production.
- A/B testing is built into the system. New checkout UI extensions can be rolled out to a percentage of traffic. You see the conversion impact before full deployment.
| Dimension | Traditional one-time migration | Sonder living ecosystem approach |
|---|---|---|
| Post-launch monitoring | None. You discover problems via customer complaints. | Real-time checkout telemetry. Step-by-step conversion tracking. Error alerts within minutes. |
| Platform updates | You find out about new APIs from Twitter or your dev team's Slack. | Every quarterly API version evaluated against your checkout. Relevant improvements implemented proactively. |
| Performance degradation | Discovered when Functions start timing out and orders fail. | Execution time monitored. Optimisation triggered at 3ms (60% of budget), not 5ms (failure). |
| Conversion optimisation | Not in scope. Separate engagement if you want it. | Continuous. UI extension experiments, payment method optimisation, and checkout flow analysis baked into the retainer. |
Investment and Timeline
Realistic ranges for enterprise checkout extensibility migrations:
| Complexity | Typical scenario | Investment | Timeline |
|---|---|---|---|
| Standard | 3-5 Scripts (discounts + shipping), basic checkout UI needs, no external data dependencies | $35,000-$60,000 | 4-6 weeks |
| Complex | 8-15 Scripts with interactions, custom validation logic, B2B payment terms, external pricing data sync | $60,000-$120,000 | 6-10 weeks |
| Enterprise | 20+ Scripts, multi-market checkout variants, complex bundle/subscription logic, full checkout UI rebuild | $120,000-$220,000 | 10-16 weeks |
These ranges include discovery, architecture design, implementation, QA across all checkout scenarios, and deployment. They also include 3 months of post-launch monitoring within our living ecosystem model.
For brands that want ongoing checkout optimisation (which we strongly recommend), the living ecosystem retainer adds $4,000-$12,000/month depending on checkout complexity and traffic volume.
The Migration Process
Week 1-2: Audit and Architecture
- Run the Shopify Scripts Customizations Report to identify all active Scripts
- Document every Script's business logic, trigger conditions, and interaction patterns
- Map each Script to its replacement (Function API, UI Extension, or Web Pixel)
- Identify external data dependencies that need metaobject sync architecture
- Design the new discount combination and priority model
Week 3-6: Build and Test
- Develop Shopify Functions (typically in Rust for performance-critical paths, JavaScript for simpler logic)
- Build metaobject sync layer for any external data dependencies
- Develop Checkout UI Extensions for customer-facing elements
- Migrate tracking to Web Pixels via Customer Events API
- Deploy Functions alongside existing Scripts (they coexist during the migration window)
- Run parallel testing: same cart, compare Script output vs Function output
Week 7-8: Cutover and Stabilisation
- Disable Scripts (while Functions handle all logic)
- Monitor checkout conversion, error rates, and Function execution time
- Validate all discount combinations with production traffic
- Confirm Web Pixel data matches legacy tracking
When to Escalate
Some checkout customisation patterns cannot be replicated in the current Functions framework. If your store relies on any of the following, you need a custom architecture conversation, not a standard migration:
- Real-time external pricing: If checkout prices are calculated by an external engine (ERP, CPQ system) at the moment of purchase, Functions cannot call that API. You need a pre-checkout sync or a custom app that runs before the checkout flow begins.
- Multi-currency pricing logic: If your discount logic varies by currency in ways beyond percentage-off (e.g., fixed-amount discounts that need exchange rate adjustment), the architecture is more complex.
- Checkout UI that requires DOM access: Checkout UI Extensions use Shopify's component library. You cannot inject arbitrary HTML, run external JavaScript, or access the DOM. If your current checkout has heavily custom UI (not just branding), expect a redesign.
Act Now
The April 15, 2026 editing lockout has already passed. You can no longer modify your Scripts. If your Functions are not deployed and tested by late June, you are running production checkout logic on a dead platform with no ability to fix bugs.
If you are a brand doing $10M+ on Shopify Plus and your checkout relies on Scripts or legacy checkout.liquid customisations, we need to talk this week. Not next quarter.