Migrating Shopify Scripts to Functions
On this page
If your Shopify Plus store uses Scripts — the legacy way of writing custom discount, shipping, and payment logic — you have a migration to plan, because Shopify is replacing Scripts with Shopify Functions as part of its broader move to a modern extensibility model. This is closely related to the Checkout Extensibility migration (both are part of Shopify moving from older customization approaches to the modern, supported architecture), and like that migration, it’s work you didn’t ask for but that leads to a better, more robust, upgrade-safe foundation. If you used Scripts for custom commerce logic, that logic needs rebuilding as Functions, and doing it properly — especially given that Scripts often touch discounts and checkout, where mistakes cost money — matters.
This piece covers what Scripts were, what’s changing and why, what you need to migrate, the process, and how to approach it. A caveat upfront, as with the Checkout Extensibility discussion: Shopify has set and adjusted timelines for the Scripts-to-Functions transition, so verify the current deadlines and requirements in Shopify’s documentation rather than relying on any date here — this piece covers the shape of the migration and how to approach it, not a countdown. Let me walk through it.
What Shopify Scripts were
Shopify Scripts were a Shopify Plus feature for writing custom commerce logic — specifically custom discount logic, shipping logic, and payment customization — using Ruby scripts that ran in the checkout. If your Plus store needed custom discount rules, custom shipping logic, or payment customization beyond the standard options, Scripts were the legacy way to do it: a developer wrote a script implementing the custom logic, and it ran in your checkout. So Scripts were the older mechanism for the kind of custom commerce logic now handled by Shopify Functions (as the Functions discussion covers) — custom discounts, shipping, and payment logic, written as scripts.
If your Plus store has custom discount, shipping, or payment logic implemented via Scripts, that’s what’s affected by this migration — that legacy Scripts-based logic needs to move to the modern Functions approach. Stores that used Scripts for things like complex discount rules, custom shipping logic, or payment customization have this logic to migrate. Understanding what Scripts were (the legacy mechanism for custom discount, shipping, and payment logic) clarifies what the migration involves: moving your Scripts-based custom commerce logic to Functions. If you’re not sure whether you use Scripts, it’s worth checking (a developer can confirm), since if you do, you have this migration to plan; if you don’t (you never used Scripts for custom logic), this migration doesn’t apply to you. For stores that do use Scripts, the migration to Functions is the subject here.
What’s changing and why
What’s changing: Shopify is deprecating Scripts in favor of Shopify Functions, as part of its broader move to a modern extensibility model (the same move that brought Checkout Extensibility, replacing the older checkout.liquid and Scripts approaches with the modern, supported architecture). So Scripts are being retired, and the custom commerce logic they handled moves to Functions, the modern way of implementing such logic (as the Functions discussion covers). This is part of the same modernization that the Checkout Extensibility migration is part of — Shopify moving from older customization mechanisms (checkout.liquid, Scripts) to the modern extensibility model (Checkout Extensibility, Functions).
Why Shopify made the change is the same reasoning as Checkout Extensibility: the modern approach (Functions) is more robust, performant, supported, and upgrade-safe than the legacy approach (Scripts). Functions run on Shopify’s infrastructure in a more robust, performant, supported way, and they’re part of the modern architecture Shopify can keep improving — whereas the legacy Scripts were a less robust, harder-to-support older mechanism. So the change, while it’s work you didn’t ask for, leads to a better foundation: your custom commerce logic moves from the legacy Scripts to the modern, more robust, supported Functions, which is better (as the Functions discussion covers — Functions are capable, fast, and reliable). So like the Checkout Extensibility migration, the Scripts-to-Functions migration is modernization that’s beneficial despite being imposed: you’re moving your custom logic to a better, more robust, supported foundation. Understanding the change (Scripts deprecated for Functions, part of the broader modernization) and the reasoning (Functions are more robust and supported, a better foundation) frames the migration as worthwhile modernization, not just imposed work — though it is work to be done.
What you need to migrate and the process
What you need to migrate is your Scripts-based custom logic — your custom discount logic, shipping logic, and payment customization implemented via Scripts — rebuilt as Functions. So the migration involves taking each piece of custom commerce logic you implemented as a Script and rebuilding it as a Function, achieving the same (or improved) functionality in the modern approach. The process mirrors other careful migrations: inventory your Scripts (identify all the custom logic you have implemented as Scripts — the discount rules, shipping logic, payment customization), map each to a Function (plan how each Script’s logic will be rebuilt as a Function), rebuild the logic as Functions, test thoroughly, and deploy.
The inventory step matters — you need to know all the custom logic you have in Scripts, including any you’ve half-forgotten, so nothing is missed in the migration. The rebuild involves a developer implementing your custom logic as Functions (Functions are developer-built, as the Functions discussion covers). And the testing is crucial, because Scripts often touch discounts and checkout — the most conversion-critical, money-handling parts of your store — so the rebuilt Functions must be tested thoroughly to ensure the custom logic works correctly (the discounts apply right, the shipping logic works, the payment customization functions) before going live, since errors in discount or checkout logic directly cost money or break the checkout. So the migration process is: inventory your Scripts, map and rebuild each as a Function, test thoroughly (especially given the discount/checkout stakes), and deploy — the careful migration process appropriate to delicate, money-touching custom logic. This is developer work (Functions are developer-built), so if you have Scripts, you have or need a developer to handle the migration, ideally one experienced with Functions given the stakes.
How to approach it: don’t delay, don’t panic
The approach mirrors the Checkout Extensibility guidance: don’t delay it past the deadline, but don’t panic either. Don’t delay, because Shopify is deprecating Scripts on a timeline (verify the current deadline in Shopify’s docs), and leaving the migration to the last minute risks doing delicate discount/checkout logic work under time pressure, or worse, having your Scripts stop working before you’ve migrated. So plan the migration in good time rather than leaving it to a deadline scramble. But don’t panic either — for many stores, the Scripts-to-Functions migration is a manageable rebuild of a defined set of custom logic, not a crisis, especially with an experienced developer. The scope depends on how much custom logic you have in Scripts: a store with a couple of Scripts has a smaller migration than one with extensive custom logic.
So approach it calmly and promptly: find out what Scripts you have (inventory), check the current deadline (Shopify docs), plan the migration in good time, rebuild your logic as Functions with a developer (ideally one experienced with Functions), test thoroughly given the discount/checkout stakes, and deploy. This calm, prompt, thorough approach handles the migration well — you move your custom logic to the modern Functions foundation in good time, tested properly, without a deadline scramble or careless work on delicate logic. The two failure modes are the same as Checkout Extensibility: delaying past the deadline (forcing a rushed job on delicate logic, or having Scripts stop working) and panicking/over-complicating a manageable migration. The right posture is calm and prompt — plan it in good time, do it thoroughly, get it done before the deadline pressure. And given that this migration and the Checkout Extensibility migration are both part of the same modernization, they may be related or done together (a store migrating off checkout.liquid and Scripts is moving to the modern extensibility model overall), so consider them together if both apply, with a developer handling the modernization of your custom checkout and commerce logic to the modern approach.
A worked example: the discount logic migration
To make the migration concrete, picture a Plus store that used Scripts for a sophisticated discount structure — say, custom tiered discounts, a complex BOGO variation, and some conditional logic — implemented years ago as Ruby scripts running in the checkout. With Scripts being deprecated, this logic needs rebuilding as Functions. The store (with its developer) inventories the Scripts, confirming exactly what custom discount logic exists (including a couple of older rules half-forgotten), maps each to a Function, and rebuilds the logic as Functions.
The testing is where the care concentrates, because this is discount logic touching the checkout. The developer tests thoroughly: do the tiered discounts apply correctly at each tier, does the BOGO variation work as intended, do the conditional rules trigger right, do the discounts stack (or not stack) correctly, does it all work across payment methods and edge cases? Because errors in discount logic directly cost money (discounts applying when they shouldn’t, or not applying when they should) or break the checkout, this testing is essential before the Functions go live. Once tested and verified, the store deploys the Functions, retiring the Scripts, with its custom discount logic now on the modern, robust Functions foundation — and possibly improved, since Functions’ greater capability let the developer refine some of the logic that Scripts had constrained.
This captures the migration: a defined set of custom logic (the discount structure), inventoried, rebuilt as Functions, tested thoroughly given the money-touching stakes, and deployed — moving from the legacy Scripts to the modern Functions foundation, done carefully because discount/checkout logic errors are costly. The store didn’t panic (it was a manageable rebuild of a defined set of logic) nor delay (it planned it in good time before the deadline), and it took the opportunity to improve the logic on the more capable Functions. The worked example shows the migration’s shape — inventory, rebuild, thorough testing, deploy — and why the testing matters so much (discount/checkout stakes), illustrating the careful, calm, prompt approach the migration warrants.
Confirm whether this applies to you
A practical first step worth emphasizing: confirm whether you actually use Scripts, since this migration only applies if you do. Not every Plus store used Scripts — many never implemented custom discount, shipping, or payment logic via Scripts, in which case this migration doesn’t apply to you. So the first thing to determine is whether your store has Scripts-based custom logic: a developer can check, or you can review whether you have custom discount, shipping, or payment logic that was implemented via Scripts. If you do, you have this migration to plan (inventory, rebuild as Functions, test, deploy, before the deadline). If you don’t (you never used Scripts), this migration doesn’t apply, though you might still use Functions for new custom logic going forward (as the Functions discussion covers).
So before planning a Scripts-to-Functions migration, confirm it applies to you by determining whether you use Scripts — checking with a developer or reviewing your custom logic. This avoids both the worry of an inapplicable migration (if you don’t use Scripts, there’s nothing to migrate) and the risk of missing an applicable one (if you do use Scripts, you need to plan the migration before the deadline). For the stores this applies to (those using Scripts for custom logic), plan the migration as described; for those it doesn’t (no Scripts), there’s nothing to do here, though the Functions capability is available for future custom logic. Confirming whether you use Scripts is the practical starting point — determining whether this migration is on your plate at all, so you can plan it if it is, or set it aside if it isn’t. If you’re a Plus store and unsure, checking is worthwhile, since if you do use Scripts, the migration has a deadline you don’t want to miss.
The opportunity and the bottom line
As with Checkout Extensibility, the migration is an opportunity as well as imposed work: since Functions are more capable than Scripts (as the Functions discussion covers — Functions can do sophisticated custom discount, shipping, validation, and payment logic), rebuilding your logic as Functions is a chance to improve it, not just replicate it. If your Scripts-based logic was limited by Scripts’ constraints, or if you’ve wanted more sophisticated custom logic, the migration to Functions is the moment to build the improved or expanded logic the more capable Functions enable. So approach the migration not just as replicating your Scripts as Functions, but as an opportunity to improve your custom commerce logic on the more capable modern foundation — though, as with any migration, balance the opportunity to improve against the risk of over-expanding scope on delicate logic.
The bottom line: if your Shopify Plus store uses Scripts for custom discount, shipping, or payment logic, Shopify is replacing Scripts with Functions (part of its broader modernization, alongside Checkout Extensibility), so you have a migration to plan — rebuilding your Scripts-based custom logic as Functions. The change is beneficial despite being imposed: Functions are more robust, performant, supported, and capable than the legacy Scripts, so your custom logic moves to a better foundation. Approach it like the Checkout Extensibility migration: inventory your Scripts, check the current deadline (in Shopify’s docs, since timelines have been set and adjusted), plan and rebuild your logic as Functions with an experienced developer, test thoroughly (especially given that Scripts often touch discounts and checkout, where errors cost money), and deploy — calmly and promptly, not delaying past the deadline nor panicking over a manageable migration. Treat it as an opportunity to improve your custom logic on the more capable Functions, and consider it alongside the related Checkout Extensibility migration if both apply. Done well, your custom commerce logic moves to the modern, robust, supported, more capable Functions foundation, which is a genuine improvement, achieved through a careful migration appropriate to the delicate, money-touching logic involved. The migration is, in the end, modernization worth doing despite being imposed — and the stores that handle it well are the ones that confirmed early whether they use Scripts, planned the migration in good time, rebuilt and tested their logic carefully with an experienced developer, and treated it as a chance to improve their custom logic on the more capable foundation, rather than scrambling at a deadline or treating delicate discount and checkout logic carelessly. Approached that way, what could be a stressful imposed migration becomes a controlled move to a better foundation, leaving your custom commerce logic more robust, supported, and capable than it was on the legacy Scripts. And if it turns out you never used Scripts at all, then there’s nothing to migrate here — but it’s worth confirming that rather than assuming, since the deadline matters for the stores it does apply to. Either way, the practical first move is the same: determine whether you use Scripts, and if you do, plan the migration to Functions in good time, handled with the care that delicate, money-touching discount and checkout logic deserves. That clarity — knowing whether this is on your plate, and if so handling it calmly and thoroughly before the deadline — is what turns the Scripts-to-Functions transition from a potential scramble into a managed, beneficial modernization of your custom commerce logic.
Frequently asked questions
What are Shopify Scripts and what’s happening to them?
Shopify Scripts were a Shopify Plus feature for writing custom commerce logic — custom discount, shipping, and payment logic — as Ruby scripts running in the checkout. Shopify is deprecating Scripts in favor of Shopify Functions, the modern way of implementing such logic, as part of its broader move to a modern extensibility model (the same move that brought Checkout Extensibility, replacing the older checkout.liquid and Scripts approaches). So if your store uses Scripts for custom logic, that logic needs migrating to Functions.
Why is Shopify replacing Scripts with Functions?
The same reasoning as Checkout Extensibility: the modern approach (Functions) is more robust, performant, supported, and upgrade-safe than the legacy Scripts. Functions run on Shopify’s infrastructure in a more robust, performant way and are part of the modern architecture Shopify can keep improving, whereas Scripts were a less robust, harder-to-support older mechanism. So the change, while imposed, moves your custom logic to a better, more capable foundation — beneficial modernization, not just busywork.
What does migrating Scripts to Functions involve?
Inventory your Scripts (all the custom discount, shipping, and payment logic you have implemented as Scripts, including any half-forgotten), map each to a Function (plan how each Script’s logic will be rebuilt), rebuild the logic as Functions (developer work), test thoroughly, and deploy. Testing is crucial because Scripts often touch discounts and checkout — the money-handling, conversion-critical parts — so the rebuilt Functions must be tested to ensure the logic works correctly before going live, since errors in discount or checkout logic directly cost money or break checkout.
How urgent is the Scripts to Functions migration?
Don’t delay it past Shopify’s deadline (verify the current timeline in Shopify’s docs, since they’ve been set and adjusted), because leaving it late risks rushing delicate discount/checkout logic or having Scripts stop working before you’ve migrated. But don’t panic either — for many stores it’s a manageable rebuild of a defined set of custom logic, not a crisis. Plan it calmly and promptly: inventory your Scripts, check the deadline, rebuild as Functions with an experienced developer in good time, test thoroughly, and deploy — ideally alongside the related Checkout Extensibility migration if both apply.