Migrate a website with staged file sync, database cutover and separate email checks

Moving website files is only one part of a hosting migration. Databases, scheduled jobs, TLS certificates, PHP extensions, DNS and mail routing all have their own state. A dependable migration rehearses the new environment first, chooses a clear point for the final data transfer and keeps email routing separate from the web cutover.

Inventory services before copying anything

• Document every hostname, document root, redirect, runtime version, extension and application secret source.
• List databases, database users, scheduled tasks, queues, payment integrations and outbound mail services.
• Record authoritative DNS, A and AAAA answers, MX records and sender authentication records.
• Confirm disk space, inode limits, account ownership and backup recovery options at the destination.

A compatible PHP version number alone is insufficient: extensions, limits, database behavior and filesystem permissions also matter. Record who controls the domain, DNS, old hosting and mail accounts so the migration does not stall when a separate administrator must approve a change.

Back up the source before starting, and verify that the backup can be restored. A copy on the same server is useful for a short rollback but does not protect against loss of that server or account.

Perform an initial copy into the correct destination

rsync -avhn --itemize-changes \
  --exclude='.git/' --exclude='.env' \
  -e ssh ./site/ deploy@192.0.2.40:/srv/www/example/current/

# After reviewing paths and the preview, remove only the dry-run flag:
rsync -avh --itemize-changes \
  --exclude='.git/' --exclude='.env' \
  -e ssh ./site/ deploy@192.0.2.40:/srv/www/example/current/

The trailing slash copies the directory contents into the destination directory. These examples deliberately do not delete destination files. Review ownership and the deployment account permissions on the target; archive mode cannot give an unprivileged account arbitrary ownership privileges.

Provision application configuration through a separate protected channel. Excluding .env helps prevent an accidental overwrite, but it does not make every remaining file safe to publish. Review configuration files, backups, version-control folders and application-specific secrets before exposing the document root.

Restore a rehearsal database and test the application

Create a dedicated database and a least-privilege application account at the destination. Import a verified backup there, after checking that the dump does not select an unintended database. Keep a staging copy isolated from real payments, customer mail and production queues.

curl --resolve example.com:443:192.0.2.40 \
  --silent --show-error --fail --output /dev/null \
  --write-out 'HTTP %{http_code}; remote %{remote_ip}\n' \
  https://example.com/

For interactive testing, use a carefully recorded hosts-file override on your own workstation or an appropriate staging hostname. Test forms, authenticated pages, uploads and background jobs. Remove local overrides afterward so your final verification tests the public DNS path.

Plan the final write pause and transfer

A rehearsal database becomes stale while production receives new writes. Choose a maintenance window or an application-supported online migration strategy. During a maintenance window, stop or pause all writers that matter, including scheduled tasks, workers, APIs and administrative edits; a front-page maintenance message alone may not stop them.

pwd
wp core version
wp maintenance-mode activate
umask 077
wp db export "$HOME/final-migration.sql"

Check the export result, protect the SQL file and transfer it outside the destination web root. Perform the reviewed final file sync, import the final database into the verified target and complete the acceptance checks before allowing destination writes. Decide how you will handle writes if a rollback is needed; importing an old database over new orders is a data-loss event.

Preserve mail delivery independently

If email stays with the existing mail provider, preserve its MX records and required TXT records. If the web server previously delivered local messages directly to local mailboxes, check the hosting account mail-routing setting so website forms reach the actual external mail service.

If mailboxes are moving too, treat that as a separate project: create destination mailboxes, plan secure IMAP migration, account for messages arriving at the old server during cache overlap and verify folders, quotas and client settings. Never assume a website backup includes all mailbox data or a DNS change moves existing messages.

dig example.com MX +noall +answer
dig example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Observe the cutover and retain a recovery window

Change the reviewed web records, including IPv6 where applicable, and watch traffic on both servers. Enable scheduled jobs at the intended active host only; duplicated billing or queue workers can be more damaging than a temporary page error. Confirm HTTPS, application mail and representative customer actions through public DNS.

Keep the old environment protected and available for the agreed observation period. Record final DNS values, restore instructions, runtime settings and remaining tasks. Once stable, retire old access and data according to your retention policy rather than leaving an unpatched duplicate online indefinitely.

Primary documentation

• rsync manual
• cPanel Zone Editor
• WP-CLI database export
• WP-CLI maintenance mode
• cPanel Email Accounts
• WordPress migration guidance