Checkout extensibility: what to migrate first

If you’ve been putting off the move from checkout.liquid to Checkout Extensibility, this is the post for you.

The deprecation timeline is no longer hypothetical: Shopify Plus stores must complete the migration to keep getting platform updates, and Standard / Advanced stores already lost checkout.liquid editing entirely. The question isn’t whether to migrate — it’s what to migrate first so you don’t break your checkout while doing it.

Here’s the order we use on every project.

1. Inventory what you actually have

Before you migrate anything, list every customization in your current checkout. We use a four-column spreadsheet:

What	Where	Why	Owner
Trustpilot widget	Above order summary	Social proof	Marketing
Custom delivery date picker	Shipping step	Operational requirement	Ops
GA4 enhanced ecommerce	All steps	Analytics	Marketing
Hide PO Box for fragile items	Shipping step	Carrier rule	Ops

The point of the inventory: most stores think they have 3 checkout customizations. They actually have 8. Find them all before you migrate any.

2. Migrate the analytics layer first

Move analytics off additional-scripts and onto Web Pixels before you touch anything visual. Why first?

• It’s invisible to shoppers — zero conversion risk.
• It teaches your team the new pattern (sandboxed events, the analytics API).
• It unblocks the visual changes — you’ll have working analytics before, during, and after.

Shopify’s standard events give you checkout_started, checkout_address_info_submitted, checkout_shipping_info_submitted, checkout_completed, and payment_info_submitted out of the box. For most stores, that replaces 80% of what you were doing in additional-scripts.

3. Move “informational” UI changes next

Banners, trust badges, custom messaging, social proof widgets — all of these belong in Checkout UI Extensions with the standard targets (purchase.checkout.block.render, purchase.checkout.delivery-address.render-after, etc.).

These are low-risk because they don’t change order behavior. They’re also where you’ll learn the extension model — manifest, target, settings schema — without the pressure of a money-touching change.

A common pattern: build a single “marketing-blocks” extension that ships several configurable blocks (announcement bar, trust badges, FAQ accordion). One extension, multiple targets, settings-driven content.

4. Move discount and delivery logic to Functions

This is the biggest leap and the one most teams over-engineer.

If you had Shopify Scripts, port them to Shopify Functions:

• cartTransform for line-item modifications and bundles
• productDiscount and orderDiscount for discount logic
• delivery_customization for hiding/sorting/renaming delivery options
• payment_customization for hiding/sorting payment methods

Functions run in a WASM sandbox at the edge. They’re fast, they’re typed (Rust or JS), and they have a strict input/output contract — which means once they pass tests, they’re hard to break in production.

The trap to avoid: don’t try to replicate Scripts 1:1. Use the migration as an excuse to delete logic you don’t need anymore. We typically find 30–40% of Scripts in old stores aren’t actually doing anything useful.

5. Save the visual redesign for last

If you’re tempted to also redesign the checkout while you migrate, resist it. Migrate functionally-equivalent first. Then, once everything is working in extensibility, redesign in a clean second project.

Two reasons:

1. You can A/B test the redesign separately, knowing the only variable is the design.
2. If something breaks during migration, you know it’s the migration — not a design choice.

6. Test the order paths you forgot about

Before you flip the switch, test these paths specifically:

• Gift cards
• Discount codes (especially stacking)
• Local pickup
• Subscription products (if you sell them)
• B2B / draft orders
• Translated checkout (if you use Markets)

These are where every checkout migration we’ve ever seen has hit a snag. A 30-minute test plan here saves a 30-hour incident later.

A pragmatic timeline

For a typical Plus store with moderate customization:

• Week 1: Inventory + analytics migration to Web Pixels
• Week 2–3: UI extensions for visual elements
• Week 4–5: Functions for discount / delivery / payment logic
• Week 6: Edge case testing + soft launch
• Week 7: Full cutover

Smaller stores with light customization can compress this to 2–3 weeks. Stores with very heavy Scripts logic may need 8–10. But in every case the order is the same: analytics, UI, Functions, redesign-later.

---

If you want a one-page version of this checklist, it’s in the 60-minute performance audit — the checkout migration section is appendix B.

Got a checkout migration question we didn’t cover? Email us — we use reader questions to plan the next deep-dive.