WooCommerce Block Checkout vs Classic

What this article covers

The classic checkout shortcode is not deprecated. It is supported, and WooCommerce still ships a one click route back to it.
Blocks has been the default for new stores since WooCommerce 8.3, and new platform features increasingly target blocks only.
The deciding factor is your extension list, not your opinion of blocks. Run the checklist below before anything else.
There is a third option that most guides never mention: improve the classic checkout you already have and revisit blocks later.

The short answer

Switch if every extension that touches your checkout supports blocks, you want express payment buttons and the newest WooCommerce features, and you can afford an hour of testing with a real card.

Do not switch yet if you depend on a gateway, subscription, booking, multi-currency or checkout field plugin that has not shipped block support, or if your checkout carries custom PHP you cannot easily rewrite. Nothing is forcing you, and a broken checkout costs more than a modern one gains.

Is the classic checkout deprecated?

No, and this is the question that causes the most unnecessary panic.

The [woocommerce_checkout] shortcode remains a supported part of WooCommerce. WooCommerce's own documentation still describes moving between the two, and the cart and checkout blocks can be transformed back to the classic version using the transform button in the block toolbar. A platform does not build a one click escape hatch to a format it is about to delete.

What is true is quieter and more important:

The block checkout has been the default for new installations since WooCommerce 8.3, so every store created since late 2023 starts there.
New platform capabilities are increasingly built for blocks first, and sometimes only. That gap widens over time.
Existing stores are prompted to migrate, but not moved automatically.

So the accurate framing is not "classic is dying next month". It is "classic is stable, and the innovation is happening elsewhere". That is a reason to plan a migration, not a reason to rush one.

What actually differs under the hood

Understanding this explains every compatibility problem you will hit.

The classic checkout is a PHP template. WooCommerce renders the form server side, extensions hook into it with standard WordPress filters and actions, and the page reloads or uses AJAX for updates. Fifteen years of WooCommerce plugins were written against this model.

The block checkout is a React application. It fetches cart and checkout data from the Store API, renders the form in the browser, and extensions must register through a dedicated JavaScript API. A PHP hook that worked for a decade may simply never fire.

This is why "it just stopped working" is the most common migration report. Nothing errored. The extension's PHP hook is still registered, it just has no template to attach to. Silence, not a crash. We ran into exactly this while building field controls: the classic checkout honours the woocommerce_default_address_fields filter for required and hidden flags, and the block address form largely ignores them. Same filter, same code, different outcome. See removing checkout fields for the detail.

What you gain by switching

Express payment buttons at the top of checkout, which are genuinely good for mobile conversion.
Faster perceived performance. Totals update without a full page round trip.
Editing in the site editor rather than in PHP templates, which suits teams without a developer.
Access to new features. This is the real long term argument. Anything WooCommerce builds next is likelier to land on blocks.
Built in field controls for phone, company and address line 2, exposed in the block inspector.

What you risk

Extension breakage, the big one. Covered by the checklist below.
Custom code stops firing. Any snippet in functions.php that hooks a classic checkout action needs rewriting against the JavaScript API, which is a genuinely different skill.
Analytics and tracking gaps. Conversion pixels and event tracking wired into classic checkout events are a well documented casualty. Verify your tracking fires after switching, before you trust the numbers.
Design work. Your theme's checkout styling will not carry over cleanly. Blocks has its own class names and structure.
Less styling freedom in practice. Deep visual customisation of a React form is harder than overriding a PHP template.

The compatibility checklist

Run this before you decide. It takes about twenty minutes and it answers the question properly, which no amount of reading opinions will.

1. List every plugin that touches checkout

Payment gateways, shipping method plugins, tax plugins, subscriptions, bookings, memberships, multi currency, checkout field editors, order bumps, gift cards, loyalty and points, EU VAT tools, fraud tools, and anything with "checkout" in its name.

2. Let WooCommerce tell you

Open your checkout page in the editor and add or select the Checkout block. If an active extension has declared itself incompatible, WooCommerce shows a warning in the block inspector along with a one click button to switch to the classic checkout. This is the single fastest signal available, and it is built into core.

Absence of a warning is not proof of compatibility. The notice only fires for extensions that have explicitly declared incompatibility. A plugin that simply never got updated declares nothing and stays silent. Treat a clean inspector as a good sign, not a guarantee.

3. Check each plugin's own documentation

Search the plugin's changelog or docs for "blocks", "block checkout" or "Store API". Vendors who support blocks say so loudly. Silence usually means no.

4. Inventory your custom code

Search your theme and site plugins for these strings. Each hit is code that will stop running on blocks:

woocommerce_checkout_fields
woocommerce_after_checkout_billing_form
woocommerce_review_order_before_submit
woocommerce_checkout_before_customer_details
woocommerce_before_checkout_form
woocommerce_checkout_process
woocommerce_default_address_fields

Not exhaustive, but these five minutes catch most of it.

5. Test on a staging copy, with a real payment

Not a sandbox order. Push one real, small, live transaction through every gateway you offer, then refund it. Sandbox modes routinely behave differently from production, and payment is the one thing you cannot afford to discover at 9am on a Monday.

6. Test on a phone

Mobile is where most of your traffic is and where most checkout defects live. Walk the full flow on an actual handset, not a desktop browser resized narrow.

How to switch safely

Take a full backup, database included.
Do it on staging first. Every time.
Edit your checkout page, select the classic shortcode block, and use the transform option to convert it to the Checkout block.
Work through the checklist above on the staging copy.
Re-apply your styling, then re-verify your analytics and conversion tracking actually fire.
Go live at your quietest hour, not your busiest.
Watch completed orders for 48 hours. A migration failure usually shows up as fewer orders, not as an error message.

How to switch back

Reassuringly simple, and worth knowing before you start. Edit the checkout page, select the Checkout block, and use the transform control to go back to the classic shortcode. If an incompatible extension is detected, WooCommerce offers the same revert as a one click button in the block settings sidebar.

Your orders, customers and settings are untouched either way. The checkout page is a rendering choice, not a data migration.

The third option nobody mentions

Most articles frame this as a binary: stay on an ageing classic checkout, or migrate to blocks. There is a third path that suits a lot of stores.

Improve the classic checkout you already have, and revisit blocks when your extensions catch up.

The reason people want to migrate is rarely the block editor. It is that their checkout looks dated, has too many fields, and does not convert. Those are solvable on classic today, without touching your gateway stack, and the four routes for doing it are compared in how to customise the WooCommerce checkout page:

A modern, mobile first layout
Fewer and better organised fields
A multi-step flow, if your form is long
Trust signals near the payment button
Express payment options

This is the bet OptiCheckout is built on. We restyle the classic checkout rather than replace it, so your gateways, shipping, tax and subscription extensions keep working exactly as they do now. It is not the right answer for everyone. If your extensions are all block ready and you want the newest platform features, migrate. But "my checkout looks old" and "I must convert to blocks" are two different problems, and only one of them is urgent.

Our verdict

Your situation	What we would do
New store, few extensions	Use blocks. You are already there, stay there.
Simple store, all extensions block ready	Migrate, on staging, with the checklist.
One critical extension not ready	Wait. Ask the vendor for a timeline.
Heavy custom checkout code	Budget it as a project, not an afternoon.
Subscriptions, bookings or B2B	Test exhaustively. These break most often.
"It looks dated and converts badly"	That is a design problem. Fix it on classic now.

Whichever way you go, test with a real payment before you trust it.

Staying on classic for now?

OptiCheckout gives the classic WooCommerce checkout seven modern templates and a visual builder, with no migration and no checkout conversion. Your extensions keep working.

See a live checkout See pricing

Where we are biased, stated plainly. We build a plugin for the classic checkout, so we have an interest in classic remaining viable. We have tried to keep that out of the facts: classic genuinely is not deprecated, blocks genuinely is the platform's direction, and if your extension list is clean we genuinely think you should migrate. Check the claims here against WooCommerce's own documentation, which we have linked rather than paraphrased.

Should you switch to the WooCommerce block checkout?