Checkout Components Reached GA on Plus: How to Plan the Rebuild

At Summer '26 Editions on 17 June, Checkout Components reached general availability for Shopify Plus. It arrived in the same wave as the Scripts sunset, and the two are more connected than the release notes suggest: the old model of customising checkout by bolting logic onto a rendered page is finished, and what replaces it is a composable surface you assemble yourself.

Most of the calls we have taken since June open with the same question, which is whether a store needs to migrate at all. Usually the answer is no, or not yet. This post is about how to tell.

What Checkout Components actually change

Checkout Extensibility, which most Plus stores adopted between 2023 and 2025, gave you defined slots. You wrote UI extensions, dropped them into the positions Shopify exposed, and worked within the branding API for everything else. The layout itself was not yours.

Checkout Components moves the boundary. Instead of injecting into a page Shopify renders, you compose the checkout from primitives: the field groups, the summary, the delivery and payment sections, each addressable as a component you place. The result is that checkout stops being a page you decorate and becomes a surface you build, while Shopify continues to own the parts that must not be touched, which are payment processing, PCI scope, fraud analysis and the order creation path.

Who this is actually for

Being available on your plan is not a reason to adopt it. Three profiles genuinely benefit.

Stores with checkout logic that never fit the slots. If your team has a backlog of checkout requests that were closed as not possible under extensibility, price that backlog. Multi-step flows, conditional field groups, B2B purchase order capture that has to appear before delivery selection, and progressive disclosure for complex configurable products are the recurring examples.

Brands where checkout is a brand surface. For most stores it is not, and pretending otherwise is how teams spend six figures to move conversion by nothing. For a small number of high-consideration brands, the visual break between site and checkout is measurable in drop-off. Measure it before you assume it applies to you.

Stores already mid-rebuild. If you are replatforming to a headless storefront, the marginal cost of composing checkout at the same time is far lower than doing it as a separate project later. We covered the storefront side of that decision in our Hydrogen and Next.js comparison.

Everyone else should stay on extensibility. It is not deprecated, it continues to receive investment, and it is dramatically cheaper to maintain.

The costs nobody puts in the estimate

A Checkout Components migration is not a port. Three cost centres consistently get underestimated.

• Regression surface. You now own layout, which means you own every device, locale, currency, tax display and delivery method combination. A store selling into France, the UK and Canada with three delivery options has a test matrix that grows faster than the estimate assumes.
• Accessibility. Shopify's default checkout is accessible because Shopify made it so. The moment you compose your own, that work is yours, and checkout is the one surface where an accessibility defect converts directly into lost revenue and legal exposure.
• Ongoing maintenance. Every platform improvement to the default checkout previously arrived for free. Composed checkouts inherit less automatically. Budget continuing engineering time, not a one-off build.

The teams that regret the migration are almost always the ones that scoped it as a redesign. The teams that are glad they did it scoped it as taking permanent ownership of a revenue-critical surface.

Sequencing a migration that does not break peak season

It is mid-July. Black Friday is roughly nineteen weeks out. That is enough time, but only with a hard cutoff.

1. Weeks 1 to 2, inventory. List every behaviour your current checkout performs: extensions, branding overrides, Functions, validation rules, third-party pixels and post-purchase offers. This is the same document the Scripts sunset should have taught everyone to keep.
2. Weeks 3 to 4, decide per behaviour. For each item, decide whether it stays as a Function, becomes a component, or gets dropped. Dropping things is the highest return activity in this phase. Most stores are carrying checkout logic that no longer serves anyone.
3. Weeks 5 to 10, build against a development store. Compose the checkout with a real product catalogue, real tax configuration and real delivery profiles. Synthetic data hides exactly the problems you are trying to find.
4. Weeks 11 to 13, test the matrix. Every locale, every currency, every delivery method, on real devices. Include a screen reader pass and a keyboard-only pass.
5. Weeks 14 to 16, roll out gradually. Summer '26 also shipped native A/B testing and gradual publishing under Rollouts. Use it. Send a small share of traffic to the new checkout and hold it there long enough to reach significance on completion rate, not just for a day.
6. Week 17, freeze. If the new checkout is not fully live and stable by mid-November, keep the old one through peak and resume in January. This is a decision to make now, in writing, not in the third week of November.

Instrumentation to put in before you start

You cannot evaluate a checkout rebuild without a baseline, and the baseline has to exist before the rebuild starts. At minimum, capture completion rate by step, by device and by locale for a full four weeks of current checkout behaviour.

// Baseline event shape to capture per checkout step, before any rebuild.
// Store it somewhere you control, not only in a vendor dashboard.
function checkoutStepEvent(step, context) {
  return {
    event: "checkout_step_viewed",
    step,                        // "information" | "delivery" | "payment"
    checkoutToken: context.token,
    locale: context.locale,      // "en-GB", "fr-FR", "en-CA"
    currency: context.currency,
    deviceClass: context.deviceClass,
    deliveryMethod: context.deliveryMethod || null,
    hasDiscount: Boolean(context.discountCodes?.length),
    timestamp: new Date().toISOString()
  };
}

Push these server side rather than relying on browser events alone, for the same reasons we set out in our server-side tracking guide. A composed checkout that appears to convert better because your client-side measurement changed is worse than no measurement.

The honest recommendation

For most Plus stores, the right move in July 2026 is to do the inventory, price the backlog of checkout requests you have been declining, and then decide. If that backlog is thin, stay on extensibility and spend the budget on catalogue data or performance instead, both of which have clearer returns this year.

If the backlog is real, start now rather than in September. The compressed timeline is what turns a reasonable project into a peak season incident.

Frequently asked questions

Is Checkout Extensibility being deprecated?

No. Extensibility remains supported and is the correct choice for the majority of Plus stores. Components are an additional model, not a forced replacement.

Do Checkout Components require a headless storefront?

No. They apply to checkout regardless of how the rest of the storefront is built. Headless stores tend to adopt them earlier because the team and tooling are already in place.

Does composing checkout affect PCI scope?

Payment capture stays within Shopify's boundary, so your PCI position is unchanged. Everything you compose sits outside that boundary by design.

Can I test the new checkout against the old one?

Yes. Summer '26 added native A/B testing and gradual publishing for checkout configurations, so you can split traffic without a third-party tool.

What happens to my existing checkout UI extensions?

Most are portable, but they were written against slot positions that no longer describe the layout. Plan to review each one rather than assuming it carries over unchanged.