Moving a Static Site Between Hosts Without Breaking Links: A 2026 Migration Checklist

Hosting providers change pricing, degrade service, get acquired, shut down, or simply stop meeting your needs. At some point, every website owner switches hosts. For a dynamic site running WordPress or a custom application server, migration involves database exports, server configuration, plugin compatibility testing, and a genuine risk of something breaking in ways that take hours to diagnose. For a static site—a folder of HTML, CSS, JavaScript, and image files—the migration is fundamentally simpler. Your entire website is a directory on disk. You copy that directory to the new host, point your domain at it, and you are done.

Except people still break things. They forget to test links after the switch. They let DNS propagation catch them off guard. They overlook the .htaccess redirects that were handling old URLs on the previous host. They migrate the files but not the SSL certificate configuration. The file transfer itself is the easy part. Everything around it is where mistakes happen.

This guide is a complete migration checklist for moving a static website between hosting providers in 2026. It covers pre-migration preparation, file transfer, DNS changes, SSL setup, redirect preservation, SEO considerations, and post-migration verification. Follow it in order, check off each step, and your site will move between hosts without dropping a single visitor or breaking a single link.

Before You Start: What You Need

Gather these items before beginning the migration:

• Access to your current host’s file manager or FTP/SFTP. You need to download a complete copy of your live site. Even if you have a local copy from your folder-based project, the live version may have accumulated changes—redirects, server configuration files, additional assets—that your local copy does not include.

• Access to your new host’s control panel and FTP/SFTP credentials. Set up your account on the new host before starting the migration. Upload a test file to confirm you can connect and that files are served correctly. The FTP protocol guide covers secure connection setup if you need it.

• Access to your domain registrar’s DNS settings. This is where you point your domain name from the old server to the new one. Your registrar is wherever you purchased the domain (Namecheap, Cloudflare, GoDaddy, Google Domains, etc.). Do not confuse your hosting provider with your domain registrar—they may be different companies.

• A list of all URLs your site serves. Every page, every redirect, every asset URL that has been indexed by search engines or linked from external sites. For a small site you can compile this manually. For a larger one, download your sitemap or use a crawling tool.

• Current server configuration files. On Apache hosting, this means .htaccess. On Nginx, the server block configuration. These files contain redirect rules, custom error pages, MIME type definitions, and caching headers that need to be replicated on the new host.

Phase 1: Pre-Migration Preparation

Step 1: Download Everything from the Current Host

Connect to your current host via SFTP and download the entire web root directory. Include hidden files (files starting with a dot, like .htaccess). Your FTP client may hide these by default—check its settings to show hidden files.

Store this download in a clearly labeled folder on your local machine:

site-backups/
└── 2026-04-27-migration-from-oldhost/
    ├── public_html/
    │   ├── .htaccess
    │   ├── index.html
    │   ├── css/
    │   ├── images/
    │   └── ...
    └── notes.txt

This is your definitive record of what was on the old server at the moment of migration. Do not skip this step even if you have a local development copy. The live server is the source of truth.

Step 2: Crawl and Record All Live URLs

Use a tool like Screaming Frog (free for up to 500 URLs), Xenu’s Link Sleuth, or a browser extension to crawl your live site and record every URL that returns a 200 (OK) or 301/302 (redirect) status. Save this list. You will use it for post-migration verification.

Pay special attention to:

• Pages that redirect. If yoursite.com/old-page redirects to yoursite.com/new-page, you need to replicate that redirect on the new host. These redirects may live in .htaccess, in the hosting control panel, or in a server configuration file.
• Non-HTML assets linked externally. If other sites link directly to your images, PDFs, or other files, those URLs need to keep working.
• URL patterns with and without trailing slashes. Some servers redirect /about to /about/. If the new server does not, those URLs may break.

Step 3: Document Server Configuration

Open your .htaccess file (or equivalent) and document every rule:

# Example .htaccess rules to preserve
RewriteEngine On
RewriteRule ^old-services/?$ /services/ [R=301,L]
RewriteRule ^blog/(.*)$ /news/$1 [R=301,L]

ErrorDocument 404 /404.html

# Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Each of these rules needs to exist on the new host. If the new host uses Nginx instead of Apache, you will need to translate the rules to Nginx syntax. If the new host is a static platform like Netlify or Cloudflare Pages, you will use their platform-specific redirect configuration files (_redirects or _headers files, or netlify.toml).

Step 4: Check Your SSL Certificate Situation

If your current site uses HTTPS (it should), determine how SSL is handled:

• Host-provided free SSL (Let’s Encrypt, AutoSSL): The new host will provision a new certificate. No action needed from you other than enabling it on the new host.
• Purchased SSL certificate: You may need to export it from the old host and import it to the new one, or simply let it expire and use the new host’s free SSL option.
• Cloudflare or CDN-provided SSL: If you use Cloudflare as a proxy, SSL is handled at Cloudflare’s edge. Changing the origin server does not affect the visitor-facing certificate.

Phase 2: Upload to the New Host

Step 5: Upload Your Site Files

Connect to the new host via SFTP and upload your complete site directory to the web root. Verify that the folder structure is intact. Check that file permissions are correct (644 for files, 755 for directories on Linux-based hosting).

Upload your .htaccess file or create the equivalent redirect configuration for your new platform. If the new host uses a different web server, translate your redirect rules now.

Step 6: Test on the New Host Before Switching DNS

Most hosting providers give you a way to access your site on the new server before pointing your domain at it. This may be:

• A temporary URL: Something like server123.hostingprovider.com/~youraccount/ or an IP-based URL.
• A staging subdomain: Some hosts provide youraccount.hostingprovider.com.
• Direct IP access: Add an entry to your local hosts file to force your domain to resolve to the new server’s IP address without changing public DNS.

The hosts file method is the most reliable for testing because it lets you see exactly what visitors will see after the DNS switch. On Windows, the file is at:

C:\Windows\System32\drivers\etc\hosts

Add a line:

203.0.113.42  yoursite.com
203.0.113.42  www.yoursite.com

Replace 203.0.113.42 with your new server’s IP address. Save the file (you need administrator privileges). Now when you visit yoursite.com in your browser, it will load from the new server. Every other visitor in the world still sees the old server.

Step 7: Verify Everything on the New Host

With the hosts file pointing to the new server, systematically check:

• Homepage loads correctly. All assets (CSS, JavaScript, images) load. No broken references.
• Internal navigation works. Click through every page. Check that links between pages resolve correctly.
• Redirects function. Test every redirect from your Step 2 list. Confirm they return the correct status code (301 for permanent, 302 for temporary).
• 404 page works. Visit a non-existent URL and confirm your custom 404 page appears.
• HTTPS works. If the new host has SSL configured, verify the certificate is valid and all pages load over HTTPS. Check for mixed content warnings (HTTP resources loaded on an HTTPS page).
• Forms or interactive elements. If your static site includes contact forms that submit to external services, test them.

Fix any issues before proceeding. It is much easier to troubleshoot with both servers running simultaneously than after you have already cut over.

Phase 3: DNS Migration

Step 8: Lower Your DNS TTL

DNS records have a Time To Live (TTL) value that tells DNS resolvers how long to cache the record before checking for updates. If your TTL is set to 86400 seconds (24 hours), DNS resolvers worldwide may continue sending visitors to your old server for up to 24 hours after you change the record.

At least 48 hours before your planned migration, lower your TTL to 300 seconds (5 minutes). This means that once you change the DNS record, resolvers will pick up the change within minutes rather than hours.

Important: The lowered TTL only takes effect after the old TTL period expires. If your TTL was 24 hours and you lower it to 5 minutes, you need to wait 24 hours before the 5-minute TTL is actually propagated. Plan ahead.

Step 9: Update DNS Records

Go to your domain registrar’s DNS management panel and update the A record (and AAAA record if you have IPv6) to point to the new server’s IP address. If your new host uses CNAME-based pointing (common with platforms like Netlify or Cloudflare Pages), update the record accordingly.

If you use www as a separate record, update that too. If you have MX records for email, do not change them unless your email hosting is also moving. This is a common mistake: people change the entire DNS zone when they only need to change the web server records, and their email breaks.

Step 10: Keep the Old Host Running

Do not cancel your old hosting account immediately after updating DNS. DNS propagation is not instant and not uniform. Some visitors will reach the new server within minutes. Others, behind corporate DNS caches or in regions with slower resolver refresh cycles, may reach the old server for hours or even days.

Keep the old host running for at least 72 hours after the DNS change. A week is better. The marginal cost of a few extra days of hosting is trivial compared to the cost of visitors hitting a dead server because a DNS resolver somewhere has not refreshed yet.

Phase 4: Post-Migration Verification

Step 11: Remove Hosts File Override

Delete or comment out the lines you added to your local hosts file in Step 6. Clear your browser cache. Visit your site normally and confirm it loads from the new server.

Step 12: Re-Crawl and Compare

Run the same crawl you performed in Step 2, this time against the live site on the new host. Compare the two URL lists:

• Every URL that returned 200 before should still return 200.
• Every redirect should still work with the same target URL and status code.
• No new 404 errors should appear.

If you find discrepancies, fix them now while the issues are fresh and your old server is still running as a reference.

Step 13: Check Search Console

If your site is registered in Google Search Console, check the coverage report over the following week. Look for new crawl errors, indexing issues, or security warnings. If you changed your URL scheme (HTTP to HTTPS, or non-www to www), add the new property to Search Console and submit an updated sitemap.

Step 14: Update External Services

Services that reference your server by IP address or old hostname need updating:

• CDN configuration. If you use a CDN, update the origin server address.
• Monitoring services. Uptime monitors, analytics pixel endpoints, external form processors.
• Third-party integrations. Any service that pushes data to or pulls data from your server.

Why Static Sites Make This Easier

The entire migration process above applies to any website, but static sites skip the hardest parts. There is no database to export and import. There is no server-side runtime to configure (no PHP version, no Node.js version, no Python environment). There is no application state that could be lost during the transition.

Your website is a folder. You copy the folder. You point the domain. You verify. That’s the migration.

This is one of the fundamental advantages of building with a desktop tool like DFM2HTML. The feature set is designed around producing portable static output. Your project files on your hard drive are the definitive source. The published site is a copy of those files on a server. Moving to a different server means copying the same files to a different location. There is no vendor-specific format to convert, no proprietary hosting platform to disentangle from, no export process that might lose data.

The tutorials section covers the broader context of this publishing workflow, from initial folder structure through secure file transfer to this migration guide. Each piece builds on the same principle: you own the files, you control where they live, and moving them is a file-copy operation rather than a platform migration project.

The Checklist, Summarized

For quick reference, here is the condensed checklist:

1. Download complete site from current host (including hidden files)
2. Crawl and record all live URLs and redirects
3. Document server configuration rules
4. Verify SSL certificate status and plan
5. Upload files to new host
6. Test new host via hosts file or temporary URL
7. Verify all pages, redirects, assets, and HTTPS
8. Lower DNS TTL 48+ hours before switch
9. Update DNS A/AAAA/CNAME records
10. Keep old host running for 72+ hours
11. Remove hosts file override and verify
12. Re-crawl and compare URL lists
13. Check Search Console for issues
14. Update external services and integrations

Print this list. Check off each item. Skip nothing. A static site migration should be a non-event for your visitors—they should never notice it happened. That outcome requires following the steps, not improvising them.