Moving a WordPress site is not difficult, but it is unforgiving. The files, the database, the domain, and the DNS all have to agree on the same address at the same moment. Most failed migrations are not caused by a missing feature; they are caused by skipping a backup, replacing URLs carelessly, or switching DNS before the new copy was tested.
What a migration actually moves
Before touching anything, write an inventory. It should list every domain and subdomain, where DNS is managed, the WordPress version, the PHP and MySQL versions, the active theme and plugins with their versions, user accounts, cron jobs, redirects, forms, analytics tags, and any external services connected through API keys. Note the static files that live outside WordPress too, such as uploaded PDFs or a small script in a folder.
The inventory does two things: it tells you what must be recreated, and it gives you a checklist for the day of the move.
Back up before you touch anything
Take a full backup, not just an export of posts. That means every file in the web root, including wp-content, plus a complete database dump. Download both to your computer and to a second location. Confirm the archive opens and the SQL file is not empty; a backup you have not looked at is a hope, not a backup.
If the current host offers an export tool, use it, but also copy the raw files through the file manager so you are not dependent on one mechanism. Keep the backup until the new site has been live for at least two weeks.
Move the files and the database
Compress the web root into a single archive, upload it through the file manager on the new host, and extract it in the correct directory. The general file workflow is described in uploading site files. Create a new database and user on the new host, import the SQL dump, then edit wp-config.php so the database name, user, password, and host match the new environment.
If the archive is large, move it in parts rather than retrying a single upload. After extraction, check that hidden files such as .htaccess came across, since file managers often hide dotfiles by default.
Replace old URLs properly
WordPress stores the site address in the database and in serialized settings inside widgets, menus, and plugin options. A blind text replacement can corrupt serialized data, leaving widgets empty or the theme broken. Use a migration plugin that handles serialization, or a command-line search-replace tool if you have shell access on either host. Never edit the GUID column; it is not a public URL and changing it breaks feeds.
Replace the temporary address with the final one, then open the site and check menus, widgets, forms, and image paths. If a page still points at the old domain, the replacement missed a table.
Plan the DNS cutover
Lower the TTL on your DNS records a day or two before the move so changes propagate quickly. Decide whether you will change nameservers or only the address record. Changing nameservers moves all DNS management at once; changing a single A record keeps mail and other records where they are. The nameserver side of the process is covered in connecting a domain and nameservers.
| Stage | What to confirm before moving on |
|---|---|
| Backup | Files and database downloaded, archive opens, SQL imports cleanly |
| Files | Web root complete, dotfiles present, permissions sane |
| Database | Credentials updated, tables imported, admin login works |
| URLs | Site and home URLs replaced, no mixed content, permalinks resaved |
| DNS | TTL lowered in advance, records copied, old site still reachable |
| Launch | Forms, SSL, redirects, and mail tested on the live domain |
Keep the old hosting active during propagation. Do not run two copies that both accept form submissions or writes, or you will lose data from one of them.
Do not forget mail records
If you move nameservers, every DNS record moves with them, including the ones that deliver your email. Copy MX, SPF, DKIM, and DMARC records exactly before the switch, and compare them afterwards. A missing MX record does not break your website, so it can go unnoticed for days while messages bounce. BadilHost does not provide email hosting, so your mail stays with your current provider and depends on these records being recreated correctly.
Test, then keep a rollback window
After the domain resolves to the new server, work through a short test list:
- Homepage and a deep page load without errors.
- The login screen accepts your credentials.
- A form submission arrives at its destination.
- Search, feeds, and the SSL padlock behave normally.
- Old URLs redirect and the server logs show no new 404s.
Check both the www and non-www versions as well.
Keep the old account and its backup for two weeks. If something is badly broken, point DNS back to the old server and restore service while you investigate. When you are confident, cancel the old plan and remove temporary files from the new one. To start the move, create a free account and review the limits on the hosting page before uploading.
Related reading: Uploading site files safely · The free plan and its limits
Create your free account — 5 GB disk, free SSL, no card required.