How to Migrate a Website to a New Host Without Breaking SSL or DNS

Overview

This guide gives you a practical website migration checklist focused on two areas that cause the most trouble during hosting changes: DNS and SSL. In many migrations, the site files and database are not the hard part. The real risk shows up at the edge: old DNS records still pointing to the wrong place, certificates issued for the wrong server, redirects looping, mixed content appearing after cutover, or email records being overwritten during a rushed DNS change.

A safe migration usually follows this order:

1. Inventory what exists now.
2. Prepare the new host completely before changing DNS.
3. Test the new host without sending public traffic yet.
4. Install or reissue SSL on the new server.
5. Reduce DNS TTL ahead of time if you control the zone.
6. Switch only the records that need to move.
7. Verify site, redirects, SSL, and email after cutover.
8. Keep the old host online until you are sure traffic has drained.

If you remember only one principle, make it this one: do not treat DNS, hosting, and SSL as one step. They are related, but they should be staged and verified separately.

It also helps to define what kind of move you are making. A migration from one shared host to another is different from moving to a VPS. A server rebuild with the same domain is different from a registrar or DNS provider move. The checklist below is organized by scenario so you can skip what does not apply.

Checklist by scenario

Use the scenario closest to your setup, then combine it with the universal checks at the end of this section.

Scenario 1: Same domain, new host, same DNS provider

This is the most common case and usually the easiest. Your domain stays where it is, your DNS zone stays where it is, and only the web server changes.

• Document the current environment: export DNS records, note the current A, AAAA, CNAME, MX, TXT, and CAA records, and list any cron jobs, background workers, firewall rules, or custom server modules.
• Back up everything: site files, database, uploads, environment files, SSL-related config, and web server config.
• Build the new server first: install the web stack, create the virtual host or server block, restore files and database, and confirm the application runs locally on the new host.
• Test before cutover: use a hosts file override or a temporary preview URL to load the new server privately. Check homepage, login, forms, admin areas, API endpoints, and static assets.
• Prepare SSL: if you use Let's Encrypt, plan to issue or reissue the certificate on the new host. In most cases, this is cleaner than copying old certificate material. If you are using Certbot, make sure the challenge method will work after cutover or use DNS validation if appropriate.
• Lower TTL in advance: if possible, reduce the TTL of the web-related DNS records well before the migration window so the cutover updates faster.
• Change only the website records: point the relevant A or CNAME records to the new host. Do not rewrite MX, TXT, or other records unless you intend to move email or verification services too.
• Verify HTTPS and redirects: confirm the site serves a valid certificate, redirects HTTP to HTTPS correctly, and does not create loops. If needed, review How to Force HTTPS Safely: Redirect Rules for Nginx, Apache, and Cloud Platforms.
• Monitor both servers: keep the old host running until logs show traffic has shifted and no missing content or session issues remain.

Scenario 2: Same host move, but DNS provider is also changing

This adds risk because DNS changes can break the website and email at the same time if the zone is recreated incorrectly.

• Export the full existing DNS zone: do this before touching nameservers.
• Recreate every record on the new DNS provider: A, AAAA, CNAME, MX, TXT, SPF-related records, DKIM, DMARC, verification tokens, subdomains, and service records.
• Check proxy settings carefully: if using a provider with optional proxying, know which records should be proxied and which should remain DNS-only.
• Confirm CAA records: if CAA is configured, make sure it allows your certificate authority to issue certificates. A forgotten CAA entry can block SSL issuance.
• Validate email records before nameserver switch: MX and TXT mistakes are common and often missed until mail stops flowing.
• Switch nameservers only after the new zone matches the old one: treat this as a separate task from the web hosting cutover.

Scenario 3: Shared hosting to VPS or cloud instance

This move introduces server administration tasks that shared hosting used to hide from you.

• Replicate runtime requirements: PHP version, database version, web server behavior, rewrite rules, file permissions, memory limits, and scheduled jobs.
• Set up firewall and security basics: open only required ports, disable unnecessary services, and install updates before launch.
• Create non-root deployment paths: keep application files organized and permissions predictable.
• Install SSL after web server config is stable: do not add certificate automation until the site answers correctly for the domain.
• Test renewal automation: a valid certificate at launch is not enough. Make sure renewal is scheduled and verify it. See How to Renew Let's Encrypt Certificates Automatically and Verify It Actually Works.
• Plan rollback: know how to repoint DNS if the new VPS behaves differently under live traffic.

Scenario 4: Rebuilding a server and keeping the same host or IP structure

This often happens after an OS refresh, control panel change, or stack cleanup.

• List all domains and subdomains served by the old server.
• Inventory every certificate and renewal method: Certbot, acme.sh, control panel automation, or another ACME client. If you are considering options beyond Certbot, review Certbot Alternatives for 2026: When to Use acme.sh, Dehydrated, Win-ACME, or Caddy.
• Rebuild web server configuration from known-good files: avoid carrying years of deprecated directives into the new system.
• Reissue certificates if there is any doubt: migrating old certificate files is possible, but a fresh issuance is often simpler and less error-prone.
• Check security headers and redirects after rebuild: especially if the old setup used includes or snippets that may not exist on the new system.

Scenario 5: WordPress migration with HTTPS already in place

WordPress moves add application-level URL details that can look like SSL problems even when the certificate is fine.

• Check site URL and home URL settings.
• Search for hard-coded http:// asset links: theme files, page builder content, uploads, and custom scripts may cause mixed content.
• Review plugin behavior: caching, security, redirect, and SSL helper plugins may conflict after migration.
• Flush caches after cutover: plugin cache, server cache, CDN cache, and browser cache.
• Check mixed content explicitly: if pages load under HTTPS but show warnings, see Mixed Content Errors After Installing Let's Encrypt: Causes and Fixes.

Universal cutover checklist

• Backup verified and restorable
• New host tested privately
• Database imports completed
• Application secrets and environment variables moved
• Cron jobs recreated
• Uploads and writable directories checked
• SSL issued or ready to issue
• CAA reviewed if present
• TTL lowered ahead of migration where possible
• Only necessary DNS records changed
• Email records preserved
• HTTPS redirect tested
• Monitoring enabled for uptime and certificate expiry
• Rollback plan written down

What to double-check

This section covers the details most likely to cause a migration that looks successful at first, but fails an hour later or only for some users.

DNS records beyond A and CNAME

Many site owners correctly update the web record, then accidentally break mail or verification services. Before and after cutover, compare the old and new zones line by line. Pay close attention to MX records, SPF-related TXT records, DKIM selectors, DMARC, custom subdomains, and TXT record verification entries used by external services.

IPv6 behavior

If your DNS zone has an AAAA record, your site may still send some visitors to the old server over IPv6 even after you update the A record. If the new host is not ready for IPv6, remove or update the AAAA record intentionally rather than forgetting it exists.

CAA and certificate issuance

CAA records control which certificate authorities can issue for your domain. If a previous administrator added restrictive CAA records, your new Let's Encrypt setup may fail even though DNS appears otherwise correct. If certificate issuance fails, consult Let's Encrypt Error Codes Guide: What Common ACME Messages Really Mean.

Certificate scope

Make sure the certificate covers every hostname that serves content: the root domain, www, and any active subdomains. A migration often goes live with the main domain working while www or a subdomain still presents an old or invalid certificate.

HTTP to HTTPS redirect logic

Redirect rules can conflict when multiple layers try to enforce HTTPS at once. Common combinations include the web server, application, control panel, load balancer, or CDN. Test with and without www, and test direct HTTP requests to ensure there is one clean redirect path rather than chains or loops.

Origin certificate versus public certificate

If you use a reverse proxy or CDN, know whether your origin server needs a public certificate trusted by browsers, an origin-only certificate trusted by the proxy, or both. Misunderstanding this can create hard-to-diagnose SSL warnings.

Renewal automation after the move

Migrations often focus on launch day and forget renewal. Confirm where the ACME client runs now, what challenge method it uses, and whether scheduled renewal is active. For practical monitoring ideas, see Let's Encrypt Expiry Monitoring: Best Tools, Alerts, and Dashboard Options.

Application-level absolute URLs

If the old host used a staging domain, old hostname, or HTTP-only asset paths, the application may keep referencing them after the move. This is especially common in CMS platforms and custom applications with stored configuration values.

Logs during the first hours after cutover

Watch access logs, error logs, PHP or application logs, and ACME client logs. The first hour after DNS change usually reveals missing files, wrong document roots, permission problems, or challenge failures faster than any static checklist can.

Common mistakes

These are the migration errors that repeatedly cause avoidable downtime.

• Changing nameservers and hosting at the same time without a verified zone copy. This creates too many unknowns at once.
• Assuming SSL can be copied blindly. Private keys, file paths, permissions, and ACME account setup vary. In many cases, reissuing is cleaner than moving certificate files.
• Forgetting email records. Website DNS changes do not require replacing MX or TXT records unless email is moving too.
• Not testing the new server before public cutover. A hosts file test catches many problems without risking downtime.
• Leaving the old host too soon. DNS propagation and client caching can keep some users on the old path for a while.
• Ignoring AAAA records. IPv6 can silently route traffic somewhere unexpected.
• Creating redirect loops. This often happens when HTTPS is forced at both the app and server layer without consistent proxy awareness.
• Skipping renewal checks. A certificate that works today but does not renew will create a delayed outage.
• Missing mixed content. The padlock can fail even when the certificate is valid because old HTTP assets are still referenced.
• Not documenting rollback steps. In a stressful migration window, the ability to reverse a DNS change quickly matters more than vague confidence.

If you are still deciding where to move, it helps to choose a provider that supports straightforward HTTPS issuance and renewal. A useful starting point is Best Hosting for Let's Encrypt Support: Shared, VPS, Cloud, and Managed Options.

When to revisit

This checklist is worth revisiting anytime one of the underlying pieces changes, even if the domain stays the same. In practice, that means before a host switch, before a control panel change, before moving DNS providers, before rebuilding a VPS, before enabling a CDN or reverse proxy, and before seasonal traffic periods when you want risk to be low.

It is also smart to review the checklist when any of the following changes:

• Your SSL method changes from panel-managed certificates to Certbot or another ACME client
• Your DNS provider changes proxy or flattening behavior
• Your web stack changes from Apache to Nginx, or from shared hosting to VPS
• Your application adds new subdomains, APIs, or mail-dependent services
• Your current renewal process is unclear or undocumented

Before your next migration, use this short action plan:

1. Export the current DNS zone and save it locally.
2. Create a full backup and confirm it can be restored.
3. Build and test the new host privately.
4. Issue or prepare SSL on the new server.
5. Lower TTL if time allows.
6. Cut over only the required web records.
7. Verify HTTPS, redirects, and email immediately after switch.
8. Monitor logs and certificate status for at least the first day.
9. Keep the old host available until traffic clearly settles.

For server-specific setup help, see Let's Encrypt on Ubuntu: Step-by-Step Setup for Current LTS Releases. If your migration includes WordPress, Let's Encrypt for WordPress: Hosting Requirements, Plugin Options, and HTTPS Fixes is a useful companion. The best migrations are usually the boring ones: staged, tested, and documented well enough that nothing surprises you during cutover.