WooCommerce Cart Blocks: The 2026 Migration Guide

Cart Blocks have been the default in WooCommerce for over two years, but I am still finding stores running the legacy shortcode-based cart and checkout. If your store launched before 2023 and nobody has touched the cart and checkout pages since, you are almost certainly leaving money on the table. Here is what changed, what to test before you migrate, and the gotchas I have hit on real client stores.

Why the new blocks beat the legacy shortcodes

The Cart Block and Checkout Block are React components running on the front-end. They update without full page reloads, validate fields inline, and ship a much faster perceived experience than the old PHP-rendered checkout. The default styling is also significantly cleaner. Worth saying plainly: a faster checkout will not rescue a slow store, and if your product pages take six seconds to paint, that is the problem to fix first.

On conversion, let me be careful about what I am claiming. WooCommerce pushes the block checkout as the better-converting option, and on the stores I have migrated it is a faster thing to use. I have not run a controlled test of my own, so treat that as directional rather than a number you can bank.

The block checkout also exposes a structured extensibility API. Instead of hooking into a hundred different action hooks scattered through the legacy template, you register inner blocks, slot fills, or use the checkout filters API. Cleaner, more predictable, easier to maintain.

Where the migration gets messy

Plugins. Specifically, any payment gateway, shipping plugin, or checkout customization plugin written before late 2022. The legacy hooks like woocommerce_after_checkout_billing_form do not fire on the block checkout. If a plugin you depend on has not added explicit Cart Block support, it will silently break or do nothing on the new checkout.

Before migrating, audit every active extension and check whether the developer has shipped Cart Block compatibility. Most major payment gateways (Stripe, PayPal, Square, Authorize.net) have full support. Many smaller shipping calculators, tax plugins, and custom checkout field plugins do not.

The migration playbook I follow

• Clone the production store to staging
• Replace the cart shortcode with the Cart Block, leave Checkout on shortcode
• Run a real test transaction; catch any plugin breakage early
• Replace the Checkout shortcode with the Checkout Block
• Test every payment method, every shipping method, every coupon scenario
• Test on mobile, especially Apple Pay and Google Pay flows
• Run accessibility checks. The block checkout has better default a11y but custom fields can break it
• Push to production during low-traffic hours
• Monitor checkout completion rate and abandonment for two weeks

Gotchas worth knowing

Custom checkout fields added via the legacy woocommerce_checkout_fields filter do not appear on the block checkout. You have to register them through the new Checkout Block fields API. This is the single most common surprise in migrations.

Conditional logic that hid or showed fields based on cart contents needs to be rewritten in JavaScript using the block’s filter system. The PHP equivalents do not work.

If you customized the order received page heavily, that one is still PHP-based and untouched by the block migration, so any logic there carries over fine.

What this actually costs you in time

The honest range, because “it depends” is not an answer you can plan around. A clean store (standard gateway, standard shipping, no custom checkout fields) is an afternoon, and most of that afternoon is testing rather than clicking. A store with custom fields and conditional logic is a different job: those fields have to be re-registered through the Checkout Block API and every path re-tested, and that is days rather than hours. I would not put a number on that second case without looking at your extension list first, and neither should anyone else.

The risk is worth naming precisely, because it is not the one people expect. The failure mode is not a checkout that looks broken. It is a checkout that looks perfect and has quietly dropped a plugin’s behavior: a shipping rule that no longer applies, a tax field that no longer saves, a gateway that renders its button and never fires. Nothing errors. You find out from a customer, or from a month-end number that does not reconcile. That is the entire reason the playbook above puts a real test transaction before the checkout swap and two weeks of monitoring after it, and it is why the staging clone is not the step to skip when you are in a hurry.

Should you migrate?

If your store does standard things (standard payment methods, standard shipping, no exotic checkout customization), yes, migrate now. The new architecture is where future development is going, so the legacy cart gets less attention every year you leave it. If your store has fifteen custom checkout fields, three obscure payment gateways, and conditional logic everywhere, plan a proper engineering project. Do not just flip the switch.

How this fits

This is maintenance work on a store you already have. If you are moving to WooCommerce in the first place, the sequence is different and I have written it up separately in the Shopify to WooCommerce migration guide. Either way it sits inside the same e-commerce work I do for Idaho businesses.

Not sure which bucket you’re in?

If you are on a pre-2023 store and are not sure which of the two categories above yours falls into, book a free 30-minute call and I will go through your extension list with you and tell you whether this is an afternoon or a project. If it is an afternoon and you would rather do it yourself, the playbook above is the whole of it and I will say so.