The Shopify Scripts deprecation is 16 days away. Here’s a triage playbook.

If you’re a Shopify merchant (or running migrations for one) and your Scripts haven’t moved to Functions yet, this post is for you. The June 30, 2026 deadline isn’t moving. You have a little over two weeks. Here’s how to triage what’s left.

I’m the developer of PayLogic, a Shopify Functions app that replaces payment-customization Scripts. Most of the migration patterns described below come from reading a steady stream of merchant Scripts while building the parser, and from threads in the Shopify Plus community over the last few months. The framework here is migration-path-agnostic — useful whether you migrate yourself, hire it out, or use an app.

Why this is happening, briefly

Shopify Scripts (Ruby, server-side, per-checkout) is being replaced by Shopify Functions (Rust or JS compiled to WASM, deterministic sandbox). Functions have better performance, better security, and stricter resource limits.

The deprecation has been announced since 2023. Most merchants who used Scripts have already migrated. The ones who haven’t typically fall into three buckets:

1. They forgot. Scripts run silently and reliably. Out of sight, out of mind.
2. They lost the dev. The person who wrote the Scripts left the company a year ago. Nobody on the team can read the Ruby.
3. They thought the deadline would slip. It won’t.

If you’re in any of these, read on.

What actually breaks on July 1

There’s no banner. No email. No grace period. At 00:00 UTC on July 1, 2026, in concrete terms:

• Your Scripts stop executing. Whatever logic they ran at checkout (hide COD, hide express checkout in specific countries, rename payment methods, reorder, surcharge math, custom shipping rules) — none of it runs.
• Your existing payment gateways all reappear in their default state. If you were hiding Cash on Delivery for risky customers, it shows for everyone. If you were hiding express checkout in Saudi Arabia, it appears in Saudi Arabia.
• You won’t find out from Shopify. You’ll find out from an RTO spike, a customer report, or a fraud-rate alarm.

This isn’t a “things will break loudly” deadline. It’s a “things will silently misbehave starting July 1” deadline. The merchants who get blindsided are the ones who assume they’ll get a warning.

Step 1 — Inventory your Scripts (today)

Shopify admin → Apps → Scripts editor. List every Script currently running. For each one, capture:

• Title and trigger (Payment, Shipping, or Line Item)
• Full Ruby source (copy into a doc)
• Active/inactive status
• Last-modified date

If you’re on Plus but the Scripts editor isn’t visible, verify with the Admin API:

curl -X GET "https://your-shop.myshopify.com/admin/api/2024-04/scripts.json" \
  -H "X-Shopify-Access-Token: $ADMIN_TOKEN"

Time budget: 30 minutes. If you’ve never opened the Scripts editor and you’re not sure if you have any, this step is non-optional.

Step 2 — Categorize each Script

Read each one and put it in one of four buckets.

Bucket A — Trivial translation

Maybe 60% of Scripts I read fall here. Simple conditional logic on cart state:

if Input.cart.subtotal_price.cents > 100_00
  Output.cart.payment_gateways.each do |g|
    g.disable if g.name.include?("Cash on Delivery")
  end
end

Translates cleanly to a single payment-customization Function with one IF condition and one HIDE action. Whether you write the Function yourself or use a rule builder, the result is identical.

Bucket B — Multiple rules combined

Multiple conditions chained, or multiple actions in one Script:

unless Input.cart.customer&.tags&.include?("vip")
  if Input.cart.subtotal_price.cents > 100_00
    Output.cart.payment_gateways.each do |g|
      g.disable if g.name.include?("Cash on Delivery")
    end
  end
end

Still mechanical translation, but you need to be precise about logical operators (AND vs OR), null-safe customer access (some buyers are guests), and operator precedence. A skilled dev or a competent rule builder handles this; a panicked junior dev gets it subtly wrong.

Bucket C — Custom math or behavior Functions don’t support

Payment Customization Functions intentionally do less than Scripts did. Specifically:

• No surcharges (you can’t ADD an amount via PaymentCustomization)
• No payment-method creation (hide / rename / reorder existing only)
• No modification of cart line items at the payment step
• No reading shop-level metafields or external data without an explicit input query

If your Script does any of these, the Function platform can’t replicate it as-is. You need:

• A workflow rebuild (often the right call — many surcharge Scripts existed to compensate for behaviors Shopify now supports natively)
• A different Shopify primitive (Cart Validation Function, Discount Function, or Delivery Customization Function depending on what the Script does)

Bucket D — Touches data Functions can’t access

Functions run in a deterministic sandbox with a strict input query. If your Script reads things like:

• A third-party API at checkout
• Shop metafields not part of the Function input
• Customer order history via the Admin API
• Live shipping-rate quotes from a carrier

…you can’t replicate it directly. Workarounds:

• Cache the relevant data into a metafield via a webhook (Function reads metafield instead of fetching live)
• Move the logic to a webhook-driven order workflow (different latency/UX profile)
• Build a custom backend that hooks into the order lifecycle

Bucket D is the hardest. If most of your Scripts are here, 16 days might not be enough. Plan accordingly.

Step 3 — Pick a migration path per bucket

For Bucket A

Three paths in order of effort:

A1: Use a payment-customization app. Apps with Scripts importers translate Ruby to visual rules automatically. For Bucket A logic, the import is one click. Cost: $2–$10/mo, ongoing.

A2: Write the Function yourself. Shopify’s Functions docs walk through it. Install Shopify CLI, scaffold a Function, write the logic in Rust or TypeScript, deploy. Cost: a few hours, zero ongoing.

A3: Hire it out. Agencies bill $500–$2,000 for a Bucket A migration. Reasonable if you don’t have dev capacity.

For 1–3 simple rules, A2 is fine. For more — or if you’ll need to edit rules later without a dev — A1 wins because you get a UI.

For Bucket B

Same three paths, but the cost of A2 doubles (more time, easier to get wrong). I’d skew toward A1 here unless you have a strong Shopify dev on staff.

For Bucket C

Workflow rebuild. Talk to a Shopify Plus partner agency. Don’t expect to migrate as-is — the platform won’t let you, so the rebuild is the work.

For Bucket D

Same. Find an agency that does Functions + custom backend. There aren’t many. Reach out today.

Step 4 — Test in a draft order (every time)

Before you flip anything live, test in a draft order. This is the step most merchants skip and the one that produces the “wait, it broke” tickets in July.

The discipline:

1. List the 5 most common checkout scenarios in your store: new customer + low cart, returning customer + high cart, international shipping, COD-eligible region, VIP customer. Whatever maps to your business.
2. After implementing the migration, place a draft order for each scenario. Use the Shopify draft-order tool, set the customer, set the cart, place it without charging.
3. Verify the checkout behavior matches what the Script used to do.
4. If anything’s different, fix and re-test.

Critical gotcha: if you have OTHER customizations layered on top of your Scripts (checkout.liquid edits, Shopify Flow workflows, third-party payment apps), the post-migration behavior may combine differently than expected. Test the combined behavior, not just the migrated rule in isolation.

Step 5 — Schedule the cutover

You want the migrated Function live BEFORE June 30, not on June 30. Specifically:

• Deploy the migrated Function (or app) at least 5 days before the deadline.
• Disable the old Script when the new system is live. Don’t run both — Scripts win as long as enabled.
• Test the live behavior in production with a real test order.
• Monitor checkout for 48 hours after cutover. Anomaly? Roll back to Scripts (still works until June 30) and fix.

If you wait until June 29 to flip the switch, you have no rollback window. Don’t.

What if you genuinely can’t make the deadline

Realistic backup plans:

Plan 1: Disable Scripts proactively, accept temporary degradation. Better to know your COD-hiding logic isn’t running than to be surprised on July 1. Disable July 1 morning, manually. Customers see default behavior until the migration ships. You’ll know exactly what you’re sacrificing.

Plan 2: Ship a minimum viable Function for the highest-stakes Script. If your Scripts span 5 use cases but only 1 of them (hiding COD on risky orders, say) actually moves business KPIs, migrate just that one. Let the other 4 lapse. Backfill later.

Plan 3: Use an app for an emergency import. Most payment-customization apps have a Scripts importer. Install one. Click import. You’ll have a passable migration in under an hour. Might not perfectly replicate every nuance, but it’ll restore ~90% of the behavior. Refine later.

Don’t pretend you’ll be fine. Pick a backup plan now.

Final 16-day calendar

If you’re reading this with the deadline 16 days out, here’s the cadence:

When	What
Today (weekend)	Open the Scripts editor, inventory everything, categorize into four buckets.
Monday–Tuesday	Pick a migration path per bucket. Start the work for Buckets A and B.
Wednesday–Friday	Test in draft orders. Identify gotchas. Fix and re-test.
Following Monday (June 22)	Deploy to production. Disable old Scripts. Monitor.
June 22–25	Buffer days for the inevitable surprises.
June 29	Final verification. Place a real-money test order, confirm the migrated behavior, breathe.
June 30	No action needed. You’re done.

A pitch (skip if not interested)

I built PayLogic as a payment-customization Functions app specifically for the 60–70% of merchants in Buckets A and B above. The Scripts importer pastes Ruby into a textarea, parses it, shows you the visual rules it detects, and one-clicks them live.

There’s a free standalone in-browser converter at paylogic.dev/scripts-converter if you want to see what your Scripts translate to without installing anything. No signup, no email capture.

The app costs $1.99–$9.99/mo depending on the feature set. The cheapest tier covers basic hide/rename/reorder; the most expensive includes a risk-composite rule and a customer-prior-risk rule (the latter reads Shopify’s native order-risk signal from a customer’s previous orders to auto-hide COD for known-risky returning shoppers — particularly useful for COD-heavy markets fighting return-to-origin losses).

If PayLogic doesn’t fit your use case, the converter is still free and the framework above is migration-path-agnostic. Use whatever ships you by June 30.

One last thing

If you’re an agency: the merchants you’ve handled are unlikely to all migrate before the deadline. Some will miss it. Some will be silently broken on July 1 and not notice for weeks. Reach out to them now, even if your last engagement was a year ago. The deadline is your reason to re-establish contact, and most agencies aren’t doing it.

Good luck. The next 16 days matter.