Push a WordPress staging site to live by moving only the files, database tables, or complete database that you have identified as authoritative. Treat the operation as a deployment: map the differences between staging and production, preserve newer live transactions, update URLs safely, remove staging-only settings, and run a production smoke test before declaring the release complete.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What a staging-to-live push actually changes
A WordPress site has two distinct parts. Its files contain WordPress core, themes, plugins, uploaded media, and custom code. Its database contains posts, pages, menus, widgets, users, options, plugin settings, and many forms of business data. A push can replace either part independently or replace both.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →That distinction matters because staging is usually an older copy of production. If a customer placed an order, someone submitted a lead form, a visitor left a comment, or an editor changed a page on production after the staging clone was created, the staging database does not contain that newer information. Importing the entire staging database can therefore erase valid live records even when the staging changes themselves are correct.
The safest deployment is the smallest one that delivers the release. Code changes normally require files. Content or settings changes normally require database data. A complete push is appropriate only when staging is the authoritative, current copy and production has no newer information that must survive.
Choose the deployment scope before touching production
| Deployment choice | Use it for | Main risk | What to verify first |
|---|---|---|---|
| Files only | Theme, plugin, custom code, or media changes that do not depend on new database settings | The code may expect database migrations, options, or content that was not moved | List every file changed and check whether the plugin or theme created or altered database tables or options |
| Database only | Posts, pages, menus, widgets, and configuration changes | Live content, orders, comments, leads, bookings, or users can be overwritten | Compare the staging database age with the latest production activity and identify tables that contain transactions |
| Selected database tables | A controlled content or settings release when production data must remain intact | A plugin may store related data across several tables, so an incomplete selection can break it | Confirm table ownership and dependencies with the plugin or theme documentation and make a restorable backup |
| Full files and database | A complete replacement when staging is a current clone and production has had no conflicting changes | Highest overwrite risk, including transactional data and user changes | Obtain explicit approval for the replacement and compare both sites immediately before the push |
| Managed push wizard | Operators who want guided selection of file groups and database tables | Feature availability and plan requirements vary, and a wrong selection can still overwrite data | Confirm the tool supports the required scope and that its backup can be restored |
| Manual migration | Hosts without a push wizard or deployments requiring precise control | More opportunities for database, URL, permission, and rewrite mistakes | Ensure you can access the production files, database, configuration, and web-server settings |
Preflight: freeze changes and create a rollback point
1. Schedule a short change window
Tell editors, support staff, and anyone handling orders or bookings when the deployment will occur. Stop nonessential edits on staging while you prepare the release. For a busy store or membership site, temporarily pause activities that would make it difficult to distinguish a deployment problem from a normal transaction.
2. Back up the live site and prove the backup is usable
Create a complete backup of the production files and database before copying anything. Download or otherwise preserve a copy outside the live server, record when it was made, and document the exact restoration point. A backup is not a rollback plan until you know where its files and database are stored and how you would restore them. Keep this copy until the site has passed smoke tests and completed at least one normal traffic and transaction cycle.
3. Record production activity that must survive
Write down the latest order, booking, lead, comment, user, and content timestamps on production. If the site uses an ecommerce or booking plugin, identify the tables that hold orders, customers, payment records, appointments, or other operational data. This inventory gives you a concrete check against accidental replacement.
4. Build a staging change list
Separate the proposed release into files and database effects:
- Theme templates, stylesheets, scripts, custom code, and child-theme files.
- Plugin additions, updates, and configuration files.
- Uploaded images, documents, and other media.
- Posts, pages, menus, widgets, users, and taxonomy changes.
- Plugin settings, scheduled tasks, API credentials, and custom tables.
For each item, mark whether it is required for the release, already present on production, or still experimental. Do not push an entire staging copy merely because it is convenient if the release is only a theme change.
Using a managed push wizard
WP STAGING documentation updated August 21, 2026 describes its Push Wizard as copying staged changes—files, database tables, or both—to the live site. The documentation also instructs operators to back up production with WP STAGING PRO before starting. The useful feature is scope selection: you can choose file groups and database tables rather than accepting an all-or-nothing overwrite.
- Open the staging installation in the push tool and select the production destination. Confirm the destination domain and environment; a staging-to-staging selection can be just as destructive as a live push if the target is wrong.
- Review the file groups offered by the wizard. Select themes, plugins, media, or other groups only when they are part of the release. If a group contains unrelated experiments, move those changes out of the release before continuing.
- Review the database-table list. Select only tables whose staging state is authoritative. Leave order, customer, booking, comment, lead, and other live-activity tables out unless you have deliberately reconciled their contents.
- Read the overwrite summary. Check the number and names of files and tables, the target URL, and any warning about replacements. Stop if the summary is broader than the change list you prepared.
- Start the push during the change window and watch for completion or error messages. Do not close the process or begin editing production while the copy is running.
- After completion, apply the production-setting and validation checks in this article. A wizard can copy data and perform migration replacements, but it cannot decide which live business records should win.
A managed tool reduces manual copying and can handle serialization-safe replacements, but it does not make a full database push safe by itself. Plan requirements and available features vary by edition and current provider configuration, so verify them in the tool before the change window.
Manual deployment, step by step
1. Put the production site in a controlled state
Use a maintenance notice or another clearly communicated change window if visitors could encounter mixed versions while files and data are being copied. Do not assume a maintenance page prevents every request from reaching the old or new code. The purpose is to reduce concurrent edits and transactions while you switch versions.
2. Copy the approved files
Move the selected theme, plugin, custom-code, and media files to the production locations. Preserve the production directory structure and ownership. If you are replacing a plugin or theme, make sure the complete release is present rather than copying only a single edited file that depends on other files.
Confirm filesystem ownership and permissions after the transfer. Files that are owned by the wrong account can produce update failures, missing uploads, or server errors even when the code itself is correct.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
3. Import only the approved database data
Export the staging database or selected tables in a format your production database server accepts, then import them into the production database after taking the live backup. If the release requires several related tables, import them as a planned set; do not guess based only on table names.
For a database-only release, leave tables containing newer production activity untouched. For a full replacement, understand that importing the staging database will replace the corresponding live rows, options, and user data. Keep the original production export available until validation is complete.
4. Update production configuration
Check wp-config.php and the hosting configuration for the production database name, user, password, host, table prefix, and environment-specific constants. Remove staging database credentials and confirm that the web server points at the intended production directory.
Review filesystem permissions and PHP or server settings required by the active theme and plugins. A successful database import does not prove that the production process can read, write, or execute every required file.
Free tools Windows power users keep installed
One-click scans. No signup required.
5. Replace the staging URL and path safely
If staging used a different domain, subdirectory, protocol, or uploads path, update every stored reference from the staging location to the production location. WordPress warns against a simple blanket text replacement because serialized PHP values include lengths that must change when a URL changes. The WordPress Advanced Administration Handbook recommends the Search and Replace for WordPress Databases Script for this task. Use a migration tool or another serialization-aware method rather than editing a raw SQL dump with ordinary find-and-replace.
Search for both the full staging URL and any staging subdirectory or path. Check content, options, widget settings, navigation URLs, attachment metadata, and plugin configuration. Treat an HTTP-to-HTTPS change as a URL migration as well, not merely a browser redirect.
6. Reconfigure permalinks and rewrite rules
Sign in to the production WordPress dashboard and open Settings > Permalinks. Save the existing structure again so WordPress regenerates rewrite rules. If the site uses Apache, verify the production .htaccess rules; other web servers may require their own rewrite configuration. A move can leave otherwise healthy pages returning 404 errors until these rules are rebuilt.
Protect orders, customers, comments, and other live records
The staging database is a snapshot, not a time machine. Any production activity after the clone was created is newer than the staging copy. The most important records to protect include:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →- WooCommerce or other ecommerce orders, refunds, customers, and payment-related records.
- Bookings, appointments, subscriptions, memberships, and form submissions.
- Comments, support requests, contact leads, and newsletter sign-ups.
- New user accounts, password changes, and role assignments.
- Editorial updates made directly on production.
When the release is code-only, deploy files and leave the live database in place. When content must move, use selected tables or a deliberate content-export process instead of replacing the entire database. If a plugin stores one logical record across several tables, identify those relationships before selecting anything. A partial import that moves an order header but not its line items or metadata can be worse than no import.
If staging and production both contain legitimate edits to the same page or setting, resolve the conflict manually and document which version is authoritative. Do not rely on import order to merge them; a later import normally overwrites an earlier row.
Remove staging-only behavior after the copy
Staging environments commonly contain safeguards and test integrations that must not remain on a public site. Before removing the maintenance notice, inspect:
Recommended Free Tools
- Login protection, basic authentication, temporary administrator accounts, and staging-only access rules.
- No-index directives, robots exclusions, password protection, and test XML sitemap settings.
- Debug mode, verbose error display, development logging, and test PHP constants.
- Sandbox payment gateways, test API keys, webhooks, and placeholder integrations.
- Staging email routing, disabled mail delivery, test recipient addresses, and cron schedules.
- Temporary redirects, host-specific environment variables, and staging-only domain references.
Enable the production analytics property and email configuration, then confirm that secrets belong to the production environment. Remove test users and keys only after checking that no legitimate production workflow depends on them.
Validate the live site immediately
Use a representative checklist rather than checking only the homepage. Test from a private browser window and, where possible, from a second network so cached staging responses do not hide a problem.
Public pages and links
- Open the homepage, a post, a page, an archive, a search result, and a representative custom template.
- Follow internal links and confirm that they use the production domain and protocol.
- Load representative images, downloads, and responsive image sizes.
- Check canonical URLs, redirects, and a sample of old URLs that should resolve.
Administration and permissions
- Sign in with an administrator account and a normal editor or staff account.
- Confirm that roles, capabilities, menus, widgets, and plugin screens behave as intended.
- Expect to authenticate again after a full database push because session data may have been replaced.
Forms, email, and revenue paths
- Submit each important contact, registration, and lead form with a controlled test value.
- Verify that messages reach the intended production mailbox and that confirmation messages do not expose staging addresses.
- For a store or booking system, test the complete checkout or reservation path with the provider’s approved test procedure, then verify that no test transaction is recorded as a real sale.
- Check that existing orders, bookings, customer records, and comments remain present.
Indexing and operations
- Inspect the XML sitemap and robots controls for accidental no-index or disallow directives.
- Confirm analytics, monitoring, scheduled jobs, backups, and production cron behavior.
- Review the server and WordPress error logs for fatal errors, missing files, database errors, and failed scheduled tasks.
Rollback and troubleshooting
Pages show a 404 after the push
Resave Settings > Permalinks, then verify the web-server rewrite rules and document root. If only media fails, check the uploads path, URL replacement, and filesystem permissions.
The site displays the staging domain
Find remaining staging references in the database, configuration, cached HTML, and plugin settings. Run a serialization-aware replacement for the exact domain and path, clear application and page caches, and test from a private window.
A plugin reports missing tables or settings
Compare the plugin version and its required database migrations between staging and production. Import the related tables or run the plugin’s production migration procedure only after preserving the current database. A files-only push can install code that expects options or schema changes that were never moved.
Orders or leads are missing
Stop further edits, preserve logs, and restore the pre-push production database or the affected tables from the verified backup. Do not attempt to repair by importing the entire staging database again. Reconcile any transactions created during the failed deployment before reopening the site.
Users are unexpectedly logged out
A full database replacement can invalidate sessions and authentication tokens. Ask users to sign in again after confirming that accounts and roles are intact. If passwords or roles changed unexpectedly, restore the appropriate production user data rather than copying the older staging user table.
The push tool stops or reports an error
Keep the site in the controlled change state until you know which files and tables were copied. Review the tool’s log, compare the target against the change list, and restore the production backup if the final state is uncertain. Retry only after resolving storage, permission, timeout, or database-compatibility errors.
When a manual move is preferable
Choose a manual migration when the host does not provide a push workflow, when the release crosses several environments with different database credentials, or when you need a precise table-by-table deployment. It gives you control over files, configuration, URL replacement, and rollback, but it also requires competence with backups, database imports, permissions, and rewrite rules.
A push wizard is convenient when its table and file selectors match your release and its backup process is acceptable. A manual process is safer when the wizard cannot express the boundary between staging test data and live transactions. In either case, the decision is about scope and data ownership, not about choosing the fastest button.
Quick Recap
Release checklist
- Change window agreed and editors or operators notified.
- Production files and database backed up, downloaded or preserved, and restorable.
- Staging files, options, tables, and experimental changes inventoried.
- Orders, customers, bookings, comments, leads, users, and other live records identified.
- Files-only, database-only, selected-table, or full-push scope approved.
- Production credentials, ownership, permissions, and destination path confirmed.
- Serialization-safe domain and path replacement completed where needed.
- Staging protection, no-index rules, debug settings, test keys, email routes, and cron settings removed or converted.
- Permalinks and server rewrite rules regenerated.
- Public pages, links, media, login, permissions, forms, email, checkout, indexing, analytics, and scheduled jobs tested.
- Rollback backup retained until normal traffic and transactions have completed without errors.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
