1 October Is Real: The Polaris Web Components Deadline for Checkout Extensions

Shopify has set 1 October 2026 as the date by which checkout and customer account extensions must complete the migration to Polaris web components. That is three weeks from today, and it lands in the window where most stores are trying to stabilise ahead of peak rather than refactor UI code.

We are writing about it now for the same reason we wrote about Scripts in July and the thank you page deadline last week. This is the third platform deadline in a quarter, and the pattern is consistent: the teams that get caught are not the ones with hard problems, they are the ones who found out late.

What is changing

Checkout UI extensions and customer account extensions have been built against a component library specific to those surfaces. The migration moves them to Polaris web components, aligning the extension surfaces with the component model Shopify uses across the admin.

The practical consequence for an extension developer is that component imports, element names and in some cases prop and event semantics change. This is not a rewrite of your extension logic. It is a rewrite of how that logic renders.

Who needs to act

Wider than most teams assume. Run through this list honestly.

• Custom extensions your team built. Obvious, and usually the ones people remember.
• Extensions built by a former agency. Very common, and the source repository may not be somewhere you can currently deploy from. Check that before checking the code.
• Third-party app extensions. The vendor is responsible, but you carry the consequence. Ask each vendor whose app renders in checkout or customer accounts for written confirmation of their migration status.
• Anything built during a Checkout Extensibility migration in 2023 or 2024. These are old enough that nobody currently on the team wrote them.

Start with an inventory of every extension rendering in checkout and customer accounts, with an owner name against each one. Teams routinely discover an extension they cannot immediately attribute to anyone, and that discovery takes longer than the migration itself.

The audit and migration sequence

1. Inventory and attribute. List every extension, its source repository, its owner and whether it is yours or a vendor's. Give yourself two days for this, because the answers are often not where you expect.
2. Email every vendor this week. Ask for a specific answer: is their extension migrated, and if not, on what date will it be. A vague reassurance is not an answer. You need enough notice to disable an app before it breaks something.
3. Diff each of your own extensions against the current component reference. Identify every component in use and whether the replacement is a direct substitution or a behavioural change.
4. Migrate the highest risk extension first. That is whichever one, if it stopped rendering, would cost you money rather than embarrassment. Usually a delivery option selector, a B2B purchase order field or an age or eligibility gate.
5. Test on a development store with real configuration. Every locale, every currency, and both the checkout and customer account surfaces. A component that renders correctly in English at desktop width is not evidence of anything.
6. Deploy with gradual publishing. Native gradual publishing arrived in June. Use it here rather than pushing extension changes to all traffic at once.

A rough shape for the inventory, which is more useful as a tracked document than as a mental note:

// Extension migration tracker. Keep this in the repository, not in a chat thread.
const extensions = [
  {
    handle: "delivery-instructions",
    surface: "checkout",
    owner: "internal",
    repo: "shop-extensions",
    risk: "high",          // blocks a delivery choice if it fails to render
    migrated: false,
    verifiedOn: null
  },
  {
    handle: "loyalty-enrol",
    surface: "customer-account",
    owner: "vendor:loyalty-app",
    repo: null,
    risk: "medium",
    migrated: null,        // awaiting vendor confirmation
    verifiedOn: null
  }
];

const blocking = extensions.filter(
  (e) => e.risk === "high" && e.migrated !== true
);

console.log({ total: extensions.length, blocking: blocking.length });

The value is in the migrated: null rows. Those are the vendor extensions where nobody has confirmed anything, and they are the ones that will surprise you on 1 October.

The peak season problem

The deadline is three weeks out, and Black Friday is on 27 November. That leaves a genuinely awkward gap where extension work has to land, get tested, and then sit stable through a freeze period.

Our recommendation is to treat this as the last significant extension change before the freeze. Migrate, verify, and then stop touching extension code. If you were planning other checkout work this quarter, such as a Checkout Components evaluation, fold the component migration into that effort now rather than sequencing them, because doing both means testing the same surfaces twice.

What to do if you will not make it

If the inventory reveals an extension you cannot migrate in three weeks, you have three options and it is worth deciding which now rather than on 30 September.

Disable the extension before the deadline and accept the missing functionality temporarily. This is unglamorous and almost always correct, because a disabled feature is a known state and an unmigrated extension is not.

Replace the functionality elsewhere. Some things that live in a checkout extension can move to a Function, a theme change or an order webhook. Not everything, but more than people expect. Our breakdown of when to use Shopify Functions covers where that boundary sits.

Escalate with the vendor. If a third-party app is the blocker, the conversation to have this week is about their timeline, not yours.

Frequently asked questions

What happens to an extension that is not migrated by 1 October?

Assume it stops rendering correctly. Plan on the basis that unmigrated extensions fail rather than degrade gracefully, because that assumption costs you very little if you are wrong.

Does this affect Shopify Functions?

No. Functions have no rendering surface and are unaffected by a component library migration. This applies to checkout UI extensions and customer account extensions.

Do I need to migrate extensions from third-party apps?

The vendor does the work, but you should verify it rather than assume it. Ask each vendor for a written confirmation and a date, and track the answers.

Is this the same as the Checkout Components change?

No. Checkout Components, generally available on Plus since June, is a different and optional architectural model. This migration is mandatory and applies to existing extensions regardless of whether you adopt Components. We covered Checkout Components separately.

How long does a typical extension take to migrate?

A simple extension with a few components is often a day. Extensions with custom layouts, conditional rendering or heavy form handling take longer, mostly in testing rather than in writing code.