The deadline, stated plainly
Shopify Scripts editing and publishing locked on April 15, 2026 — already passed. All Scripts stop executing on June 30, 2026. After that date, any tier pricing, BOGO, or line-item logic that lived in a Script returns full retail at checkout. There is no grace period and Shopify has stated this date will not move again. Our full migration checklist covers the non-pricing Scripts too; this post is specifically about tier pricing.
What Scripts did for tier pricing
For tier pricing, a line-item Script read the customer's tags (or order attributes) in the checkout and rewrote each line price: wholesale tier gets price A, VIP gets price B, quantity 12+ gets price C. It was Plus-only and it ran server-side, which is why it held through checkout and Shop Pay. Whatever replaces it has to do the same thing in the same place — inside Shopify's pricing pipeline, not in the theme.
The replacement options
Option 1: Native Shopify Functions (build it yourself)
Functions are the official successor: compiled modules that run inside checkout, available on Basic, Shopify, and Advanced plans, not just Plus. For a developer, a Discount Function or Cart Transform Function can reproduce tier pricing. This is the right route if you have engineering capacity and want to own the code. The cost is build and maintenance time: you are writing, testing, and versioning WebAssembly logic, and re-testing it every time Shopify ships pricing-pipeline changes.
Option 2: A Functions-based pricing app
Most merchants don't want to maintain a Function. A Functions-based app gives you the same engine with a rules UI on top: define "tag → tier price" without code, and the app handles the Cart Transform and the App Proxy price display. This is the practical replacement for the typical tier-pricing Script. The migration question becomes which app, and the comparison is in the wholesale app comparison.
Option 3: Native discounts (only for simple cases)
If your "tier pricing" was really one flat percentage for one group, Shopify's native automatic discounts may cover it without an app at all. Be honest about whether that's your case. Native discounts struggle with per-variant fixed prices, multiple standing tiers, and quantity ladders stacked per group — the things real tier pricing usually needs.
What tier pricing specifically needs from a replacement
Tier pricing is not a single discount; it is a standing price book per customer group. A replacement has to handle:
- Per-group prices driven by customer tag, more than three groups if you have them (native B2B caps at 3 catalogs off Plus).
- Fixed price or percent per tier, with quantity breaks stacked on top.
- Per-variant resolution, so multi-size SKUs price correctly.
- Cart + Shop Pay + draft order + refund parity. Scripts had this for free because it ran server-side. A theme-code "replacement" does not, and that is the most common migration mistake.
How to migrate tier logic safely
- Inventory the Script. List every tier, every tag, every quantity break, every product or collection it touches. This is your acceptance test.
- Rebuild the rules in Functions or a Functions-based app on a development store.
- Parallel-test each tier: log in as a tagged customer, add to cart, open Shop Pay, place a draft order, issue a test refund. Confirm the number matches the old Script everywhere.
- Cut over before June 30. Because editing is already locked, you cannot tweak the old Script during the transition — so the new path has to be verified independently, not compared live against an editable Script.
Most tier-pricing migrations are an afternoon of rule setup plus a one-to-two-week parallel run. The risk is not effort; it is shipping a display-only "fix" and finding out at checkout.
Honest recommendation
If you have a dev team and want to own it: native Functions. If you want the engine without maintaining code, and especially if you run more than three tiers or a hybrid DTC + wholesale + subscriber store: a Functions-based app. If your tier pricing was genuinely one flat discount: native discounts, no app. TagTier is built for the second case — Functions-native from day one, no Scripts dependency, with an audit log and one-click rollback so a bad rule is a click to undo, not a screenshot from an angry buyer.
Rebuild your tier pricing on a dev store →