How to Push WordPress Staging to Live Without Losing Data

The moment you push WordPress staging to live is the single most destructive operation a site owner performs on purpose. Everything else — plugin updates, theme edits, PHP version changes — is reversible in minutes. A database overwrite is not. Furthermore, the failure is silent: the site loads perfectly, the new design is live, and nobody notices the missing orders until a customer emails asking where their receipt went.

Notably, almost every guide on this topic was written for managed hosts with a one-click “Push to Production” button, or by a plugin vendor whose answer is a Pro upgrade. This guide is neither. It is written for cPanel shared hosting, and it gives you the exact table list — which is the one thing the other guides never publish.

What Actually Breaks When You Push WordPress Staging to Live

Specifically, what breaks is not the code you tested — it is the data production created while you were testing. Staging is a photograph of your site taken at a moment in time. Meanwhile, production kept moving: orders arrived, users registered, comments posted, contact forms filled. Consequently, pushing the photograph back on top of a moving site erases everything that moved.

The Overwrite Window: Every Row Production Gained While You Tested

We call this the Overwrite Window: the elapsed time between cloning staging and pushing it back, multiplied by your production write rate. Therefore a store taking four orders an hour that spends three days on a redesign is risking roughly 288 orders. In practice, the number surprises people, because the instinct is to judge risk by site size rather than by staging duration.

Additionally, the window applies to more than commerce. Membership registrations, WooCommerce sessions holding active carts, Action Scheduler jobs queued for delivery, comment threads, and form submissions all accumulate on production and all sit in database tables. Ultimately, the fix is arithmetic rather than luck: measure the window before you push WordPress staging to live, then exclude the tables that filled during it.

Why “Just Exclude the Orders Table” Became Wrong Advice in 2024

Here is the part almost every published guide gets wrong. WooCommerce moved order storage. Since version 8.2, released in October 2023, High-Performance Order Storage is enabled by default on new installations, and orders live in dedicated tables rather than in wp_posts and wp_postmeta. The HPOS upgrade recipe book documents the schema in full.

Consequently, three generations of advice are now circulating simultaneously, and two of them are wrong for any given store. Pre-2024 guides say to exclude wp_posts — which protects nothing on an HPOS store. Newer guides say to exclude wp_wc_orders — which protects nothing on a legacy store. Notably, one widely-ranked tutorial names a table called wp_woocommerce_orders, which has never existed in any version of WooCommerce.

Furthermore, there is a trap that catches even correct HPOS advice: order line items never moved. Both storage modes keep them in wp_woocommerce_order_items and wp_woocommerce_order_itemmeta. Therefore excluding the four wp_wc_ tables and nothing else preserves the order records while overwriting what was in them.

The AHosting Staging Push Exclusion Map

Specifically, this is the table-by-table verdict for a WordPress site pushing staging changes back to production. In practice, “Never push” means production is the authoritative copy of that table and staging’s version must be discarded. Additionally, “Conditional” means the answer depends on whether the table changed on both sides.

Table	What it holds	Push from staging?	What you lose if you push it
wp_options	Site settings, serialized plugin config	Conditional	Any setting changed on production during the window
wp_posts, wp_postmeta	Content; legacy WooCommerce orders	Conditional	New posts, and all orders on a legacy-storage store
wp_users, wp_usermeta	Accounts, roles, password hashes	Never push	Every registration and password reset since the clone
wp_comments, wp_commentmeta	Comments and reviews	Never push	Every comment and product review since the clone
wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data, wp_wc_orders_meta	HPOS order records	Never push	Every order on an HPOS or compatibility-mode store
wp_woocommerce_order_items, wp_woocommerce_order_itemmeta	Order line items — legacy tables in both modes	Never push	The contents of every order, in every storage mode
wp_woocommerce_sessions	Active carts	Never push	Every cart in progress at push time
wp_wc_customer_lookup, wp_wc_order_coupon_lookup, wp_wc_product_meta_lookup	Analytics lookup tables	Never push	Reporting history — regenerate rather than restore
wp_actionscheduler_actions, wp_actionscheduler_logs	Queued background jobs	Never push	Pending emails, subscription renewals, sync jobs
wp_terms, wp_term_taxonomy, wp_term_relationships	Categories, tags, product attributes	Conditional	Terms created on production during the window

Notably, a store on a managed WooCommerce hosting plan still needs this map, because the exclusion list is a property of WooCommerce’s schema rather than of the server. Ultimately, the host controls whether the push completes; the map controls whether it costs you anything.

How to Tell Whether Your Store Runs HPOS, Compatibility Mode, or Legacy Storage

In WP Admin, open WooCommerce, then Settings, then Advanced, then Features. Specifically, “High-performance order storage” checked with compatibility mode unchecked means HPOS only. Both checked means compatibility mode, where every order is written to both table families at once. Neither checked means legacy post storage.

Consequently, compatibility mode is the most dangerous state for a push, because excluding one family and not the other leaves the two out of sync — the store then shows an order in one view and not the other. Therefore confirm the mode before you build the exclusion list, not after.

Three Ways to Push WordPress Staging to Live on cPanel Shared Hosting

Specifically, cPanel shared hosting has no vendor “Push to Production” button, which turns out to be an advantage: you choose the method by data risk rather than by what the dashboard offers. Additionally, all three ways to push WordPress staging to live below work on any cPanel account with staging, and none of them require shell access.

Method	What moves	Data risk	Typical time	Best for
Selective table push	Files plus a named subset of tables	Low — production tables untouched	10–25 min	Stores, membership sites, anything with live writes
Files-only push with options diff	wp-content only, settings re-entered by hand	Lowest — database never written	15–40 min	Theme and plugin updates with few setting changes
Full push behind maintenance mode	Everything, production overwritten	High — total, and irreversible without a backup	5–15 min	Content-only sites with no registrations or comments

Method One: Selective Table Push

Specifically, you export only the tables that changed on staging, then import them over production while leaving the excluded tables alone. In practice, this is the default choice for any site that accepts orders, registrations, or comments. Furthermore, it is the only method where you can name in advance exactly which rows are at risk.

Method Two: Files-Only Push With an Options Diff

Notably, most staging work changes code rather than data. A theme update, a plugin version bump, and a template edit all live in wp-content. Therefore you can copy the files across and never touch the database at all, then re-enter the handful of settings you changed through WP Admin on production.

However, this method has a real cost: plugin configuration usually lives in wp_options, so a page builder or a checkout plugin configured on staging will arrive on production unconfigured. Consequently, keep a written list of every setting you change on staging, or the diff becomes guesswork.

Method Three: Full Push Behind a Maintenance Window

In practice, a full push is legitimate for brochure sites, portfolios, and documentation sites where the owner is the only person writing to the database. Additionally, enabling maintenance mode first shrinks the Overwrite Window to the length of the push itself, which turns a three-day risk into a five-minute one.

How to Push WordPress Staging to Live in Seven Steps

To push WordPress staging to live safely: back up production, exclude every table it wrote to since the clone, replace URLs with a serialization-aware tool, push files before tables, then reconcile the row counts. The seven steps below expand that sequence.

First Step: Measure the Overwrite Window and Back Up Production

Firstly, note the clone date and count what production gained since: orders, users, comments, form entries. Then take a full backup of production — files and database — and confirm it downloaded rather than trusting that it exists on the server. Notably, a backup stored only in the account you are about to overwrite is not a backup.

Second Step: Build the Exclusion List Before You Push WordPress Staging to Live

Secondly, confirm your WooCommerce storage mode, then copy the matching rows out of the Exclusion Map into a written list. Additionally, check your own plugins: membership, LMS, booking, and form plugins each create their own tables, and the WordPress database API documentation explains how those custom tables register alongside core ones. In practice, anything whose name you do not recognize should be excluded until you have checked what writes to it.

Third Step: Run a Serialization-Safe URL Replace

Thirdly, replace the staging domain with the production domain — and never with a raw SQL UPDATE. Specifically, WordPress stores plugin and theme configuration as PHP serialized strings, which record their own byte length. Consequently, swapping staging.example.com for example.com leaves a length prefix that no longer matches, the value fails to unserialize, and the setting silently reverts to its default.

Therefore use a serialization-aware tool. WP-CLI’s search-replace command unpacks serialized values, leaves primary keys alone, and offers a --dry-run flag that reports every change before writing one. Furthermore, run the dry run first every time — it costs seconds and it catches the case where you typed the wrong domain.

Fourth Step: Push Files First, Tables Second

Fourthly, move wp-content across before you touch the database, so the code that the new rows expect is already in place. Additionally, export the staging tables with a consistent snapshot: the mysqldump documentation notes that --single-transaction produces a consistent dump for InnoDB tables without locking other clients, though MyISAM and MEMORY tables can still change mid-dump.

Fifth Step: Reconcile Order and User Counts

Fifthly, compare the counts you wrote down in the first step against what production shows now. Specifically, check the order total, the registered user total, and the newest order ID. Notably, if any number moved downward, stop and restore the backup immediately — a partial recovery attempted an hour later is far harder than a clean restore attempted at once.

Sixth Step: Flush Caches and Regenerate Permalinks

Sixthly, purge the page cache, then open Settings and Permalinks in WP Admin and save without changing anything. In practice, that single save rewrites the rewrite rules against production’s structure, which is the fix for the “everything 404s except the homepage” symptom that follows most pushes.

Seventh Step: Watch the Error Log Before You Walk Away

Finally, place a test order, register a test account, and watch the cPanel error log for fifteen minutes. Consequently, you catch the two failures that appear only under real traffic: a plugin querying a table you excluded, and a scheduled job that cannot find the row it queued against. Ultimately, fifteen minutes of watching is the cheapest insurance in this entire process.

Server Resources That Decide Whether You Can Push WordPress Staging to Live

Specifically, a push is a burst of heavy PHP and database work running on the same account that is serving visitors. Therefore the ceiling is not disk space — it is concurrency and memory. AHosting publishes both figures per plan, which is unusual enough that it is worth stating them plainly: Bronze allocates 15 entry processes and 512MB of container memory, Silver 25 and 1024MB, and Gold 40 and 2048MB.

Consequently, an import that pins several workers for minutes leaves fewer for visitors. Notably, CloudLinux queues the overflow rather than rejecting it outright, and on AHosting’s LiteSpeed stack that queue drains for up to 120 seconds before a visitor sees a 503. Additionally, cached pages consume zero entry processes, so LSCache keeps the storefront answering while the push runs underneath it — which is the single most useful thing you can do before starting.

Two Memory Ceilings, One Packet Limit, and Why They Get Confused

Furthermore, two separate memory ceilings apply, and confusing them wastes hours. PHP’s own memory_limit defaults to 256MB on PHP 8.4 accounts and is raisable through cPanel’s PHP INI Editor without a support ticket; the container PMEM cap is the harder limit, as our guide to why raising the WordPress memory limit often does not work explains in detail. Meanwhile, a browser-driven SQL import is also bounded by the database packet size — the MariaDB server system variables reference documents max_allowed_packet, which is what fails a large import halfway through and leaves a partially written database.

What AHosting Includes Before You Push WordPress Staging to Live

In practice, staging is included on every AHosting WordPress plan rather than reserved for higher tiers, and the same PHP worker arithmetic that governs a push governs everyday traffic — our breakdown of the PHP worker math behind concurrent capacity shows how to size it. For the environment requirements behind the clone itself, see what your hosting plan needs to run a staging site.

Staging Push Exclusion Builder

Notably, the exclusion list changes with your site type and storage mode. Answer the four questions below and the tool prints the list to copy into your push tool, along with the method it recommends.

When You Cannot Safely Push WordPress Staging to Live on Shared Hosting

Specifically, three signals mean the push has outgrown a shared account. Firstly, the database exceeds roughly 2 GB and browser-driven imports keep timing out. Secondly, the store writes continuously enough that no maintenance window is acceptable. Thirdly, the same push has to run across many client sites on a schedule.

In those cases, dedicated resources change the arithmetic: workers are guaranteed rather than shared, and shell access means the import runs from the command line instead of through a browser session that can expire mid-write. Specifically, a store that has outgrown shared infrastructure stops competing for entry processes at all. Meanwhile, agencies running the same workflow across a client portfolio get per-account isolation on reseller plans, so one client’s import never draws down another’s worker pool.

Notably, none of this applies to moving a site between hosting providers, which is a different operation with a different failure mode — our guide to moving a WordPress site between hosts with zero downtime covers the DNS side.

The Checklist to Run Before and After You Push WordPress Staging to Live

• Record production’s order count, user count, and newest order ID.
• Download a full production backup and verify the file opens.
• Confirm the WooCommerce order storage mode in Settings, Advanced, Features.
• Write the exclusion list from the Exclusion Map, plus any plugin tables.
• Enable maintenance mode if any pushed table is one production writes to.
• Run the URL replace as a dry run first, then for real.
• Push files, then push the named tables.
• Save Settings, Permalinks without changing anything.
• Purge the page cache and the CDN.
• Re-check the three counts from step one.
• Place a test order and register a test account.
• Watch the error log for fifteen minutes before closing the laptop.

Frequently Asked Questions About How to Push WordPress Staging to Live

How do I push WordPress staging to live without losing orders placed during testing in 2026?

Specifically, exclude every table that production wrote to while you were testing, then push only the tables that changed on staging. Users, comments, sessions and all WooCommerce order tables stay untouched on production. Furthermore, the exact table list depends on whether your store runs HPOS, compatibility mode, or legacy post storage, which is why the Exclusion Map in this guide splits them out by mode.

Selective table push vs full database push: which is safer when you push WordPress staging to live?

Specifically, a selective table push is safer in every case where production accepted a single order, comment, or registration after you cloned. A full push overwrites the entire database and cannot be partially undone. However, a full push is legitimate for content-only sites under a short maintenance window, and the three-method comparison table in this guide shows the exact data risk of each.

Which WooCommerce tables must be excluded when pushing staging to live on an HPOS store in 2026?

Specifically, exclude wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data and wp_wc_orders_meta, plus wp_woocommerce_order_items and wp_woocommerce_order_itemmeta. Notably, those last two are the trap: line items still live in the legacy tables even on a fully migrated HPOS store, so excluding only the wp_wc_ tables leaves orders whose contents get overwritten.

When should I put a WooCommerce store into maintenance mode before I push WordPress staging to live on an AHosting Bronze plan?

Typically, use maintenance mode whenever the push includes any table production also writes to, and always on Bronze, where 15 entry processes and a 512MB PMEM ceiling leave little headroom for a long import running alongside live traffic. In practice, a five-minute maintenance window costs less than one lost order.

What is the Overwrite Window and how do I calculate how much live data is at risk?

Specifically, the Overwrite Window is the elapsed time between cloning staging and pushing it back, multiplied by your production write rate. Therefore a store taking four orders an hour that stages for three days is risking roughly 288 orders. Additionally, the same arithmetic applies to registrations, comments and form entries, which is why the window matters more than the site’s size.

AHosting shared hosting vs VPS: which handles a 2 GB database import when you push WordPress staging to live?

Typically, an AHosting Gold plan handles a 2 GB import comfortably at 40 entry processes and 2048MB PMEM, while Bronze at 15 entry processes and 512MB frequently stalls. In contrast, a VPS gives dedicated workers and shell access, so the import runs from the command line rather than through a browser session that can time out.

Why does a raw SQL find and replace corrupt serialized WordPress data during a staging push?

Specifically, PHP serialized strings store their own byte length, so replacing a shorter domain with a longer one leaves a length prefix that no longer matches the string. Consequently the value fails to unserialize and the setting silently reverts to default. Therefore use a serialization-aware tool, which is exactly what the third step of this guide covers.

What happens if I push WordPress staging to live while WooCommerce compatibility mode is still enabled?

Notably, compatibility mode writes every order to both the HPOS tables and the legacy post tables, so excluding only one family desynchronizes the two. As a result, the store shows orders in one view and not the other, and reconciliation requires a resync. In practice, confirm your storage mode before building the exclusion list.

How long does a staging to live push take on shared hosting before it times out?

Typically, a database under 500MB imports in two to six minutes on shared hosting. However, browser-driven imports are bounded by the web server connection timeout, which on AHosting’s LiteSpeed stack is 120 seconds for the queue window. Consequently, larger databases need a command-line import or a plan with more entry processes.

Does AHosting include staging on every WordPress plan, and what PHP memory does the push need in 2026?

Specifically, staging is included on AHosting WordPress Bronze, Silver and Gold at no extra cost. Additionally, accounts default to PHP 8.4 with a 256MB memory_limit, which customers can raise through cPanel’s PHP INI Editor without a support ticket. Notably, the container PMEM ceiling is the harder limit, and it scales from 512MB on Bronze to 2048MB on Gold.