Shopify Scripts are not approaching end of life. They have already stopped running. Shopify sunset Scripts on June 30, 2026, and any Scripts that were still published were deactivated.
That changes the immediate decision for a store that relied on line item, shipping, or payment scripts. The question is no longer whether to migrate. It is which behavior still matters, which Shopify Function API can reproduce it, and whether the replacement should be a ready-made app or a custom build.
Shopify’s current migration guide says the Script Editor remains available in read-only mode until July 30, 2026. If you still need the original source as a reference, preserve it now.
Start with the behavior, not the Ruby code
A Script often contains several business decisions in one file: product eligibility, customer segmentation, price changes, discount-code handling, shipping-method rules, or payment restrictions. Rebuilding the file line by line can carry obsolete assumptions into the replacement.
Inventory each active behavior instead:
- What customer or cart condition triggers it?
- What data does the rule read?
- What change does the customer see?
- Where does that change happen in the purchase flow?
- Is the rule still commercially necessary?
- Which orders prove that the replacement is correct?
Shopify’s Scripts customizations report lists detected payment, shipping, and product-discount customizations and points to relevant Function documentation or compatible apps. Use it as an inventory, then compare it with the actual source and current business rules. A detected customization is not automatically a requirement worth keeping.
Which Shopify Function replaces each Script?
Shopify does not provide one universal replacement API. Its official mapping separates the old Script types by the operation they perform:
| Existing Script behavior | Shopify Function API | Intended replacement |
|---|---|---|
| Change product or cart pricing | Discount API | Product, order, or delivery discount logic |
| Merge, expand, or update cart lines | Cart Transform API | Bundles and cart-line presentation |
| Reject an invalid cart or checkout | Cart and Checkout Validation API | Server-side purchase rules |
| Hide, rename, or reorder delivery methods | Delivery Customization API | Delivery-option presentation |
| Discount delivery | Discount API | Shipping discount logic |
| Hide, rename, or reorder payment methods | Payment Customization API | Payment-option presentation |
The mapping comes from Shopify’s migration reference. One line item Script can therefore become more than one Function. A script that changes a price and blocks an invalid combination belongs partly in Discounts and partly in Cart and Checkout Validation.
This is the first important scope check. If no available Function API exposes the input or operation that a rule needs, changing programming language will not solve the gap. Confirm the contract in the current Function APIs reference before estimating the work.
Choose among three replacement paths
Retire the customization
Remove a rule when the promotion has ended, the affected product no longer exists, Shopify now handles the case natively, or nobody can explain why the rule remains necessary. Retirement still needs an owner and a checkout test; otherwise an undocumented dependency may disappear with it.
Install an app built on Shopify Functions
An existing app is usually the lower-maintenance choice for a common requirement such as a standard discount, delivery-method rule, or payment-method rule. Evaluate the app against the exact conditions and outcomes in your inventory rather than its feature list.
Shopify says stores on any plan can use public App Store apps that contain Functions, except where an individual Function API has narrower availability. Check pricing, configuration limits, support, data access, and uninstall behavior before treating an app as a direct replacement.
Build a custom Shopify Function
A custom build is more defensible when the rule is specific to the business, combines store-owned data in a way generic apps cannot express, or needs a merchant interface tailored to an internal workflow.
Availability matters: Shopify states that only Shopify Plus stores can use custom apps containing Shopify Function APIs. Some individual capabilities also have plan restrictions. Scripts themselves were a Plus feature, but the replacement architecture still needs to be checked against the store’s current plan and the selected API.
Custom does not mean copying Ruby into a new folder. It means owning an app, Function extensions, configuration, deployment, testing, API-version updates, and ongoing support.
Why Functions are not a direct port of Scripts
Shopify Functions run as WebAssembly modules inside Shopify’s backend. A Function receives data selected by a GraphQL input query and returns a structured list of operations for Shopify to apply. Shopify invokes it at the relevant point in the commerce flow; a store does not call it directly by URL.
Shopify provides templates and libraries for Rust and JavaScript, while its documentation strongly recommends Rust for performance on large carts. The right choice depends on the cart size, logic, team capability, and measured resource use—not on which language looks closest to the old Ruby source.
The execution model creates several design constraints:
- each Function API defines the data that can be requested and the operations that can be returned;
- execution order matters because cart transforms, discounts, delivery customizations, payment customizations, and validation run at different stages;
- Functions have input, output, binary-size, memory, and instruction limits;
- randomness and clock-based logic are not allowed;
- network access is limited, so external data may need to be synchronized into metafields or passed through supported cart data.
These are platform rules documented in Shopify’s Function APIs overview and limitations. They are reasons to redesign the data path before implementing the rule.
A practical migration sequence
The following sequence is a MerchWeave recommendation, not a Shopify requirement.
1. Preserve and classify
Save the source and customization report while they remain accessible. Split every rule into discount, cart transformation, validation, delivery, or payment behavior. Mark each one as retire, replace with an app, or custom build.
2. Define acceptance cases
Create a small test matrix from real store conditions. Include the products, customer state, market, currency, discount combination, shipping address, delivery option, and payment method that can change the result. Record both the expected checkout behavior and an order or scenario that demonstrates it.
3. Confirm API and plan fit
For every custom rule, verify that the selected Function API exposes the required inputs and output operation. Check plan availability and current resource limits. Resolve any gap before writing production code.
4. Build and test in a development store
Test normal, boundary, and failure cases. Compare the outcome with the acceptance matrix rather than with the old implementation structure. A technically valid Function is not a successful migration if totals, labels, eligibility, or checkout blocking differ from the intended rule.
5. Limit production exposure
Shopify’s migration guide recommends targeting tagged test customers before enabling a Function for everyone. This is useful for production validation, but there is an important post-sunset consequence: while the Function is restricted to testers, untagged customers receive none of that customization because the old Script no longer runs.
Keep this phase short. Use it to verify the production configuration and representative checkouts, not as an indefinite parallel rollout.
6. Enable, observe, and document
Remove the test condition, activate the Function configuration for the intended audience, and monitor the first relevant orders. Document where merchants change settings, who owns the app, how it is deployed, which API version it targets, and how to disable the customization safely.
What to prioritize if Scripts were still active at sunset
Start with rules that can change money or prevent an order:
- product and order discounts;
- shipping discounts and delivery-method eligibility;
- payment-method restrictions;
- cart validation and bundle behavior;
- cosmetic renaming or reordering.
This order is not universal. A payment restriction tied to fraud or contractual terms may outrank a discount. The useful principle is to rank each missing behavior by customer harm, financial exposure, compliance impact, and order volume.
Do not rebuild everything under one emergency deadline if a standard app can safely restore a common rule. Conversely, do not force a store-specific policy into a generic app whose configuration cannot express or test it.
The decision in one sentence
Retire rules with no current owner or value, use a Function-based app for a standard requirement it can reproduce exactly, and build a custom Function when the behavior is specific, supported by the relevant API, and worth owning as software.
If your checkout lost Scripts-based behavior or you need a scoped replacement plan, request a Shopify Functions migration consultation. MerchWeave’s Shopify development service covers custom apps, extensions, integrations, and backend logic.