---
title: "Checkout Extensibility: What Plus Merchants Must Migrate"
description: "The old checkout let you edit a Liquid template and do almost anything. The new one gives you defined extension points, a faster checkout, and no way to break it."
author: "Aashish Kaushik"
published: 2026-09-24T13:01:07.314Z
updated: 2026-09-24T13:01:07.504Z
url: https://blog.byteinfy.com/shopify-checkout-extensibility
---
# Checkout Extensibility: What Plus Merchants Must Migrate

## Key takeaways

- Checkout extensibility replaced checkout.liquid with defined extension points — UI extensions, Functions, and branding through the admin.
- Checkout Components reached general availability for Plus merchants in 2026, allowing the post-cart flow to be composed with drag-and-drop blocks.
- The constraint is real: some customisations that worked in checkout.liquid have no equivalent, and the honest answer is sometimes to drop them.
- What you gain is a checkout that stays fast, upgrades itself, and cannot be broken by a bad template edit.

For years, customising a Shopify Plus checkout meant editing `checkout.liquid`, and that file could do almost anything. Merchants added fields, rewrote layouts, injected scripts, and built flows the platform never anticipated.

That flexibility had a cost that was invisible until it was not. Every heavily-customised checkout was a bespoke, unversioned piece of code that Shopify could not upgrade. Performance improvements, security patches and conversion work could not reach the stores that had rewritten it — which were, inevitably, the largest ones.

Checkout extensibility is the trade: defined extension points instead of an editable template.

> **Who this affects**
> 
> Primarily Shopify Plus merchants who customised checkout. Merchants on other plans never had checkout.liquid and are largely unaffected, though Functions and UI extensions are relevant to them too.

## What the new model consists of

Not one replacement but four mechanisms, each covering a slice of what the template used to do.

**Checkout UI extensions** add interface elements at supported points in the flow — a message, a field, a custom block in a defined location. You do not choose an arbitrary position; you choose from the extension points Shopify supports.

**Shopify Functions** handle logic: discounts, delivery customisation, payment customisation, validation. This is where anything that used to be conditional script now lives.

**Branding through the admin.** Colours, typography, logo, layout choices are configured rather than coded. This is the part that has moved furthest out of development.

**Checkout Components**, generally available to Plus merchants in 2026, allow the post-cart flow to be customised with drag-and-drop blocks ([Shopify Editions coverage, ShopAppy](https://shopappy.com/ecommerce/shopify-editions-summer-26-what-shopify-actually-announced), retrieved 2026-09-02).

The direction across all four is consistent: less code, more configuration, and no way for a merchant to break the checkout by editing it badly.

## What genuinely does not migrate

The section most migration guides avoid, and the one that matters most for planning.

Some customisations that worked in `checkout.liquid` have no equivalent, because the new model is deliberately bounded. Being honest about this early saves a project from discovering it late.

## Old customisation and its fate
| Customisation | Status now |
| --- | --- |
| Branding, colours, fonts, logo | Fully supported, configured in admin |
| Custom fields at checkout | Supported at defined extension points |
| Conditional discount logic | Supported via Functions |
| Hiding or reordering payment methods | Supported via payment customisation Functions |
| Hiding or renaming shipping rates | Supported via delivery customisation Functions |
| Trust badges, messaging, upsell blocks | Supported at extension points |
| Arbitrary layout rewrites | Not supported |
| Injecting third-party scripts freely | Not supported |
| Custom multi-step flows outside the model | Not supported |

The bottom three are where projects stall. A merchant who built a genuinely unusual checkout flow will not be able to rebuild it exactly, and the correct response is usually to ask what business problem it solved and whether the new model addresses that problem differently — rather than to seek a workaround, which tends to produce something fragile.

## The migration is an audit before it is a build

The most common mistake is scoping the work from the current checkout's code rather than from its intent.

Checkout customisations accumulate over years. Some were added for a promotion that ended in 2022. Some address a payment provider you no longer use. Some exist because someone once asked, and nobody has questioned them since.

## Audit before scoping
- List every customisation currently live, including ones added by apps
- For each, write down the business reason in plain language
- Mark the ones nobody can justify any more, and plan to drop them
- Identify any that depend on injected third-party scripts
- Note anything seasonal that will not appear in a current audit
- Check which apps rely on checkout access and whether they have migrated

The seasonal item catches teams out — a customisation that only appears during a November promotion is invisible in a July audit and absent when it is needed, which is the worst possible moment to discover a gap in the migration scope.

The app question is equally important. Apps that touched the old checkout have had to migrate too, and not all of them did well. Check that every app you depend on at checkout supports the current model.

## What you get back

The trade is not one-sided, and the gains are worth stating.

**The checkout stays fast, without you.** Shopify optimises checkout continuously, and those improvements now reach your store. Under the old model, a heavily customised checkout was frozen at whatever performance it had when it was written.

**It upgrades itself.** New payment methods, accessibility improvements and conversion work arrive without a project.

**It cannot be broken by an edit.** A misconfigured extension fails in a bounded way. A bad edit to `checkout.liquid` could take down the only page that takes money.

**Less ongoing development.** Branding and, increasingly, layout are merchant-editable. The work that used to be a ticket is now a setting.

For most merchants the honest accounting is that they lose a handful of customisations they had stopped valuing and gain a checkout that improves on its own. For a small number with genuinely unusual requirements, the loss is real.

There is a second-order gain worth noting too. Because every extensibility checkout is built from the same components, problems are shared rather than private. When something behaves oddly, it is far more likely that someone else has hit it and documented it — which is not true of a checkout that only your store has ever run. Bespoke code is lonely to debug, and that cost never appeared on any invoice for the original customisation.

## Test the things the demo will not show

Checkout is the one page where a fault costs the entire order, so verification should be more thorough than elsewhere.

- Every accelerated checkout method you have enabled, completed end to end, not just rendered.
- Every discount combination a real shopper could reach, including codes still circulating.
- A failed payment, confirming the recovery path works.
- An international address, if you sell across markets.
- Guest checkout, not only logged-in.
- A mobile device on a slow connection, which is where most of your traffic actually is.

> **Do not migrate checkout during peak**
> 
> This work should not be shipped anywhere near a high-traffic period. Checkout changes need weeks of ordinary traffic to reveal edge cases, and the failure mode is losing orders rather than degrading an experience. If a peak period is approaching, wait until after it.

## Who can change checkout now

An organisational consequence worth planning for deliberately, because it is the change teams notice day to day.

Under the old model, checkout customisation was unambiguously a developer task. Nobody edited `checkout.liquid` casually, which was dangerous but at least had a clear owner.

The new model splits the work three ways. Branding and layout are merchant-editable in the admin. Composition of the post-cart flow is merchant-editable through Checkout Components. Logic remains a development task through Functions and UI extensions.

That is mostly good — routine changes stop waiting in a development queue. It introduces a governance question that most merchants have not faced: when several people can change how checkout looks and behaves, and none of those changes go through review, a conversion drop becomes genuinely hard to diagnose.

Two lightweight practices prevent most of the pain:

**Decide who may change what.** Not everyone with admin access should be reconfiguring the page that takes money. Shopify's staff permissions can express this; most stores have never used them for it.

**Keep a dated note of significant changes.** A shared document is enough. The failure it prevents is the one where conversion falls four percent, nobody can recall what shipped that week, and the investigation takes longer than the change did.

> **Watch checkout completion, not just conversion**
> 
> Store-wide conversion rate moves for a dozen reasons. The number that isolates checkout problems is the proportion of sessions that reach checkout and then complete. If that ratio moves after a change, the change is the cause, and you will know within days rather than after a month of arguing about traffic quality.

## A sequence that works

1. Audit the current checkout for what exists and why.
2. Cut what nobody can justify.
3. Map each survivor to a UI extension, a Function, a branding setting, or Checkout Components.
4. Identify the unmappable ones and decide explicitly whether to solve the underlying problem differently or drop it.
5. Check every app that touches checkout.
6. Build and test on a development store, including all the paths above.
7. Ship well away from peak, and watch order completion rates for a fortnight.

Step four is the one that needs a decision-maker rather than a developer, and getting it in front of one early is what keeps the project moving. Development teams tend to park unmappable requirements rather than escalate them, on the reasonable assumption that a workaround will emerge. Usually none does, and the decision surfaces weeks later with the deadline much closer. Ask for it in the first week.

For the wider checkout picture, see [checkout and payments](/category/checkout-payments). Discount logic and Functions are covered in [promotions and offers](/category/promotions-offers) and [Shopify development](/category/shopify-development).

**Still carrying a legacy checkout?**
ByteInfy migrates Shopify Plus checkouts to extensibility — UI extensions, Functions and Checkout Components, with the audit that decides what is worth keeping.

[Start a project](https://byteinfy.com/#contact)

## FAQ

### What replaced checkout.liquid on Shopify Plus?

Checkout extensibility, which is a set of defined mechanisms rather than one file.

### Why did Shopify remove checkout.liquid?

Because an editable checkout template meant every merchant's checkout was a bespoke, unversioned piece of code that Shopify could not upgrade, optimise or guarantee.

### What are Checkout Components?

A drag-and-drop way of composing the post-cart flow, generally available to Plus merchants as of the Summer 2026 release.

### Can I still customise my Shopify checkout?

Yes, within defined boundaries. You can add interface elements at supported extension points, change discount and delivery and payment behaviour with Functions, apply branding through the admin, and compose the flow with Checkout Components.

### Do I need a developer to migrate?

For branding and layout, increasingly not — that work has moved into the admin and Checkout Components. For anything involving custom logic, validation or third-party calls, yes.