WooCommerce
How to migrate to WooCommerce block checkout
A WooCommerce block checkout migration is the move from the [woocommerce_checkout] shortcode (and the matching cart shortcode) to the Cart and Checkout blocks. I still find stores in 2026 running classic checkout because a gateway, a field plugin or an Elementor template never got tested. I am Alan Vo, a Gold Coast web developer with 18 years on WordPress shops. Block checkout is where WooCommerce is putting new payment and field work. Classic is maintenance mode with a longer tail than people admit.
WooCommerce documents the editor surface in customizing cart and checkout. This note is the staging-first process I use on furniture, footwear and specialist catalogues so gateways and required fields survive the swap.
Why a WooCommerce block checkout migration is overdue
A WooCommerce block checkout migration is overdue when you want Express wallets, modern address forms, and the field layout WooCommerce still ships features for. Classic checkout is PHP templates, woocommerce_checkout_fields, and jQuery that talks to checkout.js. Block checkout is a React tree, Store API, and inner blocks for contact, shipping, payment and order summary.
New gateway features land on blocks first. Some wallets never get a classic adapter. Field plugins that only hook woocommerce_after_order_notes do not appear on blocks unless the vendor shipped a checkout-block integration. That split is why stores freeze on classic: one plugin would go blank.
Performance is the other reason. Classic checkout often loads the entire theme, cart fragments, and three field plugins on every keystroke. Blocks are not automatically fast (I wrote WooCommerce checkout INP for that), but they give you a supported way to stop stacking jQuery validators.
Classic is still valid if a gateway or a B2B plugin has no block support and the revenue depends on it. I do not migrate those stores on a hope and a weekend. I migrate when the plugin list is compatible, or when we replace the incompatible plugin as part of the same ticket. For the broader classic-versus-blocks decision, see WooCommerce blocks vs shortcodes in 2026.
How WooCommerce block checkout actually works
WooCommerce block checkout actually works as a page built from blocks, not as a shortcode inside a page builder widget. You create (or convert) a Checkout page in the block editor. The Checkout block contains inner blocks: contact information, shipping address, billing, shipping methods, payment, additional fields, terms, and the order summary. Cart is a separate Cart block on the Cart page. Mini-cart can be a block in the header.
Data goes through the Store API (/wc/store/v1/) rather than the old wc-ajax=checkout HTML refresh as the primary path. Extensions that posted to admin-ajax and expected a full checkout fragment redraw will fail or double-submit.
Payment methods register for blocks via the WooCommerce Blocks payment API. A gateway can be "available" on classic and invisible on blocks. That is the number one go-live failure. Wallets (Shop Pay is Shopify; on Woo it is Apple Pay, Google Pay, PayPal buttons, Stripe Express) each have a block module. Test every one.
Checkout fields: WooCommerce has been moving additional fields into a block-aware fields API. Old woocommerce_checkout_fields filters still apply to some fields and not to others depending on version. I audit fields on a staging order, not by reading functions.php.
Elementor, Bricks and other builders that embed the checkout shortcode in a widget are a special case. The builder page may not be a block template. You either replace that page with a block theme template (or a block-enabled page) or you keep classic until the builder supports the Checkout block without wrapping it in a shortcode widget that never hydrates.
How I migrate cart and checkout on staging
I migrate on a staging clone with a payment gateway in test mode and a shipping plugin that matches production. I never flip the live Checkout page first.
Step one is a plugin compatibility pass. WooCommerce lists many extensions. I still test: gateways, shipping, fees, gift cards, local pickup, multi-address, VAT plugins, field add-ons, and any "one-page checkout" app. One-page checkout plugins that replace the page entirely usually conflict with blocks. They are a removal, not a setting.
Step two is pages. WooCommerce Settings, Advanced, Page setup: Cart and Checkout must point at pages that contain the blocks, not the shortcodes. I leave the old shortcode pages unpublished but not deleted for a week.
Step three is the Checkout block inner layout. I match the business rules: account creation, guest checkout, phone required, company field, order notes, privacy text. I do not add extra inner blocks because they look like a landing page. Checkout is not a PDP.
Step four is shipping and pickup. Local pickup in blocks has its own inner block and location list. Classic pickup plugins that injected HTML under the methods table will vanish. Rebuild pickup as WooCommerce's pickup or a block-compatible plugin.
Step five is fields. Custom fields must save to order meta the warehouse already reads. I place a test order and open it in admin (HPOS or posts, whatever the shop uses). If the engraving note is not on the order, the field integration is fiction.
Step six is gateways. Pay with card, with a wallet, with a delayed method (BACS, invoice) if you offer them. Fail a card. Refund. Partial capture if you use it.
Step seven is theme CSS. Blocks bring their own markup. A theme that styled .woocommerce-checkout tables will miss the new grid. I restyle with block theme JSON and a thin CSS file, not 800 lines of classic checkout CSS.
Step eight is GTM and GA4. begin_checkout and purchase often hook classic events. Block checkout still has dataLayer needs. I verify DebugView on a staging purchase before go-live.
Production checklist
- Clone production to staging. Disable cache plugins on checkout URLs.
- Spreadsheet every checkout plugin: block-compatible, classic-only, unknown.
- Replace or remove classic-only plugins that own required fields or gateways.
- Create a block Cart page and a block Checkout page. Point WooCommerce to them on staging.
- Configure inner blocks to match guest/account, required fields, pickup, notes, terms.
- Place a test product with shipping class, a virtual product, and a mixed cart.
- Test coupons, gift cards, tax-inclusive display, and zero-total carts (100% coupon).
- Test every payment method including wallets and failed payments.
- Confirm order emails, PDF invoices and ERP/webhook payloads still see custom fields.
- Restyle without breaking focus states and error messages. Accessibility regressions here cost more than colour.
- Recheck GA4 purchase and Ads conversions on the new page.
- If the site is Elementor, verify the live checkout URL is the block page, not a builder template that still has the shortcode.
- Go live by switching page IDs in WooCommerce settings, not by editing the old page in place until it "looks like blocks."
- Keep classic pages drafted for rollback for 7 days. Watch failed-order rates on day one.
What breaks on WooCommerce block checkout
Gateways that never registered a block payment method. The checkout shows "no payment methods" or only BACS. Customers bounce. Classic still worked that morning.
Field plugins that only hook PHP templates. The VAT ID is gone. EU invoices fail. This is a compliance incident, not a cosmetic one.
Shipping plugins that calculated on woocommerce_package_rates may still work, then fail to update when the address block debounces. Rates stick on the first postcode. I watch the Store API network tab while typing an address.
Elementor templates that wrap the Checkout block in a shortcode widget: hydration fails, express buttons duplicate, or the page never becomes interactive.
Themes that dequeue wc-blocks-checkout CSS "for performance" and then the order summary collapses on mobile.
Cart fragments and a block cart together: mini-cart counts lie. Disable fragment JS on stores that fully moved to the Cart block and mini-cart block, or you fight two carts.
Custom process_checkout JavaScript that prevented double submit on classic will block Store API checkout. Remove it.
How I measure a successful migration
I measure completed orders, payment error rate, and field completeness. Gateway dashboard versus WooCommerce orders versus GA4 purchase should agree. If WooCommerce orders continue and GA4 drops, tags failed. If both drop, checkout failed.
I sample 20 live orders for custom meta, shipping method, and tax. Warehouse complaints are a better detector than Lighthouse.
INP on the checkout URL group in CrUX should not collapse. If it does, the migration still "worked" commercially and failed as a site. Fix INP next. Do not roll back to classic only for a lab score if orders are clean.
I do not attach a conversion percentage to this migration unless the store already published one. Block checkout is infrastructure.
Related work on this site
WooCommerce catalogues I have shipped still have to finish the order on a phone. The Skanvi furniture storefront is editorial photography plus a first-order path. Janet and Janet is campaign footwear imagery that cannot stall cart. The Detail Dr. is a specialist catalogue with education next to SKUs. Block checkout is the 2026 way those shops take money. It is not a redesign of the PDP.
FAQ
Can I run classic cart and WooCommerce block checkout together?
You can point Cart and Checkout at different stacks, and I do not recommend it. A shortcode cart posting into a block checkout (or the reverse) is how coupons and fees desync. Migrate cart and WooCommerce block checkout as one change.
Does Elementor block a WooCommerce block checkout migration?
It blocks you if checkout lives in an Elementor template that only supports the shortcode widget. Move checkout to a WordPress page that hosts the Checkout block, or to a block theme template. Keep Elementor on marketing pages if you must.
Will I lose custom checkout fields?
Only if they were classic-only hooks. A WooCommerce block checkout migration needs a block-compatible fields plugin or WooCommerce's additional checkout fields. Prove it with a staging order that shows the meta in admin.
How long should a WooCommerce block checkout migration take?
A compatible plugin list can move in a few staging days plus a quiet go-live. An incompatible gateway or B2B field pack is a plugin project first. The block swap is the last hour, not the whole risk.
Keep reading
Contact if you want this kind of work on a live store.