Recommended Free Tools
You can move a WordPress site to a different host while keeping its domain at GoDaddy, or transfer the domain registration separately. The safe sequence is to make and verify a local copy of the site files and database, build the destination installation, test it privately, then change DNS. Do not cancel the GoDaddy hosting account until the new site, email, HTTPS, forms and DNS are working.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What actually moves when you leave GoDaddy?
A WordPress site has two essential components: its files and its database. The files contain WordPress core, themes, plugins, uploads, configuration and custom code. The database contains posts, pages, users, settings, comments, menus and much of the content generated by plugins. A copy of only wp-content is not a complete migration.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Hosting, DNS and domain registration are separate services. You can change one without changing the others.
| Service | What it controls | Can it remain at GoDaddy? |
|---|---|---|
| Web hosting | The server that runs WordPress and stores its files and database | Yes. You can move the site to another host while keeping the registration there. |
| DNS hosting | Records such as A, AAAA, CNAME, MX and TXT that direct visitors and mail | Yes. You may leave DNS at GoDaddy or delegate it by changing nameservers. |
| Domain registration | Your registration, renewal, transfer lock and registrar account | Yes. A registrar transfer is optional and separate from the site move. |
Moving hosting changes where the website runs. Changing nameservers changes which provider publishes DNS. Transferring the domain changes the registrar responsible for the registration. Treat these as separate projects so a website move does not accidentally interrupt mail or domain ownership.
Plan the move before touching DNS
Inventory the existing site
Write down every component that must continue working:
- All domains, subdomains and parked domains.
- WordPress, PHP and database versions.
- The active theme, child theme, plugins and any custom code.
- Permalink structure, scheduled tasks (cron jobs), redirects and caching rules.
- Forms, transactional mail, analytics, advertising tags, CDN settings and external API integrations.
- SSL certificate arrangements and every DNS record, especially MX, SPF, DKIM, DMARC, verification and service records.
- The current database name, table prefix and non-default settings in
wp-config.php.
Record this information while the old site is working. It gives you a reference when a destination host uses different PHP modules, database limits or document-root paths.
Choose a low-risk change window
Make the final file and database copy during a quiet period. If the site receives orders, comments or user registrations, put it in maintenance mode briefly or schedule the final export immediately before the DNS change so new writes are not stranded on the old server.
Lower DNS TTL when practical
Reducing the time-to-live on records before the cutover can make a later change take effect sooner, but it cannot control resolvers that cache beyond the advertised value. Keep the old server available throughout propagation.
Create and verify a complete backup
Download the WordPress files
Use FTP, SFTP or the host’s file manager to download the entire WordPress document root. Include WordPress core files, wp-content (themes, plugins and uploads), wp-config.php, hidden files such as .htaccess where applicable, and custom files outside the normal WordPress directories. Download the archive to your computer rather than leaving the only copy in cloud storage.
Export the database from phpMyAdmin
- Open the database assigned to the site in phpMyAdmin.
- Choose Export, select the complete database and use SQL format.
- Save the resulting
.sqlfile beside the files archive.
If the database is large, use the host’s documented command-line or backup export method instead, but preserve a standard SQL dump when possible. Do not edit serialized WordPress data in a text editor.
Check that the backup is usable
Confirm that the file archive opens and includes the expected uploads, theme and plugin directories. Check that the SQL file has a non-zero size and contains table definitions and data. Keep a second copy on separate physical storage, such as an external drive. A backup is only useful if it can be read and restored.
Pick an automatic or manual migration
| Approach | What you do | Advantages | Limitations |
|---|---|---|---|
| Automatic migration | Use a migration tool supplied by the destination Managed WordPress product, following that product’s current wizard. | Less FTP and database work; some services perform the copy and configuration for you. | Availability depends on the destination product and account interface. You still need an independent backup and post-move testing. |
| Manual migration | Download files, export SQL, create the destination database, upload files, import SQL and edit wp-config.php. |
Works with almost any host and gives you control over URLs, versions and rollback. | Requires FTP or SFTP, phpMyAdmin or equivalent database access, and careful configuration. |
An automatic wizard does not eliminate DNS, email, URL, SSL or rollback work. If the destination does not explicitly support an import, use the manual procedure below.
Build the destination WordPress installation
- Create the hosting account, site or virtual host at the destination. Select a PHP version compatible with the existing site and confirm that HTTPS can be issued for the domain.
- Create an empty MySQL or MariaDB database and a database user. Grant that user full privileges on the new database and record the database name, username, password and database host exactly as supplied by the destination.
- Identify the destination document-root path and confirm whether the host expects a particular table prefix, character set or database port.
- If the host offers a temporary URL or staging address, use it for testing. Do not point public DNS at an untested installation.
Do not install a second, unrelated WordPress copy over the directory where you will restore the existing files. The restored files and SQL dump should be the authoritative installation.
Manual migration: transfer the site step by step
- Put the destination in a clean state. Create the database and user, then note the exact credentials. If the host preinstalls WordPress, remove or set aside its default files and database tables unless the host’s migration instructions say otherwise.
- Upload the files. Transfer the complete archive contents to the destination document root with FTP or SFTP. Preserve directory names, file permissions and hidden files. Large media libraries may take longer than the PHP files, so verify that the upload completed rather than assuming the client succeeded.
- Import the SQL dump. Open the new database in phpMyAdmin, choose Import, select the SQL file and run the import. For a dump that exceeds the web interface’s upload limit, use the destination’s documented import utility or ask support to load it without altering the file.
- Configure
wp-config.php. Edit the copied file so the database constants match the destination account. The relevant entries are the database name, user, password and host, for example:define('DB_NAME', 'destination_database');define('DB_USER', 'destination_user');define('DB_PASSWORD', 'destination_password');define('DB_HOST', 'destination_database_host');Keep the existing table prefix and other custom constants unless the destination requires a documented change. Never publish the password in a support ticket or commit it to a public repository. - Check file ownership and permissions. WordPress must be able to read its files and write to required directories such as uploads. Use the destination’s recommended ownership and permission settings; do not make the entire site world-writable to bypass an error.
- Sign in privately. Use the temporary URL, a hosts-file override or the destination’s staging function. If WordPress redirects immediately to the public domain, use the URL procedure in the next section before continuing.
- Regenerate rewrite rules. In the WordPress dashboard, open Settings > Permalinks and click Save Changes without changing the selected structure. This rewrites the server rules for the new environment.
A database connection error usually means one of the four values in wp-config.php is wrong, the user lacks privileges, or the destination uses a non-default database host or port. Correct those values before changing application files.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Keep URLs unchanged or update them safely
When the domain and protocol stay the same
If visitors will use the same domain and the same HTTP-to-HTTPS arrangement, the database usually needs no global URL edit. Concentrate on server paths, HTTPS certificates, rewrite rules and DNS. Existing absolute links and media URLs should continue to resolve once the domain points to the new server.
When the domain, subdomain or protocol changes
WordPress stores the home address and site address in the database. Update the home and siteurl values for the new address before testing. A temporary URL can also appear in media, menus, widgets, serialized options, plugin settings, canonical tags and theme templates.
Rank #3
Use a serialization-aware search-and-replace method supplied by the host or a reputable WordPress tool. A plain SQL text replacement can corrupt serialized strings because their stored lengths change. Search for the old scheme and hostname, replace them with the exact new scheme and hostname, then inspect representative posts, images, menus and plugin settings.
Plan redirects from every important old path to its corresponding new path. Recheck canonical URLs, sitemap output, robots directives, cookies and mixed-content warnings. After the replacement, save the permalink settings and test both clean URLs and URLs with query strings.
Free tools Windows power users keep installed
One-click scans. No signup required.
Test the destination before the DNS cutover
Use a private staging address or hosts-file override so you can test the new server while public visitors still reach GoDaddy. Work through this checklist:
- Log in and log out as an administrator and, if relevant, as a normal user.
- Open the homepage, several posts, pages, categories, search results and a representative archive.
- Load images, downloadable files, galleries and embedded media from the existing library.
- Submit every important form and confirm that the receiving mailbox gets the message.
- Exercise ecommerce, membership, booking or other transaction flows in their safe test mode.
- Check each active plugin and theme, including scheduled jobs, caching, security and analytics integrations.
- Test pretty permalinks, redirects, 404 handling and any custom rewrite rules.
- Verify the certificate, HTTPS redirect, secure cookies and the absence of mixed-content warnings.
- Confirm that the destination creates backups and that you can restore the transferred files and database.
- Review DNS records used by email and third-party verification before changing nameservers or A records.
Fix failures on the destination while the old site remains available. Do not treat a successful homepage load as proof that the migration is complete.
Cut over hosting without breaking email
Changing only the website records
If DNS remains with GoDaddy, change the website’s A or AAAA record to the destination address, and update any relevant CNAME. Leave MX, SPF, DKIM, DMARC, verification and mail-host records untouched unless your mail provider specifically instructs otherwise.
Delegating DNS to another provider
Before changing nameservers, export or record the complete DNS zone. Recreate every A, AAAA, CNAME, MX, TXT and verification record at the new DNS provider, then compare the two zones. Nameserver changes can affect mail, APIs, subdomains and certificate validation even when the WordPress files are perfect.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteMonitor propagation
After changing the required records, test from more than one network and resolver. Watch access logs, uptime, form delivery and mail flow on both servers. Some visitors will continue reaching the old host until their cached DNS expires, so keep the old site synchronized or in a safe read-only state during that period.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Transfer the domain registration only if you want to
A registrar transfer is not required to move hosting. If you decide to leave GoDaddy as registrar, complete the hosting cutover first or coordinate both projects so you do not troubleshoot two independent changes at once.
- Confirm that the domain is eligible to transfer and that the registrant email address is accessible.
- Disable the transfer lock and review Domain Privacy and Domain Protection settings according to the registrar’s current transfer instructions.
- Request the domain’s Auth-Code (also called an EPP code). GoDaddy sends it to the registrant email address. Under ICANN’s policy for gTLDs, when a registrant cannot generate the code directly, the registrar must provide it within five calendar days of the request.
- Start the transfer at the gaining registrar and enter the exact domain and Auth-Code.
- Approve any confirmation messages and monitor the transfer. GoDaddy states that transfers typically take five to seven days.
- After completion, verify nameservers, DNS records, contact details, renewal settings and the new registrar’s transfer-lock control. Re-lock the domain when the new registrar supports that feature.
A 60-day restriction may apply after a new registration, a previous transfer or certain registrant-contact changes. An ineligible domain cannot be transferred simply by requesting another Auth-Code.
A registry lock blocks an outbound transfer but does not stop DNS resolution, email delivery, SSL certificates or hosted services. Removing or reapplying that protection is therefore a registrar-security decision, not a website-availability switch.
Fix common migration failures
| Symptom | Likely cause | Action |
|---|---|---|
| “Error establishing a database connection” | Wrong database name, user, password or host; missing privileges; wrong port | Compare wp-config.php with the destination’s database panel and grant the user access to the imported database. |
| Homepage works but inner pages return 404 | Rewrite rules were not regenerated or the server does not support the expected module | Save Settings > Permalinks, inspect .htaccess or the server rewrite configuration, and confirm the document root. |
| Images or CSS still load from the old domain | Absolute URLs remain in content, settings or serialized data | Run a serialization-safe replacement, then inspect media, theme options and plugin settings for the old hostname. |
| Redirect loop or mixed-content warning | HTTP/HTTPS values disagree between WordPress, the proxy and the certificate | Choose one canonical HTTPS URL, correct home and siteurl, configure the proxy’s forwarded protocol correctly and clear caches. |
| Forms arrive sometimes or not at all | MX/TXT records were omitted, or the destination’s mail-sending method is not configured | Compare the DNS zone record by record and test delivery from the new server without changing unrelated mail records. |
| Plugin or theme produces a fatal error | PHP version, extension, file permissions or plugin state differs | Use the destination’s error log, temporarily disable the failing extension, match a compatible PHP version and update or reconfigure the component. |
| Some visitors see the old site | DNS caches have not expired or different records point to different servers | Check authoritative records, wait through the advertised TTL and keep the old host online while propagation completes. |
Keep a rollback path and retire GoDaddy carefully
Do not delete the old files, database or hosting account immediately after the DNS change. Retain the verified archives and keep the old environment available until traffic consistently reaches the destination, forms and email work, HTTPS is valid, backups run and no important integration is failing. If a serious defect appears, restore the old DNS record temporarily, correct the destination, and repeat the controlled cutover.
Once the new site has been stable through a normal traffic cycle, take one final backup, document the new host and DNS arrangement, remove unused credentials and cron jobs, and cancel the old hosting only after checking that no mailbox, subdomain or unrelated service still depends on it.
Quick Recap
Final migration checklist
- Inventory, versions, integrations and DNS records documented.
- Files archive and SQL export downloaded and tested, with a second copy retained.
- Destination database, credentials, PHP version and document root prepared.
- Files uploaded, SQL imported and
wp-config.phpmatched to the new database. - URL replacement completed safely when the address changed.
- Login, content, media, forms, plugins, permalinks, HTTPS, redirects and backups tested privately.
- DNS records compared, website records switched and email records preserved.
- Old hosting retained through propagation and verification.
- Registrar transfer handled separately with an eligible, unlocked domain and Auth-Code.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
