HPOS breaks stores silently: orders stranded in one storage, totals that disagree between tables, plugins that read empty data without a single error. OrderMedic finds it — and refuses to migrate until it's fixed.
Free plugin under review on wordpress.org · read-only, no data ever leaves your server
Since WooCommerce made High-Performance Order Storage the default, order data lives in two places during (and often long after) the transition. When they disagree, nothing warns you.
Deleted or written out-of-band, they never mark themselves for re-sync. The official counter says 0 pending while your tables disagree.
A plugin can declare HPOS support and still read orders through the legacy posts API. Under HPOS those reads return empty — no exception, no log line. In our 10-plugin calibration, 5 popular order plugins had this profile.
Duplicate or empty order keys crash the sync mid-flight with a database error — on stores that looked perfectly healthy in the admin.
"The order sync never finishes… wp_wc_orders tables remain empty despite thousands of completed actions."— wordpress.org support forums, store with 276,750 orders, Dec 2025
Everything read-only is free, forever. Everything that writes is Pro — and every write is preflighted, batch-verified, and reversible.
Six checks: environment (known-bad PHP/WC combos), storage mode, real cross-table consistency, field integrity sampling, order-key sanity, sync-queue state. Plain-language "what to do" for each.
Static analysis of your active plugins for legacy order-data access — including the dangerous verdict nobody else reports: declares compatible, reads legacy. File, line and evidence included.
Preflight gates (no --force exists), key repair, orphan restore, field reconciliation with your chosen source of truth, full read-back verification — and a controlled, verified rollback.
No locked features, no trials, no "upgrade to see your results".
| Capability | Free | Pro |
|---|---|---|
| Six-check health diagnosis (admin + WP-CLI) | ✓ | ✓ |
| Plugin compatibility scanner with evidence | ✓ | ✓ |
| Weekly consistency check | ✓ | ✓ |
| Order-key repair (dry-run planning) | ✓ plan | ✓ execute |
| Field reconciliation between storages | — | ✓ |
| Verified migration with orphan restore & refusal on mismatch | — | ✓ |
| Verified rollback (never strands orders) | — | ✓ |
| Daily monitoring + alert after every core/plugin update | — | ✓ |
No per-order fees, no usage surprises, no features moved behind higher tiers after you adopt. Prices lock in at purchase.
Early access: checkout opens with the public launch (Freemius — EU VAT handled). Early-access licenses get the first year at 50%.
No. The free plugin is strictly read-only — it never writes to your database, and nothing is sent anywhere. Even in Pro, every write requires an explicit flag, a confirmed backup, and passes per-batch verification.
Because every documented HPOS disaster we studied started with someone overriding a warning. If a gate is closed, the tool tells you exactly what unblocks it. Deliberately, there is no way around a failed verification.
The migration aborts without switching anything — your store keeps running exactly as before. You get every mismatching order with both values, and reconcile lets you choose the source of truth globally, per field, with an automatic non-empty rule.
It means the code contains legacy order-data access despite declaring HPOS compatibility. Whether a feature actually breaks depends on which code paths your store uses — the findings give you file and line so you (or the author) can check in minutes.