How to Migrate a Website to a New Host — 9-Step Guide
How to migrate a website to a new host with zero downtime. A complete 9-step guide covering preparation, backup, DNS cutover, testing and common migration problems.
Moving a website to a new host takes 30 to 90 minutes for most sites. The key to zero downtime is lowering your DNS TTL beforehand and keeping both hosts running during the cutover. If you can use a migration plugin or cPanel transfer tool, much of the work is automated.
Preparation before you touch anything
The most important rule when you migrate a website to a new host is this: never start a migration without a working backup and a way to revert. Preparation makes the difference between a 45-minute cutover and a weekend of downtime.
Start by lowering your DNS TTL to 300 seconds (5 minutes) at least 48 hours before you plan to switch. This reduces the maximum time visitors will wait during propagation. Next, document your current environment: PHP version, database credentials, email configuration, and any custom php.ini or .htaccess rules you have. Take screenshots of your control panel settings if possible.
Finally, confirm that the new host supports everything your site needs. If you are running a specific PHP framework or a WordPress plugin with unusual requirements, check compatibility before you move any data.
Full backup — files, database and email
A backup for migration needs three components: your website files, your database, and your email data. Missing any of these means a restart later.
| Component | Method | Location |
|---|---|---|
| Website files | cPanel File Manager or FTP download | public_html folder |
| Database | phpMyAdmin export or mysqldump | SQL dump file |
| IMAP sync or export to PST/MBOX | Local machine or new host |
Use your current host’s backup tool first, then download a second copy to your local machine. Two backups are one more than you will ever regret having. Store the database dump separately from the file archive so you can restore them independently.
Setting up on the new host
Before you point DNS anywhere, get the new host ready. Upload your website files to the new server using FTP or the host’s file manager. Create a new database and import your SQL dump. Update your configuration files (wp-config.php for WordPress, .env for Laravel, etc.) to point at the new database credentials.
Most reputable hosts offer a staging environment where you can verify everything works before the DNS change. If your new host provides this, use it. Test your site using a hosts file entry on your local machine so you can see the site on the new server without changing DNS for anyone else. Add a line like 203.0.113.1 www.yoursite.com to your hosts file, visit the site, and confirm everything loads correctly.
If you are migrating an e-commerce site, pay extra attention to SSL certificates. Install the new certificate on the new host before the cutover so HTTPS works from the moment DNS propagates.
The 9-step DNS cutover sequence
This is the critical moment when you actually migrate the website. Follow these steps in order for a clean cutover:
- Confirm the old host is still live — both hosts must serve the site during cutover.
- Take a final backup of any changes made since the first backup (new orders, comments, etc.).
- Transfer the final changes to the new host and verify they are in place.
- Update the DNS nameservers or A records at your domain registrar to point to the new host’s IP.
- Lower the TTL if you have not already done so (should already be at 300 seconds from step one of preparation).
- Log the exact time of the DNS change so you can track propagation.
- Monitor propagation using tools like whatsmydns.net or dig commands.
- Keep the old host running for at least 48 hours to catch any traffic that has not propagated yet.
- Update any third-party services that point to your old IP, such as payment gateways or API integrations.
Once DNS has propagated for your region, you can begin the testing phase while the rest of the world catches up.
Testing before going live
Testing is where most people rush, and it is where things go wrong. Check every page, every form, every link, and every payment flow. Verify that images load, that CSS and JavaScript are correctly referenced, and that the SSL certificate is valid and active.
Use Google Search Console to request re-indexing of your site once the new host is live. Check that your email still sends and receives. Run a crawler like Screaming Frog to identify broken links or missing pages. If you have changed your IP address, update your Google Analytics and any other tracking tools that log the server address.
Do not cancel the old hosting account until at least one full billing cycle has passed. This gives you a rollback option if an issue surfaces after you thought the migration was complete.
Common migration problems and fixes
Even with careful preparation, issues can arise when you migrate a website to a new host. Here are the most common problems and how to fix them:
- Mixed content warnings. The site loads over HTTPS but some assets use HTTP URLs. Fix with a search-and-replace on the database to update absolute URLs.
- Database connection errors. Usually means the credentials in your config file do not match the new host’s database. Double-check the hostname, username, password and database name.
- Email not sending. MX records need to propagate just like A records. Confirm the new host’s mail server settings and verify that your DNS includes the correct MX entries.
- File permission errors. Different hosts use different default permissions. Set folders to 755 and files to 644, or match the old host’s permissions exactly.
- SSL certificate mismatch. The certificate was issued for the old IP or server. Re-issue the certificate on the new host before the cutover.
Frequently asked questions
A standard website migration takes 30 to 90 minutes for the technical work. DNS propagation adds another 1 to 48 hours depending on the TTL you set, though most visitors see the new host within two hours of the cutover.
Yes, if your site uses a control panel like cPanel. Most hosts offer migration tools or a free migration service. For custom-built sites, a developer is recommended to handle database configurations and file path changes.
Not if you follow the correct sequence: take a full backup, transfer everything, then test before pointing DNS. The risk comes from skipping the backup or pointing DNS before the new host is fully configured.
It should not if you preserve the URL structure and redirects. The biggest SEO risk during migration is extended downtime. Keeping both hosts live during cutover eliminates that risk entirely.
Email migration and database-dependent sites cause the most trouble. Email requires reconfiguring MX records and may have a brief outage during propagation. Database-based sites need careful handling of connection strings and file permissions.