Websites & support / Explainer
Can publishing a staging website lose your live orders?
Yes, it can, if the release replaces the live database with an older copy. A staging site gives us somewhere to test changes, but the live shop can carry on receiving orders while that testing happens.
Suppose the copy was taken on Monday. By Wednesday, the live shop has new orders and customer details. Publishing Monday’s database over Wednesday’s shop could remove records that did not exist when the copy was made.
I would want the release plan to explain how those current records are protected. “It worked on staging” tells us the change was tested there. We still need to agree how it reaches the live site.
Find out what the staging copy contains
A WordPress site has files and a database. The files include themes, plugins and uploads. The database contains content and settings, along with records used by the shop and its extensions.
A staging facility may let the developer copy files, the database or selected parts between the two sites. The available controls depend on the host and setup. Ask what the release button actually replaces before using it.
WordPress.com’s own staging documentation gives a clear example: pushing a staging database can overwrite newer production orders, product changes and customer information. That is the behaviour of that facility; another host needs checking against its own procedure.
Stop the test copy acting like the live business
A copied shop may still have connections to email, accounts or fulfilment services. Before testing, agree which integrations must be disabled or redirected to test facilities. Keep access to the copy controlled and prevent it from appearing in search.
WooCommerce warns that test orders can trigger emails and that other integrations may be unable to distinguish them from real orders. A payment gateway in sandbox mode addresses the payment part; it does not establish that every connected service is safe to use.
Use appropriate test accounts and data. The developer should be able to show where a test order goes and confirm it cannot create an unwanted customer message, payment or dispatch request.
Source: WooCommerce: testing orders
Decide which changes need to move
A theme-code change may need a different release from changes to pages, product records or plugin settings. In WordPress.com’s documented facility, file changes can be copied separately, while posts, pages and settings involve the database.
Copying files alone will not carry every kind of change. Copying the whole database can carry much more than the change you intended. Ask the developer to identify where the work is stored and how it will be released on this particular site.
If the plan needs a pause in new orders or other live editing, agree the timing and the customer-facing behaviour in advance. Do not assume a staging tool automatically merges every newer record correctly.
| Part of the change | What to establish |
|---|---|
| Theme or plugin files | Which files move and whether any related data change is required |
| Pages and settings | Where those changes are stored and what the publishing operation replaces |
| Current shop records | How newer orders, customers and product changes remain intact |
| Connected services | Which live settings must remain and how test activity stays isolated |
Keep a current recovery point and a written plan
Before the switch, confirm the current backup and the route back if the release fails. Include the live records received since staging was created. A rollback to an older database has the same recent-record problem as an old staging push.
Write down the steps, who performs them and what counts as a successful release. Rehearse the risky parts in an appropriate test setup where possible. If somebody else manages the payment or accounts connection, include their checks in the plan.
A useful handover should make clear what the staging facility does and what still needs a developer’s judgement. An owner should not have to discover the scope of a database replacement by pressing the button.
Check the records as well as the new page
After release, confirm the intended change is visible and check recent live orders against the records you expected to keep. Check the connected systems that depend on those records too.
Follow the agreed customer journey on a phone and check the live payment configuration without exposing customers to a test gateway. Any actual test order needs a separately agreed safe procedure and destination.
If the visible change is missing, investigate the release result and caching before repeating a database operation. Keep the checks with the release record so the next update starts with a procedure somebody has already verified.
Sources
Checked on 23 October 2026.
- WordPress.com: sync staging and production sites
This provider’s file/database synchronisation choices, newer live-data replacement risks and checks for changes that do not appear.
- WooCommerce: testing orders
Test payments, staging use and the emails and connected actions test orders can still trigger.