If your store or your client's store still relies on Shopify Scripts, the clock is ticking.
Shopify says merchants could no longer edit or publish new Scripts after April 15, 2026, and that all Shopify Scripts will stop executing on June 30, 2026. That is the operative deadline. If a store is still depending on Script-based pricing, shipping, or payment logic after that date, those customizations will not keep running.
This affects a specific group of merchants. Shopify Scripts and the Script Editor app are available only on Shopify Plus, and Scripts fall into three main types - line item, shipping, and payment. Those scripts have often been used for the kind of checkout logic that merchants customize, such as discounts, shipping method changes, shipping discounts, and payment gateway rules (hiding or reordering options).
There is also a detail worth calling out - the Script Editor app is no longer available for download from the Shopify App Store. That matters less to stores already running Scripts than it does to teams that discover halfway through an audit that they assumed a fresh store or staging setup could just recreate the old workflow as is. Shopify makes it clear that existing Scripts need to be transitioned to compatible Shopify Functions replacements or apps.
A lot of merchants are seeing this as a code migration. That IS part of it, but it is rarely the whole story. Older Scripts often contain years of checkout decisions that no one has written down anywhere else - such as bundle pricing, shipping incentives, preferred gateways for certain orders, and workarounds for edge cases. In practice, this deadline can also double as a 'business rules audit'.
Start With The Customizations Report Before The Rewrite
Shopify's own recommendation is to begin with the Shopify Scripts customizations report. In Shopify admin, that report shows the Scripts customizations active in your store and surfaces documentation or app links that can help recreate them with Shopify Functions. The report can include the customization name, description, source file links, relevant Function tutorials, and recommended apps built on Shopify Functions. It can also be exported as CSV.
That's important because it gives merchants a better starting point than opening something like old files and trying to decipher them line by line. Shopify also makes a second point on the same page that many teams should take seriously. If there is a customization in the report that you no longer use, you do not need to recreate it. The deadline does not require merchants to preserve every old rule out of habit. It requires them to preserve only the rules still needed.
That is where this project gets more interesting than it appears. A merchant can come out of the report with three very different buckets - logic that should be rebuilt carefully; logic that can be replaced by an existing app; and old logic that should probably be retired.
This Is Also A Good Time To Separate Checkout Deprecations
One place merchants get tripped up is by lumping several Shopify checkout changes into one mental bucket. Shopify Scripts have their own June 30, 2026 end date. checkout.liquid is a separate story. Shopify's checkout.liquid documentation says it is already unsupported for the Information, Shipping, and Payment steps, and that checkout.liquid, additional scripts, and script tags for the Thank you and Order status pages were sunset on August 28, 2025. Shopify also notes on that page that Shopify Scripts continue to work alongside Checkout Extensions until June 30, 2026.
That distinction is worth pointing out because stores often talk about "checkout migration" as if it were one thing. It's not. Some teams have already dealt with checkout.liquid work and still have Script-based discount, shipping, or payment behavior running underneath. Others have kept checkout customization conversations on hold and now need to break the work into the correct pieces.
App Replacement & Custom Rebuilds Are Not The Same Job!
There's two broad routes for recreating Script-based customizations - install an app built on Shopify Functions, or build your own solution using Shopify Functions. The customizations report is meant to help with that decision by pairing detected customizations with recommended apps and Function guidance.
For some, the app route will be enough. If the current Script is doing something common - ie straightforward discounting logic, shipping adjustments, or payment customization that already exists in the app ecosystem - then a merchant may be able to replace the old Script without commissioning a new custom build.
For others, the problem will be more specific. A Script that reflects years of pricing exceptions, shipping logic for unusual order mixes, or payment gating tied to operational uses may need a custom rebuild. Functions-based custom apps must be created through the Partner Dashboard and connected to the store, because custom apps created directly in Shopify admin do not support Shopify App Bridge.
There is another reason not to treat Functions as a like-for-like code port. Functions is a newer customization model with app-based distribution, local development and testing, and faster execution. The WebAssembly platform behind Functions executes code in under 5 milliseconds, and that Functions reduce timeout and CPU memory limit issues compared with Scripts. Functions are configured in admin alongside other features, which means merchants do not have to work with raw code when changing those customizations.
That does not mean every migration will be simple. However, it does mean the end state should be better than 'old Script, new deadline'.
One Practical Advantage - You Can Test Before The Cutover
This is the part many of you will want to hear!
Scripts and Functions can be used in the same store at the same time until June 30, 2026. The developer migration tutorial goes further and shows a way to test new Function logic in production without disrupting customers. Shopify's example uses customer tags such as TESTER so tagged users experience the new Function behavior while other users continue to run through the existing Script behavior. You should, however, verify that the Function behaves identically before removing the testing logic and deactivating the Script.
That is worth building your plan around. A lot of avoidable migration pain comes from trying to do everything in one release window. So - identify the Script behavior, map it to the right Function path, test it in development, test it in production for a limited set of users, then remove the old Script when the replacement is proven.
For Shopify merchants, June 30 doesn't have to be a last minute scramble. It does, however, mean the work needs to start while there is still enough time to test properly.
Still Running Shopify Scripts?
If pricing rules, shipping logic, or payment customizations are buried in old Scripts, we can help map, choose the right replacement path, and rebuild the parts that should not disappear on June 30th, 2026.
What Merchants Should Review Now
The fastest way to lose time on this project is to treat it as a single item called "migrate Scripts". A better review starts with the actual behaviours running in the store.
- First, review what is active now. Shopify's Scripts documentation and customizations report make it possible to break existing behavior into line item, shipping, and payment use cases. That gives you a cleaner inventory than a general list.
- Second, review what each Script is still doing for the business. If a Script controls a live promotion, modifies shipping options, discounts shipping rates, or hides or reorders payment gateways, that behaviour needs an owner on the merchant side as well as a migration path on the development side. If no one can explain why a rule exists, that is usually a sign the logic needs a closer look before it is rebuilt.
- Third, review where the replacement belongs. Some behaviors can be replaced by an existing app. Some belong in a custom Function build. Some others may need surrounding integration work, especially if the old Script has become part of a broader checkout or operational workflow. For those dealing with the last category, this usually turns into the kind of cleanup and rebuild work that sits closer to custom APIs and integrations than a quick theme tweak.
- Fourth, review your testing window. Functions can be tested alongside Scripts and that tagged users can be used to validate new behavior safely in production. That should shape the project schedule. Leave time for side-by-side testing, verification, and rollback decisions rather than saving every change for the final week.
Our Take
The merchants who will handle this best are the ones who use the deadline to clean up old checkout logic with some discipline.
That means deciding which rules still earn their place, which ones can move to a maintained app, and which ones deserve a proper rebuild because they are tied to how the store actually sells, ships, or gets paid. Shopify has given merchants a migration path, a report to start from, and a testing model that avoids blind cutovers. That is enough to make this manageable, but only if the work is treated as a review of live business logic.
While June 30, 2026 is the platform deadline, the more useful date for Shopify merchants is the one on which they finish identifying what their store still needs.
