Shopify Scripts and the Script Editor app retired on 30 June 2026. Shopify's current extensions and functions guide confirms that old Scripts no longer run. The useful question now is which business rules your store still needs, and what currently implements them.
Start with the behaviour you can verify. A copy of an old Script explains an earlier intention; your current app configuration and customer journeys establish what happens today. A store might already have a replacement, a changed requirement or an uncovered gap. Establish that before commissioning more code.
Make one row for every required rule
Bring retained code, any exported Scripts customisations report, app settings and accepted order examples. Record the rule, its owner, its conditions and the expected result. Include exceptions such as combined discounts, customer groups, currencies and unavailable delivery methods.
| Business requirement | Replacement to investigate | Evidence to agree |
|---|---|---|
| A qualifying product, order or shipping discount | Native configuration or an app using the Discount Function API | Eligible and ineligible examples, combination rules and the expected amount |
| A delivery option should be hidden, renamed or reordered | Delivery Customization, with the required input data available | The option list for representative addresses and carts |
| A payment method should change for a defined customer or order | A compatible payment customisation solution | The relevant payment options and the supported checkout surface |
The current Discount API can address product, order and shipping discounts. Delivery Customization handles delivery-option presentation. Treat a change to shipping price and a change to option visibility as distinct requirements.
Choose the smallest suitable implementation
Compare existing configuration, a maintained public app and a custom app against the same examples. Shopify's Functions availability documentation distinguishes public App Store apps containing functions from custom apps: public apps can generally serve any plan, subject to individual API restrictions; custom apps containing Functions require Shopify Plus. Confirm the specific API, plan and checkout-surface support.
A new custom app needs an owner for configuration, supported API versions, releases and troubleshooting. A public app needs a named vendor, a verified fit and an understood subscription. Price the work from that actual choice and its dependencies rather than a standard migration estimate.
Agree how a replacement earns release approval
- Write expected outcomes. Use approved sample carts and customer situations, including a case where the rule should not apply.
- Check interactions. Review other discounts, delivery rules, subscriptions and accelerated checkout where relevant. The API's compatibility table is part of the decision.
- Review evidence before release. Record the tested configuration and the business owner's acceptance. Protected checkout and payment work needs explicit scope and approval.
- Name the ongoing owner. Agree how issues are reported, what is monitored, when changes are reviewed and what happens when an app or API changes.
Use delivery proof and an agreed care scope
Our 12 Boards case describes catalogue consolidation, landing pages and redirects. It shows the value of explaining delivered work precisely. For a checkout review, ask for evidence tied to your own rules and accepted examples.
Shopify Plus planning and ongoing Shopify maintenance can help define ownership. Snowball work follows agreed priorities, capacity, timing and approvals. Custom app engineering and checkout or payment changes need their own agreed scope. Monitoring coverage and response arrangements should be specified, with each authorised fix checked after release.