A transactional WordPress migration must preserve orders, accounts, bookings and submissions created while the move is happening. Copying yesterday's database onto the destination after customers have continued using the source can lose business records, even if the new website looks correct.
IN THIS ARTICLE
01 Define which system owns live writes
List every writer: customers, administrators, payment callbacks, renewal jobs, integrations and external imports. Choose a final migration window and agree when the source stops accepting each kind of new activity. Maintenance mode that hides pages may not block API requests, webhooks or cron jobs, so test the actual controls.
02 Prepare and rehearse
- Create an initial copy and test the destination with payments, mail and scheduled business actions isolated.
- Record the final-sync method and exactly which files and database tables it transfers.
- Compare order counts, recent user registrations and important integration settings on the rehearsal copy.
- Prepare DNS and HTTPS, plus a communication plan for any unavoidable interruption.
- Take a fresh coordinated backup immediately before the final cutover.
03 Complete the final cutover
Pause the agreed writers, capture the final source state and transfer it. Verify the latest known transaction and account records before directing public traffic to the destination. Enable production integrations only on the intended live system. Keep the source from accepting new writes while DNS caches may still send some visitors there. Monitor incoming callbacks and failed jobs after the move.
Can staging changes be merged with new orders automatically?
Do not assume so. A database deployment or restore commonly replaces data rather than reconciling independent histories. NabWP staging database synchronisation also requires this replacement risk to be considered. Prefer deploying tested code and design changes without replacing live transaction tables when the workflow supports that separation.
What if we need to roll back?
Once the destination has accepted new business activity, restoring the old source is another data migration. Preserve the destination's new records and payment references before deciding how to reconcile them. Do not repeat payments or refunds just because the website status is uncertain. Escalate with the cutover time, last verified source record, first destination record and relevant error logs so the recovery plan protects the actual business history.