Full Answer

HPOS exists for good reasons: dedicated order tables are faster and more scalable than stuffing every order into the generic WordPress posts table. But the migration quietly invalidated a decade of shortcuts. Any tracking plugin that queries wp_posts and wp_postmeta directly — or calls get_post_meta on an order ID — is now reading tables that no longer hold the canonical order data.

The dangerous part is how quietly it fails. Nothing crashes and no error is logged; the plugin simply sends purchase events with empty or outdated revenue, order IDs, and customer fields. During the transition, WooCommerce's compatibility mode syncs data back to the legacy tables, which masks the problem — until sync is switched off and the numbers hollow out. And WooCommerce keeps tightening its order data layer: version 10.8 began rejecting REST PUTs to the orders endpoint for non-order types, breaking pipelines that treated order storage loosely. Translation: assumptions about how orders are stored are no longer safe.

The fix starts with an audit. Check each tracking plugin's declared HPOS compatibility, then place a test order after migration and verify the purchase event carries real values into GA4 and your ad platforms. Longer term, tracking that reads through the official WooCommerce order API — rather than scraping database tables — is the only architecture that survives storage changes, a pattern our analysis of plugin-based tracking undercounts covers in depth. The question isn't whether your tracking plugin still loads. The question is whether the numbers it sends are real.