Keeping a WordPress staging site in sync with production, and pushing changes back safely

#The two problems with staging sites

Staging environments decay. A copy taken in March is useless for testing a change in September: the content, the orders, the users and half the plugin settings have moved on. And the moment a change is finished on staging, it has to reach production without dragging September's stale content with it. Every agency has a hand-rolled process for this, and every one of them has lost data with it at least once.

The workflow below runs on Dragon Migrate Pro, which pairs two sites once and then moves databases and files directly between them over a signed connection, on the free plugin's resumable job engine.

#Decide what flows which way

Write this down before touching anything, because it is the whole design:

• Production to staging: content and data. Posts, pages, products, orders, users, settings. Pulled on a schedule so staging is always recent.
• Staging to production: code and structure. Themes, plugins, and the specific database changes a build needs (new pages, menus, options). Pushed deliberately, by a person, after review.
• Never staging's whole database over production. That is how September's orders vanish.

#Step 1: pair the sites

On both sites install Dragon Migrate and Migrate Pro, and enter the licence under Tools, then Migrate, then Licence. Then under Connections, pair them: one site generates a pairing key, the other enters it. From then on every request between them is HMAC-SHA256 signed over method, path, timestamp, nonce and body, with replay protection. No WordPress account or password is exchanged; the endpoint authenticates the signature, not a user.

#Step 2: the scheduled pull that keeps staging fresh

On the staging site, set up a scheduled pull from production: database, with a serialization-safe find-and-replace of the production URL to the staging URL, and optionally the uploads. Nightly is typical. Each run:

1. Runs preflight checks: versions, table prefixes, disk space, writability.
2. Takes a rollback point on staging before the first write.
3. Transfers in resumable chunks with per-chunk checksums, so a dropped connection resumes rather than restarting.
4. Syncs files by size and checksum, sending only what staging does not already have. Nothing is ever deleted; a replaced file is quarantined first.
5. Emails you only if something failed.

Staging now wakes up every morning as a copy of last night's production. Testing happens against real data without anyone remembering to refresh it.

Two details worth setting on the staging side: exclude production's transactional email (an SMTP plugin's settings, or a constant that disables sending) so a copied store does not email real customers, and set the "search engines discouraged" option on staging, which the URL replacement leaves alone.

#Step 3: pushing a build to production

Pushes are always manual, by design: a scheduled push writes over a site nobody is watching. When a build is ready:

1. Freeze content edits on production for the duration, or accept that anything written during the push is lost.
2. Pull production one last time into staging so the build is applied on top of current data.
3. Push from staging to production: files (themes and plugins that changed) and, if the build needs it, the database with the staging URL replaced by the production one. Production takes its own rollback point first and stops rather than proceeding if it cannot create one.
4. Check production. If it is wrong, restore the rollback point from production's Backups tab; the transfer records where it stopped, so a retry resumes rather than repeating work.

For builds that only change code, push only files and leave the database alone. For builds that add pages or options, the safest pattern is to make those changes on production directly after the code push, or to push a database that was pulled minutes earlier, so the window for lost content is minutes rather than weeks.

#The audit trail

Every push, pull and file sync is logged with who ran it, when and from where, exportable as CSV. That is the answer when a client asks what changed on their site last Tuesday, and it is part of the evidence pack for the compliance workflow.

#From the terminal

Everything above is scriptable: wp dragon-migrate push, pull, sync-files and connections. A deployment pipeline can pull production into a fresh review environment on every pull request and tear it down after.

#When you do not have Pro

The same workflow runs on the free plugin with a download-and-upload step in the middle: export on one side, import on the other, with the same serialization-safe replacement and automatic safety backup. It is slower and manual, but it is the same engine; see migrating to a new domain for the mechanics.

#Checklist

• Direction of flow agreed and written down
• Sites paired; licence active on both
• Scheduled nightly pull into staging, with URL replacement
• Email sending disabled on staging
• Push procedure rehearsed once on a low-stakes change, including a rollback