{"id":10109,"date":"2026-11-04T15:35:55","date_gmt":"2026-11-04T12:35:55","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=10109"},"modified":"2026-11-04T07:05:52","modified_gmt":"2026-11-04T04:05:52","slug":"woocommerce-hpos-migration","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/woocommerce-hpos-migration\/","title":{"rendered":"Moving WooCommerce to HPOS: Compatibility Checks, Order Sync and Safe Rollback"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div class=\"aiw-summary\">\n<p class=\"aiw-box-title\">Quick summary<\/p>\n<p>WooCommerce HPOS (High-Performance Order Storage) stores orders in dedicated database tables. To migrate safely, test plugin compatibility on an isolated copy of your store, complete synchronization-the copying of order data between the two storage systems-then compare order fields after switching storage.<\/p>\n<ul>\n<li>Test payments, refunds and custom fields; do not rely only on compatibility declarations.<\/li>\n<li>Do not make HPOS the primary source while synchronization is pending.<\/li>\n<li>Check totals, statuses and customer details alongside order counts.<\/li>\n<li>Plan rollback around preserving current orders, not just restoring an old backup.<\/li>\n<\/ul>\n<\/div>\n<p>If your store keeps accepting orders, you may wonder where new orders will go and whether existing ones will remain visible. Until you switch, WooCommerce continues using the currently selected storage. Once synchronization finishes and you select HPOS as the primary source, WooCommerce reads and updates orders in the new tables, keeping existing order IDs. Your order-related plugins and custom code must support HPOS.<\/p>\n<p>You will first check order workflows on an isolated test copy. On the live store, you will temporarily restrict order changes, finish synchronization and record order details before switching, then compare those details afterward. If problems arise, you will identify which storage contains the latest data before rolling back, meaning returning to the previous storage. This helps you avoid losing newer orders or payment updates by restoring an older backup.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_HPOS_changes_and_what_to_prepare_before_migration\"><span class=\"toc_number toc_depth_1\">1.<\/span> What HPOS changes and what to prepare before migration<\/a><ul><li><a href=\"#Which_order_storage_is_authoritative\"><span class=\"toc_number toc_depth_2\">1.1.<\/span> Which order storage is authoritative?<\/a><\/li><li><a href=\"#Inventory_your_plugins_and_establish_a_recovery_baseline\"><span class=\"toc_number toc_depth_2\">1.2.<\/span> Inventory your plugins and establish a recovery baseline<\/a><\/li><\/ul><\/li><li><a href=\"#Verify_plugins_and_order_workflows_on_a_staging_copy\"><span class=\"toc_number toc_depth_1\">2.<\/span> Verify plugins and order workflows on a staging copy<\/a><ul><li><a href=\"#Restore_the_backup_to_an_isolated_staging_copy\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> Restore the backup to an isolated staging copy<\/a><\/li><li><a href=\"#Test_compatibility_and_the_HPOS_order_workflow\"><span class=\"toc_number toc_depth_2\">2.2.<\/span> Test compatibility and the HPOS order workflow<\/a><\/li><\/ul><\/li><li><a href=\"#Complete_synchronization_and_switch_the_live_store_to_HPOS\"><span class=\"toc_number toc_depth_1\">3.<\/span> Complete synchronization and switch the live store to HPOS<\/a><ul><li><a href=\"#Restrict_order_writes_and_take_a_fresh_backup\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> Restrict order writes and take a fresh backup<\/a><\/li><li><a href=\"#Finish_synchronization_while_WordPress_is_authoritative\"><span class=\"toc_number toc_depth_2\">3.2.<\/span> Finish synchronization while WordPress is authoritative<\/a><\/li><li><a href=\"#Select_HPOS_and_verify_orders_and_checkout\"><span class=\"toc_number toc_depth_2\">3.3.<\/span> Select HPOS and verify orders and checkout<\/a><\/li><\/ul><\/li><li><a href=\"#If_synchronization_stalls_or_orders_look_different\"><span class=\"toc_number toc_depth_1\">4.<\/span> If synchronization stalls or orders look different<\/a><ul><li><a href=\"#First_isolate_the_source_of_the_problem\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> First, isolate the source of the problem<\/a><\/li><li><a href=\"#Apply_a_targeted_fix_for_the_identified_cause\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> Apply a targeted fix for the identified cause<\/a><\/li><li><a href=\"#Update_the_legacy_storage_before_switching_back\"><span class=\"toc_number toc_depth_2\">4.3.<\/span> Update the legacy storage before switching back<\/a><\/li><\/ul><\/li><li><a href=\"#Frequently_Asked_Questions\"><span class=\"toc_number toc_depth_1\">5.<\/span> Frequently Asked Questions<\/a><ul><li><a href=\"#Does_HPOS_move_products_and_stock_to_new_tables_too\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> Does HPOS move products and stock to new tables too?<\/a><\/li><li><a href=\"#Will_existing_order_numbers_change\"><span class=\"toc_number toc_depth_2\">5.2.<\/span> Will existing order numbers change?<\/a><\/li><li><a href=\"#Is_HPOS_enabled_for_all_stores_at_once_in_Multisite\"><span class=\"toc_number toc_depth_2\">5.3.<\/span> Is HPOS enabled for all stores at once in Multisite?<\/a><\/li><li><a href=\"#Can_I_keep_using_older_order_archiving_tools\"><span class=\"toc_number toc_depth_2\">5.4.<\/span> Can I keep using older order archiving tools?<\/a><\/li><\/ul><\/li><li><a href=\"#Final_checklist_for_completing_the_migration\"><span class=\"toc_number toc_depth_1\">6.<\/span> Final checklist for completing the migration<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_HPOS_changes_and_what_to_prepare_before_migration\">What HPOS changes and what to prepare before migration<\/span><\/h2>\n<p>A WooCommerce HPOS migration copies your existing orders to dedicated database tables, then changes which storage WooCommerce uses to read and update them. HPOS (High-Performance Order Storage) separates order data from WordPress&#8217;s general content tables. Before switching, check which storage your store currently uses and whether the plugins that access orders support HPOS.<\/p>\n<h3><span id=\"Which_order_storage_is_authoritative\">Which order storage is authoritative?<\/span><\/h3>\n<p>In the legacy structure, the main order records are stored in <code>wp_posts<\/code> and <code>wp_postmeta<\/code>. HPOS uses <code>wp_wc_orders<\/code> and related dedicated order tables instead. Keeping order queries separate from general content queries can improve performance, but it will not solve every slowdown in your store.<\/p>\n<p>The <strong>authoritative data source<\/strong> is the storage WooCommerce relies on when reading and updating orders. The other storage may also contain order records, but those records are not necessarily current. Do not decide to switch simply because both sets of tables contain data.<\/p>\n<div class=\"aiw-note aiw-note-example\">\n<p class=\"aiw-box-title\">Example scenario<\/p>\n<p>You will follow a hypothetical single-site store, <code>magaza.example<\/code>, whose table prefix is <code>wp_<\/code>. The prefix is the shared beginning of its database table names. WordPress tables are initially authoritative; HPOS is off. You will restore a full backup to an independent staging copy-a separate site for testing-at <code>test.magaza.example<\/code>. This example assumes a WooCommerce version that supports HPOS and a payment plugin with a test mode. You will still check compatibility for the installed versions.<\/p>\n<\/div>\n<p>In your live admin dashboard, open <strong>WooCommerce &gt; Settings &gt; Advanced &gt; Features<\/strong>. Record the selection under <strong>Order data storage<\/strong>; do not change it yet. In this example, <strong>WordPress posts storage<\/strong> should be selected. This confirms that WooCommerce currently reads and updates orders in the legacy storage.<\/p>\n<p>In the same section, <strong>Enable compatibility mode<\/strong> synchronizes order data from the authoritative storage to the other storage. Synchronization keeps the second copy updated for migration or rollback, but you must let pending updates finish before switching. Compatibility mode does not automatically make a plugin that lacks HPOS support compatible. Labels and available controls may vary by WooCommerce version.<\/p>\n<h3><span id=\"Inventory_your_plugins_and_establish_a_recovery_baseline\">Inventory your plugins and establish a recovery baseline<\/span><\/h3>\n<p>Open <strong>Plugins &gt; Installed Plugins<\/strong> and list your plugin names and installed versions. Highlight payment, invoicing, shipping, subscription, accounting and order export tools: their order operations must work correctly after the switch. Also record your WooCommerce, WordPress and PHP versions from <strong>WooCommerce &gt; Status<\/strong>. Check compatibility for the versions you use, not just the product names.<\/p>\n<p>Add custom theme code, must-use plugins-plugins WordPress loads automatically-and external integrations that query order tables directly. For each entry, record the developer&#8217;s HPOS compatibility statement for the installed version and the operation you will test. For the payment plugin, record order creation and refunds; for the invoicing plugin, record invoice generation and custom order number retrieval. If a component has no compatibility statement, ask its developer to clarify support before testing.<\/p>\n<p>To prepare your staging copy, open the backup creation screen in your hosting panel or backup tool. Include <strong>all site files and the entire database<\/strong>, using the options provided by your tool. An order export alone cannot restore the store with its settings and plugins. When the backup finishes, check that the file archive, database copy and successful completion record are available. Store the backup separately from the live server with access restricted to authorized people, because it contains customer information.<\/p>\n<p>Recovery means restoring the files and database from the same backup together. In the next stage, you will restore this backup to an independent staging copy to check that it is usable. Keep order archiving, database cleanup and bulk updates separate from migration preparation so you can identify the effects of each change. If your live store continues taking orders, this first backup will not contain subsequent transactions. You will create a fresh recovery point before switching the live store.<\/p>\n<h2><span id=\"Verify_plugins_and_order_workflows_on_a_staging_copy\">Verify plugins and order workflows on a staging copy<\/span><\/h2>\n<h3><span id=\"Restore_the_backup_to_an_isolated_staging_copy\">Restore the backup to an isolated staging copy<\/span><\/h3>\n<p>For this example scenario, use your hosting panel&#8217;s domain section to create a separate site directory for <code>test.magaza.example<\/code>. Set this directory as the staging domain&#8217;s document root-the folder from which the site is served. Enable HTTPS and password protection for the staging site. In the panel&#8217;s database section, create a database named <code>magaza_test<\/code> and a dedicated user with access only to that database. Do not reuse the live database user: separate access helps keep staging changes out of the live database.<\/p>\n<p>Before running the copy, restrict its outbound connections in the firewall so it cannot contact live payment, shipping, accounting or email services. These network rules must apply to staging independently of the live site. If your panel does not provide that separation, ask your server administrator to establish it before starting the copy. The backup may contain pending automated tasks; password protection blocks visitors, but does not stop those tasks from contacting external services.<\/p>\n<p>In the panel&#8217;s file manager, extract the full file backup into the staging directory. Then use your database management tool&#8217;s <strong>Import<\/strong> section to load the SQL database backup into <code>magaza_test<\/code>. After the import finishes, you should see the copied WordPress tables in that database. In the staging copy&#8217;s <code>wp-config.php<\/code> file, replace the database name, username and password with the staging database details. Update the database server address too if it differs. Keep the <code>wp_<\/code> prefix; it must match the imported tables. If you use a persistent object cache, which retains cached data between requests, give staging a separate cache space or disable its cache connection before loading the copy.<\/p>\n<p>The address replacement below requires WP-CLI, the WordPress command-line tool, and SSH access, a secure way to connect to your server. If either is unavailable, ask your administrator to help complete this step. Connect through SSH and work from <strong>the staging site&#8217;s directory<\/strong>. Before running either command, confirm that the configuration file points to the staging database, not the live database.<\/p>\n<p>The first command previews the replacements without changing data. Review its output to confirm that it targets the copied site&#8217;s tables, then run the second command to replace the live address with the staging address. WP-CLI handles serialized fields-structured data stored as text-without breaking their format. The second command should report the completed replacements. Keep the original backup so you can rebuild only the staging copy if a change goes wrong.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp search-replace &#039;https:\/\/magaza.example&#039; &#039;https:\/\/test.magaza.example&#039; --all-tables-with-prefix --skip-columns=guid --dry-run\nwp search-replace &#039;https:\/\/magaza.example&#039; &#039;https:\/\/test.magaza.example&#039; --all-tables-with-prefix --skip-columns=guid<\/code><\/pre>\n<p>Sign in to the staging admin dashboard and check that the browser address stays on the staging domain. Under <strong>WooCommerce &gt; Settings &gt; Emails<\/strong>, open each enabled notification, clear its enable checkbox and save. Also remove live credentials from plugins that send email through SMTP, an email delivery protocol, or an API connection to an email service. Disabling WooCommerce notifications alone does not stop other plugins from sending messages; keep the outbound email block in place.<\/p>\n<p>Under <strong>WooCommerce &gt; Settings &gt; Advanced &gt; Webhooks<\/strong>, open each webhook, set its <strong>Status<\/strong> to <strong>Disabled<\/strong> and save. Webhooks send event notifications to external services. Confirm that the entries now show as disabled. Next, open <strong>WooCommerce &gt; Settings &gt; Payments<\/strong>, choose your payment plugin&#8217;s settings, enable <strong>Test mode<\/strong>, enter the provider&#8217;s test keys and save. Reopen the settings to confirm that test mode is selected.<\/p>\n<p>Allow outbound network access only to the payment test services you need, leaving live integrations blocked. If the provider uses the same address for test and live transactions, a network rule alone cannot distinguish them. Confirm that both test mode and test credentials are in place before attempting a staging payment.<\/p>\n<h3><span id=\"Test_compatibility_and_the_HPOS_order_workflow\">Test compatibility and the HPOS order workflow<\/span><\/h3>\n<p>On your staging copy at test.magaza.example, check incompatibility notices under <strong>Plugins &gt; Installed Plugins<\/strong> and read the developers&#8217; HPOS compatibility statements for your installed versions. An absence of notices is not proof of compatibility. Have your developer review custom code for order-related queries against <code>wp_posts<\/code> and <code>wp_postmeta<\/code>, and uses of <code>get_post_meta()<\/code>. Where necessary, replace direct access to order data with <code>wc_get_order()<\/code> and the order object&#8217;s methods for reading, updating and saving data. These methods let WooCommerce handle the selected storage rather than assuming orders are in the legacy tables.<\/p>\n<p>Under <strong>WooCommerce &gt; Orders<\/strong>, select samples of older, recent and refunded orders, plus orders with custom fields, and record their existing IDs. Note their statuses, totals, taxes, products, addresses, refunds and custom fields. You will use these notes to compare the same orders after switching storage.<\/p>\n<p>Open <strong>WooCommerce &gt; Settings &gt; Advanced &gt; Features<\/strong> on staging. Under <strong>Order data storage<\/strong>, leave <strong>WordPress posts storage<\/strong> selected, turn on <strong>Enable compatibility mode<\/strong> and click <strong>Save changes<\/strong>. This synchronizes orders to HPOS while WooCommerce continues to use WordPress storage. Watch the synchronization notice in the same section; use <strong>Sync now<\/strong> if that link appears in your version. Refresh the page until no synchronization remains pending. If the pending count is not decreasing, leave the storage selection unchanged and follow the troubleshooting section below to investigate background tasks.<\/p>\n<p>Once synchronization finishes, select <strong>High-performance order storage<\/strong> and click <strong>Save changes<\/strong>, leaving compatibility mode enabled. Reopen the page: HPOS should remain selected. Then return to <strong>WooCommerce &gt; Orders<\/strong>, open the same order IDs and compare their fields with your earlier notes. This checks that existing orders can be read correctly from the new storage, not just that the setting was saved.<\/p>\n<p>Place an order through the staging checkout using the test payment method configured earlier. Open the new order under <strong>WooCommerce &gt; Orders<\/strong> and check its status and payment transaction record. Check the purchased product&#8217;s stock quantity too; for a stock-managed product, the reduction should match the quantity purchased once the payment workflow triggers stock reduction. The transaction should also appear in the provider&#8217;s test dashboard.<\/p>\n<p>Try a test refund and confirm its record in both the order and the provider&#8217;s test dashboard. Test invoicing and shipping operations only in the relevant provider&#8217;s test environment. Record any integration that fails or cannot be tested as an issue to resolve before the live migration. Do not move orders from this copy to production. If the copy becomes unusable, restore the original backup only to staging.<\/p>\n<h2><span id=\"Complete_synchronization_and_switch_the_live_store_to_HPOS\">Complete synchronization and switch the live store to HPOS<\/span><\/h2>\n<h3><span id=\"Restrict_order_writes_and_take_a_fresh_backup\">Restrict order writes and take a fresh backup<\/span><\/h3>\n<p>Once staging checks pass, begin your planned migration window on <code>magaza.example<\/code>. In your maintenance tool&#8217;s access settings, block visitors&#8217; cart and checkout access while keeping administrator access open. Use another browser without an administrator session to confirm that a visitor cannot place a new order. A maintenance notice alone does not stop incoming orders.<\/p>\n<figure class=\"aiw-figure\" data-aiw-visual-id=\"10105\" data-aiw-visual-key=\"f6b7c1761c880e6467138f5e7fca8a916173152f6d92f35278d6a39bc9b676af\"><img decoding=\"async\" src=\"https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-bee7845cc92bafec9f3e.png\" alt=\"Five migration steps from restricting order writes through selecting HPOS, checking orders and reopening the store.\" width=\"840\" height=\"1414\" loading=\"lazy\" class=\"aiw-article-visual wp-image-10105\" srcset=\"https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-bee7845cc92bafec9f3e.png 840w, https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-bee7845cc92bafec9f3e-178x300.png 178w, https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-bee7845cc92bafec9f3e-608x1024.png 608w, https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-bee7845cc92bafec9f3e-768x1293.png 768w\" sizes=\"auto, (max-width: 840px) 100vw, 840px\" \/><figcaption>Workflow diagram: The flow shows synchronization finishing before the live storage switch, followed by order and payment checks before the store reopens.<\/figcaption><\/figure>\n<p>Ask your store team to pause order editing so that records stay unchanged during comparison. In your accounting and marketplace integrations&#8217; scheduling screens, pause order imports. Pause subscription renewals in the tool that manages them too. Keep a list of everything you pause so you can resume it after the checks.<\/p>\n<p>Allow payment notifications for transactions already in progress to arrive. Do not block server-to-server notifications from your payment provider: WooCommerce may need these to record a completed payment against an order. If a notification changes an order, repeat the final synchronization check before switching storage. Keep WordPress scheduled tasks running, because synchronization also uses background tasks.<\/p>\n<p>Once order creation and updates have settled, open your hosting panel&#8217;s backup screen, select all site files and the entire database, and start a fresh backup. Check the successful completion record and confirm that the backup files are available. This is your pre-migration recovery point, but it cannot contain orders or changes made afterward. If a problem occurs after the switch, preserve the current data before considering a restore from this older backup.<\/p>\n<h3><span id=\"Finish_synchronization_while_WordPress_is_authoritative\">Finish synchronization while WordPress is authoritative<\/span><\/h3>\n<p>In the live admin dashboard, open <strong>WooCommerce &gt; Settings &gt; Advanced &gt; Features<\/strong>. Under <strong>Order data storage<\/strong>, leave <strong>WordPress posts storage<\/strong> selected. Select the <strong>Enable compatibility mode<\/strong> checkbox and click <strong>Save changes<\/strong>. This synchronizes orders to HPOS while WordPress remains authoritative-the storage WooCommerce uses to read and update orders.<\/p>\n<p>Watch the pending synchronization notice in the same section; use <strong>Sync now<\/strong> if that link appears in your version. Refresh the page until it shows that no orders remain pending synchronization. If the pending count stops decreasing, leave the storage selection unchanged and <a href=\"https:\/\/www.dchost.com\/blog\/en\/why-woocommerce-action-scheduler-jobs-get-stuck\/\">troubleshoot the Action Scheduler queue<\/a>, which holds the background tasks used for synchronization. Resolve the cause before proceeding.<\/p>\n<h3><span id=\"Select_HPOS_and_verify_orders_and_checkout\">Select HPOS and verify orders and checkout<\/span><\/h3>\n<p>Under <strong>WooCommerce &gt; Orders<\/strong>, choose samples of older, recent and refunded orders, plus orders with custom fields, from the live store. Record their IDs and the current values of the fields listed below. These notes give you a before-and-after comparison of the same records. Then return to the <strong>Features<\/strong> screen, select <strong>High-performance order storage<\/strong> and click <strong>Save changes<\/strong>, leaving compatibility mode enabled. Reopen the page: HPOS should remain selected, meaning WooCommerce now uses it to read and update orders.<\/p>\n<p>On the <strong>Orders<\/strong> screen, open those same order IDs. Compare their statuses, products, quantities, totals, taxes, shipping costs, addresses, refunds, payment transaction IDs and custom fields with your pre-migration notes. The values should match; matching order counts alone cannot show that these details are correct.<\/p>\n<p>If the records match, use your maintenance tool to grant store access only to the person checking the payment workflow. Make a controlled real purchase permitted by your payment provider, keeping the live payment settings unchanged rather than putting the whole store into test mode. This purchase creates a real charge and notifications, so account for any automatic invoicing or shipping operations before placing it.<\/p>\n<p>Open the new order under <strong>WooCommerce &gt; Orders<\/strong> and compare its payment record with the transaction in your provider&#8217;s dashboard. Confirm that only one order was created, its status reflects the payment result, and stock changed as expected. If a refund is needed, use your normal refund process rather than deleting the order, so the charge and refund remain traceable.<\/p>\n<p>If any order fields or payment checks fail, keep the store restricted and investigate before reopening. Do not switch back to legacy storage unless you have confirmed that it contains the latest orders and changes. If all checks pass, remove the maintenance restriction and resume the paused integrations and tasks one at a time, following your list. Monitor the first new orders and the pending synchronization notice as normal activity resumes.<\/p>\n<h2><span id=\"If_synchronization_stalls_or_orders_look_different\">If synchronization stalls or orders look different<\/span><\/h2>\n<h3><span id=\"First_isolate_the_source_of_the_problem\">First, isolate the source of the problem<\/span><\/h3>\n<p>Stalled synchronization does not, by itself, mean orders have been lost. In the live admin dashboard, open <strong>WooCommerce &gt; Settings &gt; Advanced &gt; Features<\/strong>. Under <strong>Order data storage<\/strong>, record the selected authoritative storage-the source WooCommerce relies on-and any pending synchronization count or notice. Leave this selection unchanged while you investigate so you can keep track of which storage holds the current records.<\/p>\n<figure class=\"aiw-figure\" data-aiw-visual-id=\"10107\" data-aiw-visual-key=\"cbb18cb1bfd10d7bb111c299381f31fa9db74cd3a686a04c960f81c10b4cc774\"><img decoding=\"async\" src=\"https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-0e1e471c241ce4c3e08c.png\" alt=\"Rollback flow covering diagnosis, targeted fixes, restricted writes, reverse synchronization and a verified return to WordPress storage.\" width=\"840\" height=\"1453\" loading=\"lazy\" class=\"aiw-article-visual wp-image-10107\" srcset=\"https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-0e1e471c241ce4c3e08c.png 840w, https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-0e1e471c241ce4c3e08c-173x300.png 173w, https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-0e1e471c241ce4c3e08c-592x1024.png 592w, https:\/\/www.dchost.com\/blog\/wp-content\/uploads\/2026\/11\/dchost-flow-en-0e1e471c241ce4c3e08c-768x1328.png 768w\" sizes=\"auto, (max-width: 840px) 100vw, 840px\" \/><figcaption>Workflow diagram: Rollback is not a blind backup restore. The WordPress order store must match current HPOS data before you make it authoritative again.<\/figcaption><\/figure>\n<p>Under <strong>WooCommerce &gt; Status &gt; Scheduled Actions<\/strong>, inspect pending and failed tasks. Open the details of a task related to HPOS synchronization and note its execution time and any error message in its log. If pending tasks are overdue and never start, check how scheduled tasks are triggered. If tasks start but fail, use the error message to identify the plugin or database issue to investigate next.<\/p>\n<p>Under <strong>WooCommerce &gt; Status &gt; Logs<\/strong>, look for error entries from the same time. If an order looks different only in an accounting or reporting screen, open the same order ID under <strong>WooCommerce &gt; Orders<\/strong>. If the main order is correct but the integration&#8217;s output is wrong, first investigate whether the integration reads legacy tables directly or uses outdated cached data. A discrepancy in one output does not mean the entire order store is corrupted.<\/p>\n<h3><span id=\"Apply_a_targeted_fix_for_the_identified_cause\">Apply a targeted fix for the identified cause<\/span><\/h3>\n<p>If tasks are not starting and your hosting panel runs WordPress scheduled tasks, open the panel&#8217;s scheduled tasks section. Check that the relevant entry is enabled, points to the correct site and has no error in its latest execution log. If that entry is the cause, correct it without changing unrelated tasks. The absence of a panel entry is not necessarily an error: your site may use the WordPress scheduler triggered by visits.<\/p>\n<p>If the log identifies an error in a particular plugin, try the fix on <code>test.magaza.example<\/code> first. Repeat the same order operation and check that the error no longer occurs. Then take a fresh full backup and apply the fix to the live store. Keep the previous version of the plugin or code so you can undo the change if needed, rather than restore order data from an older backup. If a plugin update also changes the database, check its rollback instructions before applying it; replacing its files alone may not undo those changes. Do not delete the queue in bulk or rerun payment tasks indiscriminately.<\/p>\n<p>After applying the fix, use <strong>Sync now<\/strong> on the <strong>Features<\/strong> screen if that link is available. Refresh the page to check whether the pending count decreases. Return to the scheduled task logs to check for new errors, then compare the affected orders&#8217; fields with your pre-switch records. Synchronization should finish without new errors, and the fields should match. A pending count of zero alone does not show that custom fields were transferred correctly.<\/p>\n<h3><span id=\"Update_the_legacy_storage_before_switching_back\">Update the legacy storage before switching back<\/span><\/h3>\n<p>Before switching back from HPOS, make sure the WordPress order store contains the latest orders and updates. Use the earlier maintenance arrangements to pause operations that write order data, while still allowing payment notifications, and take a fresh full backup. Open <strong>WooCommerce &gt; Settings &gt; Advanced &gt; Features<\/strong>. Keep HPOS selected as the authoritative storage-the source WooCommerce reads and updates-and ensure <strong>Enable compatibility mode<\/strong> is checked, then click <strong>Save changes<\/strong>. Synchronization runs from HPOS to the WordPress order store, copying new records and changes made in HPOS.<\/p>\n<p>Refresh the <strong>Features<\/strong> screen until no synchronization remains pending. If another payment notification updates an order, repeat this check. Then, with your developer, compare the statuses, amounts, refunds and custom fields for the same order IDs in both stores, focusing on orders created or changed after migration. The current <strong>Orders<\/strong> screen shows the authoritative data; it cannot confirm that the other store is current. Have your developer compare both stores without editing their records. If the fields match, select <strong>WordPress posts storage<\/strong> on the <strong>Features<\/strong> screen and save. If synchronization cannot finish or differences remain, do not force the switch.<\/p>\n<p>Reopen the <strong>Features<\/strong> screen to confirm that WordPress storage is selected, then open the same order IDs under <strong>WooCommerce &gt; Orders<\/strong>. Compare their fields with your notes and repeat the controlled payment workflow check before reopening the store and resuming paused tasks. This confirms that the legacy storage is usable, rather than relying only on the synchronization counter.<\/p>\n<p>Restoring the pre-migration backup instead can remove subsequent orders, refunds and payment updates from your database; it does not reverse charges with your payment provider. If a backup restore is necessary, first preserve the current files and database in a separate full backup. Before restoring, reconcile orders, charges and refunds since the backup time against the provider&#8217;s records. Agree with your developer on how to transfer those later records and updates into the restored store without charging customers again.<\/p>\n<h2><span id=\"Frequently_Asked_Questions\">Frequently Asked Questions<\/span><\/h2>\n<h3><span id=\"Does_HPOS_move_products_and_stock_to_new_tables_too\">Does HPOS move products and stock to new tables too?<\/span><\/h3>\n<p>No. HPOS changes order storage; it does not move products, variations or their stock quantities into the new order tables. Product records in the example environment continue to use <code>wp_posts<\/code> and <code>wp_postmeta<\/code>. WooCommerce&#8217;s supporting product tables also remain separate. Enabling HPOS therefore does not automatically resolve slow product catalog queries.<\/p>\n<p>Stock reduction and restocking during refunds still depend on the order workflow. If you use an inventory integration, check its HPOS support. On staging, place a test order for a product with stock management enabled and check that its stock decreases. Then issue a test refund with the restocking option selected and check that the refunded quantity is added back.<\/p>\n<h3><span id=\"Will_existing_order_numbers_change\">Will existing order numbers change?<\/span><\/h3>\n<p>An HPOS migration does not change existing order IDs. However, the order number your customer sees may be a custom number generated by a plugin. If you use sequential or prefixed numbering, check that your installed version of the numbering plugin supports HPOS.<\/p>\n<p>Opening an order with the same ID in the admin dashboard does not prove that its custom number is correct on invoices or in emails. On your staging copy, compare existing orders&#8217; numbers in those outputs with your pre-migration records. Inspect email output without enabling delivery to real customers. Place a new test order too, and check that numbering continues in the expected sequence and format.<\/p>\n<h3><span id=\"Is_HPOS_enabled_for_all_stores_at_once_in_Multisite\">Is HPOS enabled for all stores at once in Multisite?<\/span><\/h3>\n<p>No. WordPress Multisite lets you run multiple sites within one WordPress installation. You select HPOS separately in each site&#8217;s WooCommerce settings. Each site also has its own order tables and synchronization status.<\/p>\n<p>A network-activated plugin, enabled across the installation, can affect every store. A successful check on one store does not show that the others work correctly. Unlike the single-site example, list payment methods and integrations separately for each store in your network. Base each store&#8217;s migration decision on its own synchronization and order checks.<\/p>\n<h3><span id=\"Can_I_keep_using_older_order_archiving_tools\">Can I keep using older order archiving tools?<\/span><\/h3>\n<p>Only after confirming that your installed version supports HPOS and your chosen storage configuration. A tool that searches for older orders directly in <code>wp_posts<\/code> may miss HPOS records or change only the synchronized copies. Look beyond a compatibility label: check the tool&#8217;s documentation for how archiving, deletion and restoration work with HPOS.<\/p>\n<p>An order export alone does not guarantee that you can restore those orders. Keep your <a href=\"https:\/\/www.dchost.com\/blog\/en\/woocommerce-order-archive-and-database-cleanup-keep-years-of-orders-without-slowing-down\/\">order archiving and database cleanup<\/a> plan separate from the migration. Before testing the tool, take a full backup of the isolated staging copy. Archive sample orders, then retrieve them using the tool&#8217;s restore function. Check that their IDs, amounts and custom fields are preserved. If the operation damages the data, restore that backup only to the staging copy.<\/p>\n<h2><span id=\"Final_checklist_for_completing_the_migration\">Final checklist for completing the migration<\/span><\/h2>\n<p>Before marking the migration as complete, check off each item below. Seeing HPOS selected is not enough; your order data and the operations that use it must also work correctly.<\/p>\n<ul>\n<li><strong>Compatibility:<\/strong> You have tested the order operations performed by active plugins, custom code and external integrations with HPOS enabled.<\/li>\n<li><strong>Synchronization:<\/strong> No orders remain pending synchronization, and the related scheduled tasks show no new errors.<\/li>\n<li><strong>Consistency:<\/strong> For your sample of older, recent and refunded orders, including orders with custom fields, the IDs, statuses, amounts and custom fields match your pre-migration notes.<\/li>\n<li><strong>Payments:<\/strong> Payment records match the provider&#8217;s dashboard and agree with order statuses. You have also checked stock movements, notifications and the refund workflow.<\/li>\n<li><strong>Rollback:<\/strong> You can access a current full backup. Your rollback plan includes completing synchronization from HPOS to WordPress storage and comparing order fields before selecting WordPress storage again.<\/li>\n<\/ul>\n<p>Next, decide who will monitor new orders and synchronization errors, and when they will check them. Schedule database cleanup and order archiving separately from this migration; test those operations on the staging copy before applying them to your live store.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Move WooCommerce orders to HPOS with a staging-first workflow. Check plugins and custom code, complete synchronization, compare order fields and verify checkout. Keep rollback safe by updating the WordPress order store before switching back.<\/p>\n","protected":false},"author":4,"featured_media":10098,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[183],"tags":[699,701,703,702,356,116],"class_list":["post-10109","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-hpos","tag-order-synchronization","tag-rollback","tag-staging","tag-woocommerce","tag-wordpress"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/10109","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=10109"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/10109\/revisions"}],"predecessor-version":[{"id":10111,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/10109\/revisions\/10111"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/10098"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=10109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=10109"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=10109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}