Migrating a website to a new host is one of those tasks that looks straightforward on the surface and turns into a multi-day ordeal if you don’t know where the landmines are. Done right, it’s nearly invisible to visitors — the site keeps running, search rankings hold, email keeps delivering, and the only person who notices anything happened is you. Done wrong, you get downtime, lost data, broken links, a confused DNS propagation window, and an anxious week watching your Google rankings tick downward.

The good news is that a well-planned migration is genuinely straightforward. The bad news is that most migration guides skip the parts that actually cause problems: what to do with your TTL before the switch, how to test on the new server without changing DNS, what “propagation” actually means and why you can’t rush it, and what to verify in the critical 48 hours after the cutover.

This guide covers the complete process from end to end — for WordPress sites, static sites, and custom-built applications — with every step in the right order. Whether this is your first migration or your fifteenth, the checklist at the end is worth keeping open in a second tab while you work.

1. Before You Migrate: What to Audit First

Rushing into a migration without a clear picture of what you’re moving is how things get left behind. Spend 30 minutes on this audit before touching a single file, and you’ll avoid the two most common migration disasters: discovering a missing database after DNS has already flipped, and realizing you forgot about email halfway through the process.

Know Exactly What You’re Moving

A “website” is rarely just files. Run through each item in this inventory before you start:

Document Your Current DNS Records Before You Touch Anything

This step alone prevents more migration disasters than any other single action. Log into your domain registrar and copy down every DNS record currently set for your domain. You’ll need to recreate them exactly on the new host. Pay special attention to:

• MX records — control where your email is delivered. Get these wrong and email silently disappears.
• SPF, DKIM, and DMARC records (TXT records) — email authentication. Losing these causes your outbound email to land in spam.
• CNAME records — often used for third-party services: Google Search Console, Mailchimp, Stripe, etc.
• Current TTL values — you’ll be lowering these before migration; document the originals so you can restore them afterward.

Check Your Current Hosting Contract

Before migrating, confirm a few things with your current host: Does your plan include free migration assistance to another provider? (Some do — odd but worth checking.) Do you have any remaining contract term that you’d be walking away from? Is there a cancellation process with notice requirements? Don’t cancel your old hosting until you’ve confirmed everything is working on the new host — keep both active for at least 72 hours after the DNS cutover.

2. The 4 Migration Methods Explained

There’s no single “right” way to migrate a website — the best method depends on your platform, technical comfort level, and how much time you want to spend. Here are the four options, with honest pros and cons for each.

3. Step 1 — Back Up Everything First

This is not optional, and “I’ll do it after” is not a valid migration strategy. Your existing hosting account is your safety net throughout this entire process. If anything goes wrong on the new host, you need to be able to revert to a clean, working state within minutes. A backup you made before you started is that safety net.

What a Complete Backup Includes

• All website files — everything in your public_html (or equivalent) folder, including hidden files like .htaccess and .env
• Database export — a full SQL dump of every database your site uses
• Email data — if you have hosted email on the same account, export mailboxes before migrating
• Server configuration — any custom Nginx/Apache config, cron job definitions, PHP settings

How to Create Your Backup

Option A: Via cPanel (Easiest)

Log into cPanel → Backup Wizard → Full Backup. This packages everything — files, databases, email — into a single compressed archive you can download. For large sites, this process can take 10–30 minutes. Some hosts also have a Jetbackup or Softaculous backup manager that works similarly.

Option B: Via FTP + phpMyAdmin (Manual)

Connect to your server via FTP/SFTP (FileZilla is the standard tool), download your entire public_html folder. Then in cPanel, open phpMyAdmin, select your database, click Export → Quick → Go. Save the resulting .sql file alongside your files backup.

Option C: Via SSH (Most Reliable for Large Sites)

For sites over a few gigabytes, FTP is painfully slow. SSH is dramatically faster:

4. Step 2 — Set Up Your New Host

Before moving a single file, get the destination fully ready. Trying to configure your new hosting account at the same time as migrating files is how things get mixed up and steps get skipped.

New Host Setup Checklist

• Create your hosting account and log into the control panel
• Add your domain to the new account — but do not change your DNS yet. Most hosts let you add a domain without requiring it to point to them.
• Create your database(s) on the new host — note the database name, username, and password. These will need to go into your site’s config file.
• Create email accounts if you use hosted email — you’ll want these ready before the DNS switch so there’s no gap in service
• Verify PHP version — confirm the new host runs the same PHP major version (or newer) as your current host. A version mismatch is a common cause of post-migration errors.
• Install SSL certificate — most hosts provision a free Let’s Encrypt certificate automatically when a domain is added. Confirm this is active or set it up before going live.
• Configure any required PHP extensions — check your application’s requirements and verify they’re available on the new host (e.g., GD library, imagick, intl)

Lower Your DNS TTL — Do This 24–48 Hours Early

TTL (Time to Live) is how long DNS resolvers around the world cache your DNS records before checking for updates. If your TTL is 86400 seconds (24 hours) — a common default — and you change your DNS, some visitors will still reach your old server for up to 24 hours afterward. That creates a split-brain situation where some visitors see the old site and some see the new one.

The fix: log into your registrar or DNS provider now (24–48 hours before you plan to migrate) and reduce the TTL on your A record and CNAME records to 300 seconds (5 minutes). When you’re ready to cut over, changes will propagate globally in under 10 minutes instead of up to 24 hours. After the migration is fully complete and stable, restore the TTL to a normal value (3600 or higher).

5. Step 3 — Migrate a WordPress Site

WordPress is the most common migration scenario, and fortunately it has the most tooling. Here are the three reliable methods in order of recommended approach.

Method 1: Duplicator Plugin (Recommended for Most Sites)

Duplicator is the most widely used WordPress migration plugin and handles sites up to several gigabytes reliably. The free version covers most migrations; Duplicator Pro adds support for very large sites and additional storage options.

1. Install Duplicator on your current (old) WordPress site via Plugins → Add New
2. Go to Duplicator → Packages → Create New. Accept the defaults for a standard migration. Duplicator scans your site and builds a package — this produces two files: a ZIP archive (your site files + database) and an installer.php file.
3. Download both files to your local machine.
4. Upload both files to the root of your new hosting account via FTP/SFTP (typically the public_html folder).
5. Run the installer by visiting yournewhost.com/installer.php in your browser. (You’ll need to access this via your new host’s temporary URL or by editing your local hosts file — covered in Section 8.)
6. Enter your new database credentials when prompted. Duplicator imports the database, updates all URLs automatically, and completes the installation.
7. Delete installer.php and any remaining archive files from the server immediately after — these are security risks if left in place.

Method 2: All-in-One WP Migration

All-in-One WP Migration has a simpler interface and is friendlier for non-technical users. The free version has a 512MB import size limit, which is enough for most basic WordPress sites. Sites with large media libraries will need the paid version or a different method.

1. Install the plugin and go to All-in-One WP Migration → Export. Click Export To → File.
2. Download the .wpress export file.
3. Install All-in-One WP Migration on your new host’s WordPress installation.
4. Go to All-in-One WP Migration → Import, upload your .wpress file, and confirm.
5. Log in with your original WordPress credentials (the import replaces the new site entirely).

Method 3: Manual WordPress Migration

For very large sites, sites with complex setups, or when you want full control over every step, manual migration is the most reliable option. It takes longer but leaves nothing to a plugin’s interpretation.

1. Download all WordPress files via FTP — the entire public_html directory. For large media libraries, this can take hours via FTP; consider using a ZIP via SSH instead.
2. Export the database via phpMyAdmin or WP-CLI: wp db export backup.sql --allow-root
3. Upload files to the new host via FTP or SSH.
4. Import the database on the new host (covered in Section 7).
5. Update wp-config.php with the new host’s database credentials: DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST.
6. Update site URLs in the database if your temporary testing URL differs from your live URL — use WP-CLI: wp search-replace 'http://oldurl.com' 'https://newurl.com' --all-tables

6. Step 4 — Migrate a Static or Custom Site

For static HTML/CSS/JS sites, Jamstack builds, or custom-built PHP/Python/Node.js applications, the migration process is more manual but often simpler (no database URL replacement, no plugin dependencies).

Static Sites (HTML, CSS, JavaScript)

The simplest migration possible: download all files from the old host via FTP, upload them to the new host’s public_html (or equivalent) directory in the same structure. Verify file permissions (files should typically be 644, directories 755). Test via the temporary URL. Point DNS. Done.

The most common issue with static site migrations is missing hidden files — particularly .htaccess on Apache hosts (which controls redirects and URL rewriting) and robots.txt. Configure your FTP client to show hidden files before downloading.

Jamstack / Static Site Generator Builds

If you’re using Gatsby, Hugo, Next.js (static export), or similar, you’re migrating the compiled output — not the source code. The /dist or /public build folder is what needs to go on the new host. If you’re also migrating your CI/CD pipeline (GitHub Actions, Netlify, Vercel builds), update the deployment target and environment variables in your build configuration.

Custom PHP Applications

1. Download all application files via FTP/SFTP, including any .env files not in the web root
2. Export and migrate your database (Section 7)
3. Update your database connection settings and any hardcoded paths or environment-specific configuration
4. Verify PHP version compatibility and required extensions on the new host
5. Check file permissions — uploaded files directories often need to be writable by the web server
6. Recreate any cron jobs that were running on the old server

Node.js / Python Applications

These typically run on VPS or cloud hosting rather than shared hosting. Migration involves moving application code, recreating your environment (Node version via nvm, Python version via pyenv or venv), installing dependencies, migrating your database, and configuring your process manager (PM2, Gunicorn, systemd) on the new server. Also migrate any environment variables — these are often stored in .env files outside the web root or in the server’s environment, not in your codebase.

7. Step 5 — Migrate Your Database

The database contains all your dynamic content — posts, pages, users, orders, settings, comments. It’s the most critical piece of the migration, and the most common source of errors. A file migration with a missing or corrupted database import leaves you with a broken site.

Exporting the Database from the Old Host

Via phpMyAdmin

Log into cPanel → phpMyAdmin. Select your database in the left panel. Click Export → Method: Quick → Format: SQL → Go. Save the .sql file. For large databases (over 50MB), phpMyAdmin can time out — use WP-CLI or SSH instead.

Via WP-CLI (WordPress)

SSH into your old server and run: wp db export your-backup.sql --allow-root. This is faster and more reliable than phpMyAdmin for large databases. The output file can then be downloaded via FTP or SCP.

Via MySQL CLI (Any Platform)

SSH into your server and run: mysqldump -u username -p database_name > backup.sql. For multiple databases: add --all-databases. This is the most reliable method for large databases and complex schemas.

Importing the Database on the New Host

Via phpMyAdmin

Log into the new host’s phpMyAdmin. Select your newly created empty database. Click Import → Choose File → select your .sql file → Go. phpMyAdmin has a default upload limit (often 50–256MB); if your database is larger, use the CLI method.

Via MySQL CLI

SSH into your new server: mysql -u username -p database_name < backup.sql. This works for any database size and is the most reliable import method.

Update Database Connection Settings

After importing, update your application's database connection to point to the new credentials:

• WordPress: Edit wp-config.php — update DB_NAME, DB_USER, DB_PASSWORD, DB_HOST
• Laravel / PHP frameworks: Update your .env file — DB_DATABASE, DB_USERNAME, DB_PASSWORD, DB_HOST
• Custom PHP: Find and update your database connection file (often config.php, db.php, or similar)

8. Step 6 — Test Your New Host Before Going Live

This is the step most people skip because it feels like extra work. It isn't. Testing your migrated site on the new host before changing DNS is the difference between a seamless cutover and discovering a broken site after your visitors are already seeing it. You need a way to view the new site without changing DNS for everyone else.

Method 1: Your Host's Temporary URL

Most shared hosts and managed WordPress hosts provide a temporary URL for accessing your account before DNS propagation — something like server123.hostnamehere.com/~yourusername/ or a preview subdomain. Log into your new hosting control panel and look for a "temporary URL," "preview link," or "testing URL" option. This lets you access your site on the new server without touching DNS.

The limitation: if your site has hardcoded URLs pointing to your actual domain (common in WordPress), some things may not work correctly from the temporary URL. The hosts file method below solves this.

Method 2: Edit Your Local Hosts File

The hosts file on your computer lets you override DNS for your own machine only — everyone else still sees the old host while you see the new one via your real domain. This is the most accurate way to test, because your site works exactly as it will in production.

Find your new server's IP address from your new hosting control panel, then add a line to your local hosts file:

Add a line in the format: 123.456.789.0 yourdomain.com www.yourdomain.com (using your new server's actual IP). Save the file, flush your DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS), and visit your domain — you'll now see the new host. Remove these lines after testing is complete.

What to Test Before Going Live

• Home page loads correctly with all styles and images
• Internal navigation — click through 5–10 pages and verify none return 404s
• Contact forms submit and you receive the test email
• WordPress admin login works (/wp-admin)
• Any e-commerce checkout flow (for WooCommerce sites)
• Login / member area access (for membership sites)
• Images load — particularly the media library on WordPress
• Search functionality works
• SSL certificate is active (https:// loads without browser warnings)
• No mixed content warnings (HTTP resources loading on HTTPS pages)
• Page speed — run a quick PageSpeed Insights test via the temporary URL

9. Step 7 — DNS: The Cutover Explained

The DNS cutover is the moment your site officially moves. Understanding what actually happens during propagation — and what to do during it — is essential for managing this phase without unnecessary stress.

What DNS Propagation Actually Means

When you change your A record to point to your new server's IP, that change doesn't instantly reach every internet user. DNS resolvers around the world have cached your old IP address, and they'll continue using it until their cache expires (based on the TTL value). With a TTL of 300 seconds (5 minutes, which you set in advance), most resolvers will pick up the new IP within 5–15 minutes. Some stubborn resolvers may take longer — a small fraction of users might see your old host for up to an hour or two.

This is why you must keep your old hosting active during and after the cutover. Traffic will continue arriving at the old server until every resolver in the world has updated — you can't control that timeline.

The DNS Propagation Timeline

What to Change in DNS

• A record — Change the IP address to your new server's IP. This is the primary record that controls where web traffic goes.
• www CNAME — Update to point to your new domain/server if it was pointing to the old host's hostname.
• MX records — Update these only if you're also moving your email. If your email is hosted separately (Google Workspace, Zoho, etc.), leave MX records exactly as they are.
• Any other records — Recreate SPF, DKIM, DMARC, and any CNAME records for third-party services on the new host's DNS.

10. Step 8 — Post-Migration Verification

The migration isn't done when DNS propagates. The 48–72 hours after cutover is a critical window for catching things that look fine in testing but reveal problems under real traffic. Work through these verification steps systematically.

Immediate Checks (First 30 Minutes)

• Confirm HTTPS is working — visit your site and verify the padlock shows in the browser. No SSL means visitors see a security warning.
• Test from a device that was definitely not used for hosts-file testing — use your phone on mobile data to confirm real visitors see the new host correctly.
• Submit a contact form or test order — confirm transactional functions are working with real email delivery.
• Check your server error logs — look for 500 errors, PHP notices, or database connection failures in the new host's error log.
• Verify email delivery — if you moved email to the new host, send a test email from a Gmail account and confirm it arrives in both the inbox and without spam classification.

SEO and Analytics Checks (First 24 Hours)

• Check Google Search Console for any new crawl errors or coverage issues
• Verify Google Analytics is still tracking (confirm the tracking code is present in the page source)
• Test 5–10 URLs that should exist and confirm they return 200 status codes
• Test any important redirects — 301s from old URL patterns should still be working
• Run a Screaming Frog crawl or use Sitebulb to check for broken links and unexpected 404s

Performance Checks

• Run Google PageSpeed Insights on your home page and a key inner page — compare to your pre-migration baseline
• Check TTFB from multiple locations using WebPageTest or GTmetrix
• Verify caching is active — a second page load should be significantly faster than the first (if caching is configured)

11. Protecting Your SEO During a Migration

A host migration, done correctly, should have zero impact on your search rankings. Google doesn't penalize you for changing servers — it cares about content, URLs, and user experience, not which data center your files live in. But done carelessly, a migration can cause ranking fluctuations that take months to recover from.

What Causes SEO Damage During Migrations

• Downtime during the switch — If Googlebot tries to crawl your site during a period of unavailability, it can temporarily de-index pages. Keep both servers running during the transition.
• Broken redirects — If your old .htaccess redirects aren't transferred to the new host, pages that were 301-redirecting to canonical URLs now return 404s. Google drops the link equity immediately.
• Accidental URL structure changes — Migrating is not the time to also restructure your URLs. Any URL that changes needs a 301 redirect from the old URL to the new one.
• Missing or wrong canonical tags — Check that your canonical tags still point to the correct URLs after migration, especially if you had URL replacements.
• SSL problems — HTTP pages that were previously HTTPS (or the reverse) can cause duplicate content issues. Verify all pages resolve to their HTTPS versions.
• Robots.txt blocking crawling — Some migration setups (especially WordPress staging environments) add Disallow: / to robots.txt. Verify your live site's robots.txt is correct after going live.

The Migration SEO Checklist

• All existing URLs return 200 on the new host — or have 301 redirects if they've changed
• robots.txt is present and does NOT block Googlebot
• XML sitemap is accessible at /sitemap.xml and all URLs in it return 200
• Canonical tags are present and point to the correct HTTPS URLs
• All HTTP URLs redirect to HTTPS (301, not 302)
• Google Analytics tracking code is present on every page
• Google Search Console property is verified and shows no errors post-migration
• No accidental noindex tags introduced during the migration

12. Common Mistakes and How to Avoid Them

These are the migration mistakes that appear on hosting forums and support tickets every day. Most are entirely preventable.

Cancelling the Old Host Too Soon

The most emotionally satisfying but practically dangerous part of finishing a migration is cancelling the old host. Resist the urge. Keep the old account active for at least 72 hours — a week is better. You need it as a rollback path, and you may discover issues (missing cron jobs, forgotten email accounts, database tables that weren't in the export) that require you to go back and pull something from the old server.

Forgetting to Migrate Email

Email and web hosting are often sold together on shared hosting plans but are functionally separate services. Many people migrate their website files and database and then discover their email has stopped working because the MX records still pointed to the old host, which is now cancelled. Before cancelling anything, confirm what DNS records your email depends on and whether they need to change.

Not Testing Before DNS Change

Going live without testing the new host is gambling. The five most common broken things discovered after a live DNS switch — things that would have been caught in 20 minutes of pre-launch testing — are: wrong database credentials in config, missing .htaccess file, PHP version incompatibility, missing file permissions on uploads directories, and SSL certificate not yet provisioned. Test first. Every time.

Ignoring the Hosts File Method

Most people don't know about editing the local hosts file and instead rely on the temporary URL for testing. The problem: if your site has hardcoded https://yourdomain.com URLs (WordPress does by default), the temporary URL test is unreliable because all internal links still point to the old host. The hosts file method gives you a true production-identical test on your own machine before anyone else sees it.

Changing DNS at Peak Traffic Hours

Schedule your DNS cutover for a low-traffic period — early morning on a weekday, or late night on a weekend. During the propagation window, some visitors will hit the old server and some the new one. If you're making any post-migration fixes, you want to do them during quiet hours. A migration that starts at 2pm on a Monday, in the middle of your peak traffic period, gives you much less room to troubleshoot calmly.

Forgetting Cron Jobs

Scheduled tasks — WordPress cron jobs, backup scripts, database cleanup jobs, email digest scripts — are defined at the server level and are not included in a website file backup. After migration, log into your new host's cPanel or crontab and recreate every scheduled task that was running on the old server. The absence of cron jobs is a silent failure that can take days or weeks to notice.

Migrating at the Same Time as a Redesign

Combining a host migration with a website redesign doubles the variables and makes it nearly impossible to diagnose what caused a problem if something goes wrong. Is the broken contact form a migration issue or a theme issue? Did the plugin conflict exist before the migration or is it the new PHP version? Migrate the existing site intact first. Confirm it's working perfectly. Then redesign.

13. Complete Migration Checklist

Print this out or open it in a second tab. Check off each item in order. A migration where every item is checked is a migration that goes smoothly.

Before You Start (Days Before)

• Full audit completed — files, databases, email, cron jobs, DNS records documented
• Screenshot or export of all current DNS records saved
• New hosting account created and domain added (DNS not yet changed)
• New database created on new host with credentials noted
• DNS TTL reduced to 300 seconds on A record and CNAME records (do this 24–48h early)
• Email accounts created on new host (if moving email hosting)
• PHP version confirmed matching or newer on new host

Backup

• Complete file backup downloaded (including hidden files — .htaccess, .env)
• Database export completed and verified (open SQL file and confirm it has content)
• Email backup completed (if applicable)
• Backup files stored locally AND in a secondary location (cloud storage)

Migration

• All site files uploaded to new host
• Database imported on new host
• Config file updated with new database credentials (wp-config.php / .env)
• URL replacement performed if testing domain differs from live domain
• SSL certificate active on new host
• Cron jobs recreated on new host
• .htaccess file present and correct (Apache) or Nginx rules configured
• File permissions verified (644 files, 755 directories)

Testing (Before DNS Change)

• Site tested via hosts file method or temporary URL
• Home page, inner pages, and navigation all load correctly
• All forms tested and email delivery confirmed
• Admin / login area working
• Media and images loading correctly
• HTTPS working without mixed content warnings
• Any e-commerce or membership functionality tested end-to-end
• Hosts file entries removed after testing

DNS Cutover

• A record updated to new server IP
• All other required DNS records updated or recreated
• Propagation confirmed with whatsmydns.net from multiple locations
• Site loading correctly for real visitors (verified via mobile on data connection)

Post-Migration (Within 72 Hours)

• HTTPS working on live domain (not just via hosts file)
• Email sending and receiving confirmed on live domain
• Google Analytics confirmed tracking live data
• Google Search Console checked for new crawl errors
• PageSpeed / GTmetrix test run and compared to pre-migration baseline
• Screaming Frog crawl run to check for broken links and unexpected 404s
• Cron jobs confirmed running on new host
• Error logs reviewed for any PHP errors or 500s
• DNS TTL restored to normal value (3600 or higher)
• Old hosting cancelled only after 72h+ of confirmed stable operation