High-Performance Order Storage moves WooCommerce orders out of the posts table into dedicated tables built for the purpose. It has been available a while, it is the default for new stores, and the reported gains on order processing at volume run up to several times faster.
It is still technically optional. In practice that stopped meaning much this year. New development assumes it, extension authors test against it, and the performance work in recent releases targets it by name. If you are running legacy post storage on a store of any size, the question is when rather than whether.
What was actually wrong with the old arrangement
Orders were a custom post type. That is elegant reuse of existing infrastructure and it was the right call when it was made. It also means every order shares a table with every post, page and revision on the site, and every order field is another row in postmeta.
At a few hundred orders this is invisible. At a few hundred thousand, the orders admin is querying a table serving two unrelated purposes, with meta lookups multiplying per order. Dedicated tables with real indexes on the columns you filter by fix a structural problem instead of tuning around one.
Where migrations go wrong
The migration itself is well-trodden. The failure modes live in the extensions.
Start by inventorying everything that touches orders: reads order data, writes order meta, runs reports. That list is your actual risk. Check each for HPOS compatibility, because most maintained extensions declare it and anything abandoned is what will break. Run in compatibility mode first, keeping both storage systems in sync. It costs you write performance and buys a reversible position, which is a good trade for a fortnight.
Migrate against a staging copy of production data rather than a clean install. The bugs live in the data you already have: the odd refund from 2019, the order referencing a product somebody deleted.
And watch for direct SQL. Any custom report or integration querying wp_posts for orders returns nothing at all once you switch. It does not error. It just comes back empty. That is where I have seen this go wrong most often, usually a finance report written five years ago by somebody who has since left, quietly returning zero rows for a month before anyone notices.
Timing
Not in the fourth quarter. The migration is safe but it is not instantaneous, and running it on a store heading into peak trading is choosing the worst available week to discover an incompatible extension. For retail, January and February are the obvious windows.
If you are launching something new there is no decision to make. It is already the default, and building against post storage in 2026 is volunteering for a migration you could have skipped.
