Fear of downtime is the number one reason people stay with a bad host longer than they should. The process isn't as risky as it looks. With the right sequence, copy first, test fully, cut DNS over last, you can move a live site to a new server with zero visible downtime to visitors. This guide covers the complete process from pre-migration preparation through post-migration cleanup.
Good migrations start with preparation, not action. At least 24 hours before you plan to migrate, log into your DNS provider and lower the TTL (Time to Live) on your A record and MX records to 300 seconds (5 minutes). TTL controls how long DNS resolvers around the world cache your records before checking for updates. Most records default to 3600 seconds or higher, meaning a DNS change could take up to an hour to propagate widely even after you make it.
Lowering TTL now means that when you do make the DNS change, propagation happens in minutes rather than hours. Note that the TTL change itself takes time to propagate based on the current TTL value, which is why you need to do this a day ahead. Also confirm your new hosting account is fully set up and responding before touching anything on the current host.
Before moving a single file, create a complete backup of the current site. For WordPress, use Duplicator or UpdraftPlus to generate a full package. Duplicator bundles files and database into a single installer archive; UpdraftPlus creates separate archives for files and database. Download both to your local machine, do not rely solely on the old host's server copy, since you'll be cancelling that account later.
For non-WordPress sites, download all files via FTP (FileZilla is the standard free client) and export the database from phpMyAdmin using Export → Quick → SQL format. Record your current database credentials from your config file, you'll need the database name, username, and password for the restore step.
Sign up for your new hosting account and get access to cPanel or your chosen control panel. Install WordPress via Softaculous or the host's one-click installer, you'll be overwriting this with your migration, so the version doesn't matter. Create a new MySQL database and user with ALL PRIVILEGES assigned, noting the credentials.
If using Duplicator: Upload the installer.php and archive.zip to your new host's public_html directory. Access the installer via the host's temporary URL (found in your new cPanel under "Server Information" or similar). The Duplicator installer creates the database tables and restores all files automatically. Update the database credentials when prompted.
If using UpdraftPlus or manual backup: Install UpdraftPlus on a fresh WordPress instance on the new host, upload your backup files, and run the restore. For a manual restore, import the SQL file via phpMyAdmin on the new host, upload files to public_html via FTP, and edit wp-config.php to reflect the new database credentials. Also verify the siteurl and home values in the wp_options table point to your domain, not a server-specific URL.
This is the step most people skip and shouldn't. Edit your local hosts file to point your domain at the new server's IP address. On Windows, that's at C:\Windows\System32\drivers\etc\hosts. On Mac and Linux, it's /etc/hosts. Open the file with administrator privileges and add a line like:
123.456.789.0 yourdomain.com www.yourdomain.comYour browser now loads the new server while the rest of the world still sees the old one. Test thoroughly: click through every page, submit forms, check image loading, test any checkout or booking flows, verify SSL is active (Let's Encrypt is available from cPanel → SSL/TLS → Let's Encrypt), and check admin login. Fix any issues you find at this stage, not after DNS is live.
When the site is verified and working on the new host, log into your domain registrar and update the A record to point to the new server's IP address. If you want the new host to manage all DNS records (recommended for simplicity), update the nameservers instead, this replaces the entire DNS zone with the new host's records. If you're keeping email hosted elsewhere (e.g. at Google Workspace or Microsoft 365), update only the A record and www CNAME, leaving MX records untouched.
Because you lowered TTL to 300 seconds 24 hours ago, most visitors will be hitting the new server within 5–15 minutes of the change. Some ISPs cache DNS longer regardless of TTL, this is why you keep both hosts running simultaneously for at least 48 hours after the cutover.
Use our DNS Propagation Checker to confirm your new IP is resolving from different locations around the world. Most locations should update within minutes with a low TTL; stragglers typically resolve within a few hours.
Remove the hosts file entry you added in Step 3 once you've confirmed DNS has propagated to your location, otherwise your browser will continue loading from the new server IP even if you want to check what the old server shows. Use a different device or a browser in incognito mode to see what the general public currently sees.
Once propagation is confirmed globally, run a final round of checks on the live site: WordPress admin works, plugins are functioning, WooCommerce checkout completes if applicable, contact forms send to the right address, and images and media load correctly. Check Google Search Console for any crawl errors that might have appeared during the transition.
After 48–72 hours of stable operation on the new host, raise your TTL back to a normal value, 3600 seconds is standard, though 86400 (24 hours) is fine for stable setups. Then cancel your old hosting account. Do not cancel before the 48-hour mark; DNS propagation edge cases and the need to retrieve any overlooked files mean you want the old environment accessible during that window.
Database connection error: The most common post-restore issue. Open wp-config.php on the new host and verify DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST (usually "localhost") exactly match the database credentials you created in cPanel. A single mismatched character breaks the connection.
Mixed content warnings after enabling SSL: If the old host used HTTP and the new host uses HTTPS, internal links and image URLs in the database may still reference http://. Use the Better Search Replace plugin to update http://yourdomain.com to https://yourdomain.com across all database tables after migration.
File permission errors: WordPress needs correct file permissions to function. Directories should be set to 755 and files to 644. In cPanel File Manager, select public_html and use "Change Permissions" recursively if you see permission-related errors after restoring.
Already hosted somewhere else? Our team handles the full migration, files, database, DNS guidance, and testing, at no extra cost. Your site stays live throughout. No technical skills needed on your end.
View Hosting Plans