Shopify Scripts Die June 30 (The Last-Minute Migration Playbook)

Shopify Scripts die on June 30, 2026. Six days from now. After that date, every active Script on your store stops executing. Custom discount logic, shipping rules, and payment conditions that depend on Scripts will silently fail. The deadline has been pushed twice before (originally August 2024, then August 2025). Shopify has confirmed it will not push it again. If you have not migrated yet, this is the last-minute playbook for the four realistic options and what to do this week.

What exactly dies on June 30

Shopify Scripts is the legacy Ruby runtime that powered three categories of custom logic.

• Line Item Scripts handled custom discount logic. Buy-X-get-Y rules, dynamic discounts based on cart contents, tiered volume pricing, customer-tier discounts.
• Shipping Scripts handled custom shipping rates. Conditional free shipping thresholds, restricted-region shipping rules, dynamic shipping based on product type or weight.
• Payment Scripts handled payment method visibility. Hiding specific gateways for specific customer segments, country-specific payment rules, B2B-only payment methods.

After June 30, 2026, none of these execute. The Script Editor was already frozen as of April 15. You cannot create new Scripts. You cannot edit existing Scripts. You cannot deploy a fix even if your Script breaks today. The Script keeps running in its current state until June 30, then stops entirely. Detailed migration documentation is at Shopify's official migration guide. For the broader context on how Scripts fits into the platform shift, our Shopify checkout optimization guide for 2026 covers the architectural background.

Step 1 - The 30-minute audit you should run today

Before you decide what to do, find out what you actually have running. Most Plus merchants are surprised by what they find.

Open Shopify Admin. Go to Settings, then Checkout, then Script Editor. List every active Script. For each one, capture three pieces of information.

1. What does it do? Read the description (if any) and the Ruby code. Figure out the actual business logic.
2. What revenue does it influence? Roughly estimate the monthly GMV that flows through that Script. A 10 percent automatic discount on all sitewide orders has different weight than a buy-3-get-1 rule on one product line.
3. Who owns it? Is there a developer, an agency, or anyone on your team who actually knows how it works? If the answer is nobody, that Script is a higher-risk migration.

If you find more than 5 Scripts and the combined GMV influenced is significant (over 30 percent of revenue), you have a serious problem and need to make a decision today, not Friday.

Step 2 - The decision tree

Four realistic paths. Pick based on your situation.

Path A - Emergency Functions build. Choose this if you have one or two simple Scripts and a senior developer (in-house or agency) who can ship Rust or JavaScript in WebAssembly. Realistic timeline: 5 to 10 working days for a clean migration. Not realistic by June 30 if you start later than today.

Path B - Public app bridge. Choose this if your Scripts implement common patterns (volume discounts, tiered pricing, shipping by region, free shipping thresholds, hide payment methods). The Shopify App Store has dozens of apps that mimic each common Script pattern. Install one, configure it to match your Script behavior, disable the original Script. Realistic timeline: 1 to 3 days per Script depending on the pattern. Most merchants without engineering capacity should default to this.

Path C - Disable and accept the loss. Choose this only if the Script handles non-critical logic and the revenue impact is small. Disable the Script before June 30 so the failure is controlled (you see it coming) instead of silent (you find out from a customer complaint on July 1). Plan to ship a proper Function migration in Q3.

Path D - Hybrid. Choose this if you have a mix of Script types. Use a public app for the simple patterns. Build a Function for the complex ones. Disable the lowest-priority ones. This is what most Plus merchants with 5+ Scripts will end up doing.

Path A in detail - emergency Functions build

If you have engineering capacity and decided to build, here is the realistic 6-day plan.

Day 1 (Wednesday). Set up the Functions development environment. Install the Shopify CLI. Create a development store. Clone a Functions starter template from the official Shopify Functions documentation. Read the migration mapping for your specific Script type. Set up your local repo and CI.

Day 2 (Thursday). Translate your highest-priority Script into a Function. Functions are not Scripts with a new syntax. They are compiled WebAssembly modules using JavaScript or Rust. The mental model is fundamentally different. Test against synthetic carts in your development store.

Day 3 (Friday). Translate remaining Scripts. Run integration tests on all of them in the dev store. Compare every test case against expected behavior. This is where you find the edge cases the original Script handled implicitly.

Day 4 (Saturday). Deploy Functions to staging. Run synthetic orders through the entire checkout flow. Verify discounts apply correctly, shipping rates calculate, payment methods filter as expected. Document any behavior differences.

Day 5 (Sunday). Internal QA. Have your team place 10 to 20 test orders covering every Script-influenced scenario. Compare results against historical Script behavior. Fix any gaps.

Day 6 (Monday). Production cutover. Deploy Functions to production. Disable original Scripts. Monitor first 100 live orders carefully. Roll back if anomalies appear (rolling back is possible if you keep the original Scripts disabled but not deleted).

Tuesday June 30 should be a quiet day if Days 1 through 6 went well.

Path B in detail - public app bridge

For most merchants without engineering capacity, this is the right answer. The patterns to match.

• Buy X get Y discounts. Native Shopify discounts now cover the common cases. For complex BXGY logic, apps like Discount Ninja, Shopify Discounts Pro, or Bundle Builder Pro handle the patterns Scripts used to handle.
• Tiered volume pricing. Bold Quantity Breaks, B2B Wholesale Pricing, or similar. Maps 1-to-1 with most volume Script patterns.
• Customer-tier discounts. Native B2B catalogs (now available on all plans after Spring '26) handle this for B2B. For B2C tier discounts, Loyalty Lion or Smile.
• Conditional free shipping. Native Shopify shipping rules + Shipping Rates Calculator Plus. Or Intuitive Shipping for complex conditional logic.
• Restricted region shipping. Advanced Shipping Manager or Shipping Restrictions. Configures in 30 minutes.
• Hide payment methods. Hide Payment Methods Pro or HidePay. The pattern most Plus merchants need.

For each Script you have, find the matching app, install it, replicate the behavior, test in a single order, disable the Script. Budget 1 to 3 days per Script. Most apps cost $20 to $80 per month, which is materially less than emergency engineering time.

Path C in detail - disable and accept

If the Script handles low-revenue or low-criticality logic, disabling it now is better than letting it die silently on June 30. The reason is observability. You want to know the moment a Script-influenced flow breaks, not learn about it from a customer complaint two days later.

Before disabling, write down what the Script did. After June 30 you cannot read the Script Editor anymore. The knowledge of what the Script handled disappears with it unless you document it now.

If you go this route, schedule the proper Function migration for Q3. Block 2 weeks of engineering or agency capacity in August for the proper rebuild.

Path D in detail - hybrid

This is what most Plus merchants will actually do. The decision matrix.

• High-revenue + complex pattern → Path A (Function build). Worth the engineering investment.
• High-revenue + common pattern → Path B (app bridge). Get something live this week, build the Function in Q3 if needed.
• Low-revenue + complex pattern → Path C (disable). Cost of building a Function exceeds the revenue at risk.
• Low-revenue + common pattern → Path B (app bridge). Cheapest path to coverage.

Apply this matrix to each Script individually. Most merchants end up with 1 or 2 Functions, 2 or 3 apps, and 1 or 2 disabled Scripts that need a Q3 rebuild.

The Script patterns most likely to break the worst on July 1

Some Script patterns are more dangerous than others if they fail silently. Prioritize these.

Pattern 1 - Automatic sitewide discounts. If a Script applies an automatic discount on every order (sitewide 10 percent off, member discount, loyalty tier), its failure means every customer pays full price starting July 1. Loyalty cohorts will complain within hours. Refund volume will spike. Highest priority to migrate.

Pattern 2 - Conditional free shipping. If your free shipping threshold is implemented in a Script (rather than native Shopify shipping rules), customers will be charged shipping on orders that previously qualified for free shipping. Abandoned cart rates will spike. Customers who notice will email or chat. High priority.

Pattern 3 - B2B-specific payment method visibility. If you hide certain payment methods for B2B customers (cards visible for B2C, NET terms visible only for B2B), the failure means B2B customers see card payment options they were not supposed to see. Possible chargebacks or workflow confusion. Medium priority.

Pattern 4 - Region-based shipping restrictions. If you restrict shipping to certain regions via Script (no shipping to PO boxes, no APO/FPO, no certain countries), the failure means orders flow through to fulfillment that you cannot actually ship. Higher refund and customer service load. Medium priority.

Pattern 5 - Quantity-based volume discounts. The buy-10-get-15-percent-off type rule. Failure means high-volume customers pay full price. Same urgency as automatic sitewide but smaller cohort. Medium priority.

Pattern 1 is the one that wakes founders up at 2am on July 1. Make sure that one is covered first.

What happens at 12:01am on July 1

For stores with active Scripts at the cutoff, the failure mode is silent. Scripts simply stop executing. The checkout flow continues, but without the logic the Scripts were applying.

You will not get an error. No alert, no email, no warning banner in admin. The Script just stops running. Orders flow through with default behavior (no automatic discount, no custom shipping, all payment methods visible).

The first symptom is usually a customer complaint. "I expected a 15 percent discount and got charged full price." "Shipping was free yesterday and is $9 today." This is the worst possible discovery mechanism because it depends on the customer noticing.

The second symptom is a refund spike. Customers who paid full price for something that should have been discounted will request refunds, often through chargebacks. Plan for an elevated refund queue starting July 1 if any of your Scripts depend on revenue-influencing logic.

The third symptom is in your analytics. Compare conversion rate, AOV, and cart abandonment for July 1 to 7 against June 23 to 29. If you see a step-function change, a Script broke silently. Identify which one by cross-referencing what each Script did. You have 24 to 72 hours to triage before customer impact compounds.

The migration steps you should follow if you have time

For merchants reading this in time (before June 28), the textbook migration path is 8 to 14 weeks. Compressed to the absolute minimum, the steps are.

1. Inventory. List every Script. Document what each does.
2. Triage. Apply the decision matrix above.
3. Develop or install. Build Functions or install apps based on triage.
4. Test on a development store. Run synthetic carts through every scenario.
5. Stage on a duplicate of production. Run real-shaped orders through the new logic.
6. Deploy to production with Scripts still enabled. Confirm new logic works in parallel before disabling Scripts.
7. Switch over. Disable Scripts, monitor first 50 to 100 orders carefully.
8. Cleanup. Document everything. Update internal runbooks.

The full migration documentation lives at shopify.dev/docs/apps/build/functions/migrating-from-shopify-scripts. Read it once even if your engineering team is doing the work.

Why Functions is materially different from Scripts

This is a sidebar worth understanding before you build. Scripts ran in a sandboxed Ruby environment. They executed at checkout time and could read cart contents, customer data, and shipping options. Functions are different in three important ways.

Language. Functions are written in JavaScript or Rust, compiled to WebAssembly, and run in Shopify's core infrastructure. The Ruby code from your Script does not translate directly. You rebuild from the business logic, not from the code.

Runtime model. Functions execute at specific lifecycle points (cart validation, discount application, shipping calculation, payment customization). The model is more constrained than Scripts but more performant.

Deployment. Functions are deployed as part of a Shopify App, not edited in the Script Editor. This means you need an app shell (created via Shopify CLI), version control, and a deployment pipeline. The good news is once you have one Function shipped, adding more is fast. Our broader context on the platform shift is in our Spring 2026 Edition teardown.

What is Shopify Scripts and why is it being shut down?

Shopify Scripts was a legacy Ruby-based scripting environment available to Shopify Plus merchants that let them customize discount logic, shipping rates, and payment method visibility at checkout. Shopify announced its deprecation in 2023 and has confirmed the final sunset for June 30, 2026. The shutdown is part of Shopify's broader platform modernization, replacing Scripts with Shopify Functions (a WebAssembly-based runtime that runs JavaScript or Rust modules at specific commerce lifecycle points). Functions offer better performance, stronger security guarantees, and integrate with Shopify's modern app ecosystem in ways Scripts could not.

How do I check if my Shopify store has active Scripts?

Open Shopify Admin, go to Settings, then Checkout, and scroll to the Script Editor section. The Script Editor lists every active Script on your store. As of April 15, 2026, you cannot create or edit Scripts anymore but you can still view existing ones. Read each Script's name, description, and Ruby code to understand what it does. If your store does not show a Script Editor section at all, you have no active Scripts and the June 30 deadline does not affect you. If you find Scripts and you do not know what they do, ask your previous Shopify Plus Partner agency or any developer who has worked on your store. Document everything before June 30 because the Script Editor disappears after the cutover.

Can I extend the June 30 Scripts deadline?

No. The deadline has been extended twice already (originally August 2024, then August 2025) and Shopify has publicly confirmed June 30, 2026 is the final cutoff. There is no mechanism to request an extension, no enterprise SLA path that buys you more time, and no precedent of Shopify changing this deadline once finalized. Plan as if the deadline is hard, because it is.

What is the fastest way to replace a Shopify Script if I have 6 days?

For most Script patterns, installing a public Shopify App that replicates the behavior is the fastest path. App configuration takes 1 to 3 days per Script, compared to 5 to 10 days for a custom Function build. For common patterns (volume discounts, conditional free shipping, hiding payment methods, region-based shipping), apps like Discount Ninja, Intuitive Shipping, Bold Quantity Breaks, and Hide Payment Methods Pro cover the most common Script use cases. Match each of your Scripts to a matching app, configure to match Script behavior, test on a single order, then disable the original Script before June 30. This is path B in the decision tree above and the right answer for most merchants without engineering capacity.

What happens to my store if I do not migrate by June 30?

The failure mode is silent. Active Scripts stop executing at midnight on July 1. No error, no alert, no warning banner. Checkout continues to work, but without the logic your Scripts were applying. The first symptom is usually a customer complaint (lost discount, unexpected shipping charge, wrong payment options visible). The second is a refund spike from customers who paid full price for something that should have been discounted. The third is a step-function change in conversion rate, AOV, or cart abandonment that you only spot in analytics 24 to 72 hours later. For stores with revenue-influencing Scripts (especially sitewide automatic discounts), the cost of failing to migrate is often 5 to 15 percent of weekly revenue until you patch the gap.

Do I need a Shopify Plus Partner to migrate from Scripts to Functions?

It depends on your Scripts. Simple patterns (volume discounts, free shipping thresholds, hiding payment methods) can be replaced with public apps without any developer involvement. Complex patterns (custom B2B pricing rules, multi-condition discount logic, region-tiered shipping calculations) usually need a developer who can ship JavaScript or Rust in the Functions runtime. If you have a Shopify Plus Partner agency (or in-house engineering), brief them today. If you do not, the public-app route covers most needs without engineering. For complex custom logic with no engineering capacity and a tight deadline, the honest answer is to disable the Script, install a partial-coverage app, and schedule a proper migration in Q3 with a real Plus Partner.

What we would do this week

If we were running checkout for a Shopify Plus brand with unfinished Script migration work, here is the order of operations for the next 6 days.

Today. Run the 30-minute audit. List every Script. Triage with the decision matrix.

Tomorrow. For Path B Scripts (public app bridge), shortlist 2 apps per Script pattern. Read reviews. Pick one. Install on a dev store first if you can.

Day 3. Configure apps to match Script behavior. Test with 5 to 10 synthetic orders.

Day 4. Deploy to production with Scripts still enabled. Run real orders through. Compare against Script-only behavior.

Day 5. Disable original Scripts. Monitor first 50 orders. Roll back if anomalies.

Day 6 (June 29). Document everything. Write internal runbook. Brief team.

For Path A Scripts (Function build), the timeline is tighter and you should be doing the work in parallel with Path B preparation, not after. If you have not started a Function build today, Path A is almost certainly not going to ship by June 30. Default to Path B and plan Path A for Q3.

For deeper context on the broader Shopify platform direction, our guide on what autonomous commerce is in 2026 covers where the platform is going beyond the Scripts cutover.

If you want help running the audit, picking apps for specific Script patterns, or planning the Q3 Function migration, the ExactWhy team is happy to take a look. Most of the work in the next 6 days is unsexy app configuration and order-testing discipline. The brands that get through July 1 with no customer complaints and no revenue dip are the ones who did the dull work this week. The brands that wait will find out from a customer email on July 2.