An order reaches checkout successfully, but its delivery reference disappears from the packing screen. Or a loyalty export stops finding new purchases. If a store uses custom order code, those are the kinds of workflows worth checking before changing how WooCommerce stores orders.
High-Performance Order Storage, usually called HPOS, gives WooCommerce dedicated order tables. For a store owner, the useful question is simple: will every tool that reads or changes an order still agree on the same information? This guide explains what to ask your developer and what to test before a switch.
What HPOS changes
WooCommerce’s HPOS overview explains that order data can live in dedicated tables rather than the WordPress posts and postmeta tables. HPOS became the default for new installations with WooCommerce 8.2. An older store may still use the legacy storage setting, so check the actual configuration instead of guessing from the installed version.
When synchronization is enabled, WooCommerce distinguishes between the authoritative tables used for normal order operations and the backup tables receiving copies. Switching which tables are authoritative is blocked while orders still need synchronization. Having two copies is therefore different from having two equally current places that custom code can safely update.
Start with a workflow inventory
Imagine a clothing shop with a courier integration, a loyalty plugin, and a daily spreadsheet export. The customer sees one checkout, but several pieces of code touch that purchase afterwards. A useful audit follows the order through the business instead of stopping at the payment confirmation.
- Checkout: are delivery instructions, customer references, and custom fields saved?
- Administration: can staff see, search, and edit those fields?
- Fulfilment: does the courier receive the correct address and order reference?
- Rewards: are points earned, redeemed, and reversed at the intended stages?
- Reporting: do exports include recent orders and their custom values?
Include small snippets in the theme, must-use plugins, scheduled jobs, and external reporting scripts in the inventory. Give each workflow an owner and write down a visible result. “The courier label contains the apartment number” is a much better acceptance check than “the courier plugin works.”
The code review: use WooCommerce’s order APIs
The official HPOS extension recipe book warns that direct access to legacy order tables can read stale data or write somewhere the active order store will not read. Developers should review order-related uses of get_post_meta(), update_post_meta(), WP_Query, and direct SQL. Those functions remain useful elsewhere in WordPress; the concern is their use for order data.
For an order-specific field, the usual pattern is to load the order with wc_get_order($order_id), read metadata with $order->get_meta('_delivery_reference'), or update it with $order->update_meta_data('_delivery_reference', $reference), then persist changes with $order->save(). The order object lets WooCommerce choose the storage location. These are API patterns, not a complete input-handling endpoint; permission checks and validation still belong in the surrounding feature.
The recipe book also covers custom order administration screens and declaring HPOS compatibility. Treat that declaration as the outcome of a review and testing. Adding a compatibility flag does not rewrite old queries or prove that a shipping export still works.
Check order queries and exports separately
For retrieving collections of orders, WooCommerce recommends wc_get_orders() and WC_Order_Query rather than custom WordPress queries or direct SQL. Use filters and bounded result sets instead of loading the entire order history into memory. Pagination is especially useful for exports and background jobs.
For example, an operations export might request processing orders in pages of 100. Its test should verify the selected statuses, the reporting period, and every custom column. If the real report uses a store-local date boundary, include orders close to midnight in the sample. A correct row count can still hide the wrong set of purchases.
Also test a report against an empty result and more than one page of results. These are practical acceptance checks: they help expose a missing second page or a job that silently gives up when there is nothing to export.
Generated photorealistic editorial image of two laptops and a paper checklist on a developer's desk. Illustrates workflow testing; interfaces are illustrative, not real project screenshots.
Generated editorial image illustrating a testing workspace; not a screenshot of a client store.
A staging test that follows a real order
Use a protected staging copy with customer data handled appropriately. Put payments in their test mode and prevent real courier bookings, reward balance changes, and customer emails. Then write down the expected result for a few representative orders before touching storage settings.
- Place a guest order and a logged-in customer order, including a custom checkout field.
- Edit the delivery reference in administration, reload the order, and check the export.
- Complete a test payment, then check the order status and downstream integration records.
- Exercise a failed payment, a cancellation, and a partial refund; compare totals and reward adjustments with the agreed business rules.
- Open an older order and compare its address, metadata, notes, and related records with the baseline.
Where the plugin promises support for both storage systems, repeat the same cases with legacy storage and HPOS. On an isolated test copy, also check HPOS without compatibility synchronization so the test does not depend on legacy copies being present. Record the storage configuration beside each result.
Plan the switch and the way back
Follow WooCommerce’s current merchant migration instructions for the installed version. They describe the Features settings, compatibility synchronization, and checks for incompatible extensions. Keep extensions that use custom order types active during migration, as the documentation instructs.
Before a live change, take a restorable backup, agree on a quiet change window, and decide who will check the first orders. Confirm synchronization has finished before switching the authoritative storage. For a return to legacy storage, follow the documented synchronization process first.
A full database restore after new live orders have arrived needs separate planning: it can remove those newer transactions. Decide how orders placed during a problem will be preserved and reconciled. This is a business continuity decision, not just a database setting.
What to ask before approving the work
Ask for the workflow inventory, the code areas reviewed, test results for the storage modes your store needs, and a written recovery procedure. A plugin compatibility label is useful, but your acceptance evidence should show that staff can still fulfil, refund, and report on orders.
For a related example of connecting WooCommerce with an external business system, see my Swarm Rewards loyalty integration project. It covers rewards and transaction confirmations; it is not presented here as evidence of an HPOS migration.
If your store depends on a custom order plugin, courier connection, or rewards workflow, I can help review the integration and define the checks needed before changing order storage.
Official documentation checked on 27 October 2026. The linked guides contain the implementation details; the workflow examples and acceptance checklist above are suggested ways to apply them.
