Migrating a website from one host to another is one of those tasks that looks simple on paper and goes sideways quickly in practice. Miss one step and you’re looking at hours of downtime, broken email delivery, or an SEO hit that takes weeks to recover from. Do it right and nobody notices a thing — which is exactly the outcome you want.

The good news: there’s a repeatable workflow for this. Most hosting migrations fail for the same small handful of reasons — forgotten DNS records, untested backups, missed redirects, DNS TTL not lowered in advance. Knowing what those are and hitting them in order turns migration from a risky adventure into a predictable afternoon.

This guide walks through the complete process in the exact order you need to do it. Whether you’re moving a simple WordPress blog or a larger production site, the same fundamentals apply. We’ll cover when migration actually makes sense, how to schedule it, the 8 numbered steps to follow, what to verify afterward, and how to avoid the most common mistakes.

1. When to Migrate (and When Not To)

Before the checklist, a quick reality check: migration is work, and it carries real risk. Make sure the reason justifies the effort. Some triggers are clearly worth it. Others look like they are but aren’t.

Good Reasons to Migrate

• Chronic performance problems — pages consistently loading slowly even after optimization, server response times over 1 second, Core Web Vitals failing
• Frequent downtime — missing your uptime SLA regularly, especially during traffic spikes
• Outgrowing your current tier — constantly hitting resource limits, needing more RAM/CPU than your plan provides
• Missing critical features — your stack needs PHP 8.2, Redis, or Node runtimes your host doesn’t offer
• Poor or unresponsive support — the kind of support quality that costs you money during incidents
• Security incidents or compliance gaps — your host can’t meet the security posture your business requires
• Pricing changes — renewal prices significantly higher than comparable hosts, with no corresponding upgrade in service
• Acquisition concerns — your host was acquired and service quality visibly dropped

Bad Reasons to Migrate

• A single bad support experience that was probably an outlier
• A cheaper promotional rate elsewhere (that will jump at renewal)
• One bad uptime day in a year of otherwise-solid service
• A trendy host your competitor uses
• Frustration with a problem that’s actually your theme/plugins/code, not your host

2. Migration Timeline & Scheduling

Migration work fits a predictable schedule if you plan ahead. Rushing any step — especially the pre-migration prep — is where most problems originate. Here’s the realistic timeline for most sites.

Choosing the Right Time

The migration itself should happen during your lowest-traffic window — typically late evening or overnight on a weekday. Avoid:

• Fridays — if something breaks, you’re working through the weekend
• Before major sales or launches — give yourself at least 2 weeks of buffer between migration and any important event
• Peak traffic hours for your audience — Tuesday 2pm ET might be your worst possible moment
• Holidays — support teams on both sides (old and new host) are short-staffed

For most US-audience sites, late Tuesday or Wednesday evening is ideal — support teams are fresh, traffic is low, and you have three business days to catch issues before the weekend.

3. Pre-Migration: What You Need First

Before touching anything, gather the access and information you’ll need. Hunting for passwords mid-migration is how sites end up down for hours.

Credentials Checklist

• Current hosting control panel (cPanel/Plesk/dashboard) login
• Current database credentials (hostname, username, password, DB name)
• FTP/SFTP credentials for current host
• Domain registrar login (where you manage DNS)
• Email account access (admin notification emails)
• New host login and API access if needed
• CMS admin credentials (WordPress admin, etc.)
• CDN dashboard (Cloudflare, Fastly) if applicable
• SSL certificate documentation (if using a paid cert)
• Any third-party service credentials (payment gateways, email platforms)

Information to Document

• Current PHP version (and extensions if custom)
• Current database version (MySQL/MariaDB)
• Current web server (Apache, Nginx, LiteSpeed)
• All DNS records — A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC)
• Memory limits and execution timeouts
• Active plugins and versions (WordPress)
• Custom code, cron jobs, and .htaccess rules
• SSL certificate type and provider
• Current performance benchmarks (Core Web Vitals, TTFB)

4. Step 1 — Take a Full Backup

This is non-negotiable. Before you touch a single file, take a complete backup and verify it works.

What to Back Up

• All files — site code, themes, plugins, uploaded media, custom scripts
• The database — full SQL dump of everything
• Email — if your host handles email, back it up separately (usually via IMAP sync to another client)
• Configuration files — .htaccess, nginx configs, wp-config.php, environment variables

How to Back Up

WordPress sites

Plugins like UpdraftPlus, All-in-One WP Migration, Duplicator, or BlogVault handle this cleanly. Many managed hosts also have one-click backup exports you can download.

Non-WordPress sites

Use the hosting control panel’s backup feature (cPanel “Full Account Backup”), or do it manually: SFTP to download all files, plus mysqldump or phpMyAdmin “Export” for the database.

Verify the backup works

A backup you haven’t tested is a backup that might not work. If possible, restore the backup to a local environment or staging site and confirm the site runs. At minimum, open the SQL file and confirm it’s not empty or corrupted, and check the file archive’s integrity.

5. Step 2 — Audit the Current Site

Before migrating, document exactly what’s currently working so you know what needs to keep working on the other side. This audit becomes your testing checklist post-migration.

Technical Audit

• Performance baseline — run GTmetrix or PageSpeed Insights on your homepage, a product/content page, and any dynamic pages (checkout, login). Save the scores.
• Core Web Vitals — LCP, INP, CLS numbers for comparison after the move
• Server response time (TTFB) — measurable baseline you’ll want to match or beat
• Uptime statistics — pull the last 30 days if available, for comparison

Content & Functionality Audit

• Sitemap / URL inventory — pull your XML sitemap or crawl the site with Screaming Frog
• Forms — list every form (contact, signup, checkout) with what should happen on submit
• Integrations — email platforms, payment gateways, analytics, chat widgets, CRM connections
• Scheduled tasks — cron jobs, backup schedules, newsletter dispatches
• Redirects — existing 301 redirects in .htaccess or plugins
• Custom code — snippets in functions.php, custom plugins, modifications to core files

SEO Audit

• Top-ranking pages — pages driving the most organic traffic (check Search Console)
• Canonical tags — make sure they’re not going to break when URLs change
• robots.txt and sitemap.xml — current versions saved for comparison
• Schema markup — structured data currently rendering correctly

Save all of this to a document you can reference during testing. If anything on that list stops working after the migration, you know exactly what to fix.

6. Step 3 — Set Up the New Host

With prep complete, sign up for your new host and get the environment ready before you start moving anything.

1. Sign up and add your domain Create the account on the new host. Add your domain to their system (you’re not pointing DNS yet — just telling the host “this domain will eventually live here”). Most hosts will provision an empty site structure for the domain.
2. Match the current server configuration PHP version, extensions, memory limits, execution timeouts, database version. The new host should match or exceed what you’re running. Mismatches — especially PHP version jumps — cause issues during import.
3. Create an empty database In the new host’s control panel, create a blank database with a user and password. You’ll import your SQL dump into this. Note down the hostname, database name, username, and password — you’ll need them shortly.
4. Install your CMS (if needed) If you’re migrating a fresh WordPress/Drupal/whatever install, some hosts have one-click installers. Others you’ll install manually. Either way, this is just scaffolding — you’ll overwrite most of it during the actual transfer.
5. Set up email (if migrating) If your current host handles email and your new host does too, create the email accounts on the new host with the same addresses. You’ll likely want to keep email at a dedicated provider (Google Workspace, Microsoft 365) rather than the web host, but that’s a separate decision.
6. Get the temporary preview URL Most hosts give you a temporary URL (something like yoursite.newhost.com) or let you use a hosts-file trick to test the site on the new server before changing DNS. Find this — you’ll need it for testing.

7. Step 4 — Transfer Files & Database

Now the actual move. Most hosts offer a free migration service that handles this for you — take them up on it. If you’re doing it manually, here’s the process.

Use the Host’s Migration Service if Available

Kinsta, WP Engine, Cloudways, SiteGround, Bluehost, and most quality hosts offer free migration assistance. You provide your current host credentials, they handle the transfer. This is almost always the right call — their engineers have done this thousands of times and know the pitfalls. Expect 24–72 hours for them to complete a migration.

WordPress: Use a Migration Plugin

If you’re doing it yourself, plugins handle the complexity:

• All-in-One WP Migration — simplest; exports everything to a single file, imports on the new host
• Duplicator — creates a “package” you deploy on the new server
• UpdraftPlus — backup plugin with restore-to-new-location capability
• Migrate Guru — specifically designed for large WordPress sites

Manual Transfer (Non-WordPress or Complex Sites)

1. Upload files via SFTP Connect to the new host via SFTP and upload all site files to the correct directory (usually public_html, www, or htdocs). For large sites, compress to a zip/tar archive first, upload once, extract on the server — dramatically faster than uploading thousands of individual files.
2. Import the database In the new host’s phpMyAdmin or via SSH, import your SQL dump into the empty database you created. Large databases (multi-GB) may need command-line mysql import — the web UI tends to time out.
3. Update configuration files Edit wp-config.php (or equivalent) to point at the new database hostname, name, username, and password. Update any hardcoded paths, API keys, or file system references that might have changed.
4. Update URLs if the domain is different If migrating to a different domain, use a search-replace tool (Better Search Replace plugin for WordPress, or wp search-replace on the command line) to update all URL references in the database. Do NOT use a plain SQL find/replace — it breaks serialized data.
5. Transfer .htaccess and custom configs Move over any custom .htaccess rules, nginx configs, redirect rules, and CDN configurations. These often live outside the main migration and get forgotten.

8. Step 5 — Test Before DNS Change

This is the single most important step most migrations botch. Before you update DNS, you must verify the site works on the new host — and there are ways to do that without touching DNS at all.

Option 1: Use the Host’s Preview URL

Most hosts provide a temporary URL that points at your new site. Open it and click through the entire site. For WordPress, you may need to temporarily update the site URL in the database to test at this preview URL.

Option 2: Use the hosts File (Most Reliable)

The hosts file tells your computer to resolve a domain to a specific IP, overriding DNS for just your machine. This lets you preview the live domain on the new server while everyone else still sees the old server.

Windows:

Edit C:\Windows\System32\drivers\etc\hosts (as administrator). Add a line like:
203.0.113.42   yoursite.com www.yoursite.com

Mac/Linux:

Edit /etc/hosts with sudo. Add the same format. Save, then flush DNS cache (sudo dscacheutil -flushcache on Mac).

Now when you visit yoursite.com on that computer, you’ll hit the new server while everyone else hits the old one. This is the cleanest way to test.

What to Test

• Homepage loads without errors
• Navigation works across major pages
• Images load correctly (no broken links)
• CSS and styling appear correct
• Forms submit successfully (contact, signup, search)
• User login works
• Admin/CMS dashboard is accessible
• Database reads/writes work (new comments, new orders, etc.)
• Payment gateway still functional (test mode if possible)
• SSL certificate active and no mixed content warnings
• 301 redirects functioning as before
• robots.txt and sitemap.xml accessible
• Key pages’ performance matches or beats the old host
• Email-sending works (contact form sends, transactional emails arrive)

9. Step 6 — Lower DNS TTL

DNS records have a Time-To-Live (TTL) value — how long ISPs and users cache the record before checking for updates. Default TTL is typically 3600 seconds (1 hour) or 86400 seconds (24 hours). For a migration, you want this low so the DNS switch propagates quickly.

What to Do

1. Log into your DNS management (usually your domain registrar or Cloudflare)
2. Find your A record (and AAAA if IPv6) for the domain and www subdomain
3. Change the TTL from its current value to 300 seconds (5 minutes)
4. Save the change

Do this 24–48 hours before the planned migration. The goal: by the time you actually change the A record, old caches have already expired with the short TTL in place, so the new value propagates within minutes instead of hours.

Remember to Reset Afterward

Once the migration is complete and stable (after a week or so), reset TTL back to a normal value (3600 or 86400 seconds). Low TTLs increase DNS lookup load slightly and can subtly slow performance — fine temporarily, not ideal permanently.

10. Step 7 — Cutover: Update DNS

This is the moment. You’ve tested everything. TTL is low. Time to point the domain at the new host.

Pre-Cutover Checklist

• Backup verified and stored in 2+ locations
• Site fully tested on new host (via preview URL or hosts file)
• DNS TTL lowered 24+ hours ago
• All DNS records documented (especially MX, TXT, SPF/DKIM)
• Team notified of the scheduled window
• Low-traffic time confirmed
• Old host will stay active for fallback
• New host IP address confirmed

The Cutover Process

1. Freeze the current site If possible, put your current site in maintenance mode briefly to prevent new orders or user-generated content from being stranded on the old host. For most sites this is a 5-minute window. For high-traffic sites, skip this and accept minor split-brain during cutover.
2. Run one final sync If new content has been created since your main transfer (new blog posts, orders, user registrations), run a quick final database sync to capture it. Some migration services handle this automatically as “delta sync.”
3. Update the A record In your DNS panel, change your A record to point to the new host’s IP address. Also update AAAA (IPv6) if applicable, and the www CNAME if it’s a separate record. Save changes.
4. Leave all other DNS records alone This is critical. Do NOT change MX records unless you’re also migrating email. Do NOT change TXT records (SPF, DKIM, DMARC, domain verification). CNAMEs for subdomains pointing to external services (shop.yoursite.com → Shopify, etc.) should remain unchanged.
5. Confirm propagation Use dnschecker.org or whatsmydns.net to check whether the new IP is propagating globally. With low TTL, you should see most regions updated within 5–15 minutes. Sit with the tool open and refresh.
6. Lift maintenance mode on the new site Once DNS is propagating, your visitors are hitting the new server. Take the new site out of maintenance mode (if you set that) and confirm it’s responding.

11. Step 8 — Verify & Monitor

DNS is flipped. Visitors are now hitting the new host. Now comes the critical first hour — the window where any issues become immediately visible.

Immediate Verification (First 15 Minutes)

• Homepage loads on the new server (check IP with dnschecker.org)
• HTTPS works — SSL certificate is active, no browser warnings
• Navigation across major pages works
• Checkout/contact forms submit successfully
• Admin login is accessible
• Images and CSS load (no 404s in browser console)
• Database operations work (place a test comment/order)

First Hour Monitoring

• Set up uptime monitoring (UptimeRobot, Pingdom, StatusCake) if not already
• Watch error logs on the new host for PHP errors, 500 errors, database timeouts
• Check Google Analytics or equivalent for traffic flow — are sessions tracking normally?
• Run a PageSpeed Insights test on the homepage — performance should match or beat baseline
• Confirm email from the site (contact form test, order confirmation) is sending and arriving
• Scan for 404s via Search Console or Screaming Frog

First 24 Hours

• Check that transactional emails are reaching inboxes (not spam)
• Verify scheduled tasks (cron jobs, backup schedules) are running
• Confirm analytics data looks consistent with pre-migration baseline
• Review server resource usage — is CPU/RAM within expected range?
• Monitor uptime and response time for any anomalies

12. Post-Migration Tasks

The site is live on the new host and looking stable. Here’s the follow-up work to finish the migration properly.

Within 24 Hours

• Resubmit your sitemap to Google Search Console and Bing Webmaster Tools
• Fetch the homepage as Googlebot to confirm crawlability
• Verify SSL/TLS configuration (SSL Labs grade should be A or A+)
• Verify robots.txt isn’t accidentally blocking crawlers
• Run a full-site crawl with Screaming Frog to catch broken links or 404s
• Update any CDN origin IP if using one (Cloudflare, Fastly)
• Notify any stakeholders the migration is complete

Within 7 Days

• Keep old hosting account active as rollback fallback
• Monitor Search Console for crawl errors or indexing issues
• Watch analytics traffic patterns for anomalies
• Confirm automated backups are running on the new host
• Test restore from the new host’s backup (if possible)
• Reset DNS TTL to a normal value (3600+ seconds)
• Document anything that broke during migration for future reference

Within 30 Days

• Cancel old hosting account (only after thorough verification)
• Transfer domain registrar if you’re consolidating providers
• Review performance improvement vs baseline; document wins
• Update internal documentation with new host details
• Schedule regular backup verification (quarterly at minimum)
• Review organic traffic in Search Console — any ranking shifts need investigation

13. Common Mistakes to Avoid

Most failed migrations fail for the same reasons. Knowing these in advance lets you sidestep them.

Mistake 1: Changing DNS Before Testing the New Site

What happens: You flip DNS, traffic starts hitting the new host, and you discover something is broken. Now you’re debugging live in front of your users.
Fix: Use the hosts file trick to fully test on the new server before DNS cutover. Never flip DNS on something you haven’t verified end-to-end.

Mistake 2: Forgetting MX or TXT Records

What happens: Email delivery breaks because MX records didn’t transfer. Or SPF/DKIM didn’t carry over and emails go to spam. Or a TXT record verifying domain ownership with Google Workspace got dropped and services stop working.
Fix: Export your full DNS zone file before migration and migrate every record, not just A and CNAME. MX and TXT records are the most-forgotten category.

Mistake 3: Not Lowering DNS TTL

What happens: DNS change takes 24+ hours to fully propagate. During that window, you’re in split-brain — some visitors hit the old host, some the new. Orders/content created in that window may be stranded.
Fix: Lower TTL to 300 seconds at least 24 hours before cutover. This step takes 30 seconds and saves hours of mess.

Mistake 4: Canceling Old Hosting Too Quickly

What happens: A subtle issue surfaces 3 days after cutover. You’d love to restore from the old host’s backup — except you canceled it and the account is gone.
Fix: Keep old hosting active for 2 weeks minimum. The cost of one extra month of hosting is cheap insurance.

Mistake 5: Ignoring the Email Migration

What happens: You migrate the website but the MX records still point to the old host’s mail server. Email keeps flowing — but only until you cancel the old host, at which point mail delivery breaks.
Fix: Decide explicitly whether email is migrating too, and when. Most modern setups use a dedicated email provider (Google Workspace, Microsoft 365) that’s completely independent of the web host. If yours isn’t, that’s worth fixing as part of the migration.

Mistake 6: Skipping the Backup Verification

What happens: Mid-migration something breaks. You reach for the backup and discover it’s corrupted, incomplete, or the plugin used to create it can’t restore it on the new host.
Fix: Test-restore your backup before migration — either to a staging site or a local environment. A backup you haven’t verified is a Schrödinger backup.

Mistake 7: Forgetting .htaccess Rules and Redirects

What happens: Your carefully-maintained list of 301 redirects from pages that changed years ago doesn’t come over. Suddenly you have a huge spike in 404 errors and SEO takes a hit.
Fix: Include .htaccess (or Nginx config equivalents) in your backup list and explicitly transfer them. Verify redirects work on the new host before DNS cutover.

Mistake 8: Migrating During Peak Traffic

What happens: You start migration at 10am on a Tuesday, hit a problem, and are debugging live while your peak audience hits the site. Revenue and reputation take a hit.
Fix: Schedule the cutover during your lowest-traffic window. For most US-audience sites, late evening on a weekday. Check your analytics for your actual low point — you might be surprised.

14. Frequently Asked Questions

The questions that actually come up during hosting migrations.