A WordPress site is two things
The files hold WordPress itself, your theme, plugins, uploaded images and the configuration file. The database holds your pages, posts, users, comments and most settings. WordPress's own documentation says both are needed for a full restore, and that downloading the site folder does not capture the database. A move that copies only the files gives you a working shell with none of your content.
The documented order is to back up the database first and then the files, and to restore the files first and then import the database. If the database name or user changes at the new host, the configuration file must be updated to match.
Same address or new address
If the site keeps the same domain and URLs, WordPress says copying the files and the database is generally enough. If the address changes, because of a new domain or a change between http and https, the old address is stored throughout the database: in post content, widgets, menus and plugin and theme settings. WordPress notes those references remain after a move and can break links or theme display.
- Same address: copy files and database, update the database details, test.
- New address: also rewrite stored addresses, with care, and redirect the old ones.
Why a blind find-and-replace corrupts settings
Many themes and widgets store settings as serialised data, which records the length of each text value. Replace an address with a longer or shorter one by hand and the stored length no longer matches, and the setting is ignored or lost. WordPress warns against a blanket database replace for this reason. WP-CLI's search-replace command is documented to handle serialised data intelligently, to offer a --dry-run that reports without writing, and to skip named columns. The post GUID column should not be changed, because feed readers use it to recognise items they have already seen.
- Run the dry run first and read the report.
- Skip the guid column.
- Delete transients afterwards if they still hold the old address; WordPress documents that they are recreated.
Test before you point DNS at it
WordPress's page describes one way to test before switching: temporarily changing the site and home values in the options table. A different method, which is our own approach and not from that page, is to give the tester a local hosts-file entry that makes the real domain name resolve to the new host on their machine only, so the site can be checked under its real address while the public still sees the old one. Whichever you use, test the agreed pages, a form that sends a message, a log-in and the permalinks, which WordPress advises reconfiguring when the site goes live.
Freeze, switch and keep the old host
Content that arrives between the final copy and the switch can be lost: comments, form entries, edits. Agree a content freeze, run a last sync, then switch DNS and check both hosts for new entries. Keep the old host running, unchanged, for at least two weeks so you can switch back, and keep the backup until you have signed off.
Where the paid outcome fits
The fixed-price job for this is a published test price of £395, not yet tested with buyers, payable after sign-off. It covers one single-site WordPress installation up to 10 GB of files and 2 GB of database, a preview with ten pages, one form and one log-in tested, a switch and switch-back plan and live checks. It excludes shops with live orders, Multisite networks, redesign and cleaning a hacked site. If the move is part of a larger change of host, mailboxes and DNS, the project record covers the ordering.
Sources and limits
- WordPress: Moving WordPress Checked 2026-10-11.
- If the database and URLs stay the same, copying the files and database is generally enough, with wp-config.php updated if the database name or user changes.
- A blanket database search-and-replace can break serialised data; the guid column of posts should not be altered; transients can hold the old address.
- WP-CLI: wp search-replace Checked 2026-10-11.
- The command handles PHP serialised data, supports --dry-run and --skip-columns, and --precise forces a more careful but slower method.
- WordPress: Backups Checked 2026-10-11.
- A site has two parts, the database and the files, and both are needed for a full restore; back up the database first, then files, and restore files first, then import the database.