How to Handle SSL Expiry During a Site Migration: The Agency Checklist

Site migrations are the most dangerous event in the SSL lifecycle of a client website. More SSL failures happen during or immediately after a migration than at any other time — and most of them are preventable with the right pre-migration checks.

The core problem is timing: DNS changes during a migration break the validation mechanisms that certificate authorities and hosting platforms use to renew SSL certificates. The existing certificate continues to serve during the migration. The failure surfaces 30, 60, or 90 days later when the certificate reaches its renewal cycle and the validation fails because DNS no longer matches what the certificate authority expects.

This checklist covers what to check before migration, what to do during DNS cutover, and what to verify after the migration is complete.

Before the Migration

1. Document every SSL certificate on the old hosting

Before touching DNS or moving any content, audit every SSL certificate associated with the client domain:

Primary store or site domain — Who provisioned it? cPanel AutoSSL, Certbot, the CDN, the hosting platform?
All subdomains — staging.clientsite.com, api.clientsite.com, admin.clientsite.com, mail.clientsite.com — each may have independent SSL
Mail SSL — If the client hosts email on the same server, the mail domain SSL may be separate from the website SSL
CDN custom domain SSL — If the client uses Cloudflare, Fastly, or another CDN with a custom domain, the CDN has its own certificate provisioned separately from the origin

Write down: the certificate issuer, the expiry date, and how it is renewed (automated or manual). This becomes the handoff document for the new hosting environment.

2. Check certificate expiry before scheduling the migration

If any certificate on the old hosting expires within 45 days of the planned migration date, renew it before migrating. Do not migrate a site with a certificate that will expire during the transition period.

A certificate that expires during a migration window is the worst case scenario: the old hosting SSL is gone, the new hosting SSL may not yet be fully provisioned, and clients see SSL errors during the migration period — which is often also when a client is reviewing the new site.

3. Provision SSL on the new hosting before cutting DNS

SSL on new hosting should be provisioned and validated before the DNS cutover. Most hosting platforms provision SSL at setup time for their platform domain (clientsite.vercel.app, clientsite.wpengine.com). Custom domain SSL provisioning requires the DNS to point at the platform first.

The sequence for custom domain SSL on new hosting:

Add the custom domain to the new hosting environment
The hosting platform provides a CNAME or A record to add to DNS
Add that record to DNS as a new record — do not yet remove the old record
Wait for SSL to provision on the new hosting (can take minutes to hours depending on the platform and CA)
Verify SSL is valid on the new hosting before cutting the primary DNS record

Some platforms allow pre-provisioning SSL before the domain fully resolves to them. Check whether the new platform supports this — it eliminates the cutover window where neither old nor new SSL is authoritative.

4. Identify Let's Encrypt validation dependencies

Let's Encrypt uses HTTP-01 or DNS-01 challenges to validate domain ownership before issuing and renewing certificates:

HTTP-01 challenge: Let's Encrypt makes an HTTP request to http://clientsite.com/.well-known/acme-challenge/[token]. This requires the domain to resolve to the server requesting the certificate. If DNS is cut to the new server before the old certificate is renewed and the old server's renewal script runs, the challenge succeeds on the new server. But if the old server renews SSL after DNS cutover, the challenge request reaches the new server — which does not have the Let's Encrypt ACME client running — and the renewal fails.

DNS-01 challenge: Let's Encrypt checks for a specific TXT record on the domain. This is independent of where the domain resolves, but requires the DNS provider to support automated TXT record management. If the new DNS provider does not support the DNS-01 challenge for the client's Let's Encrypt setup, the renewal method must change during the migration.

Document which validation method the old hosting uses. Plan for the change in validation target when DNS moves.

During DNS Cutover

5. Lower TTLs 24–48 hours before cutover

Lower the TTL on all DNS records to 300 seconds (5 minutes) at least 24 hours before the planned cutover. This reduces the propagation window when DNS changes. After the migration is stable, restore TTLs to standard values (3600 seconds or higher).

Do not change TTLs at the same time as changing DNS targets — lower the TTL first, wait for it to propagate, then change the targets.

6. Cut the primary A record or CNAME in a single change

Avoid staged DNS changes where some records point at the old hosting and others at the new. Mixed DNS propagation creates a state where some visitors reach the old site and others reach the new site — each with potentially different SSL certificates, different content, and different functionality.

Cut all records for the primary domain in a single DNS change. Monitor DNS propagation immediately after the change to confirm the new records are resolving globally.

7. Verify SSL is active on the new hosting before declaring migration complete

After DNS cutover, verify SSL from multiple geographic locations and from multiple DNS resolvers before informing the client the migration is complete. A certificate that is valid from your location may not be valid globally if CDN edge provisioning is still in progress.

Tools to check from multiple locations: SSL Labs server test, an online SSL checker that shows the certificate from multiple vantage points, or Merlonix's monitoring which checks from three independent DNS resolvers.

8. Monitor for DNS propagation issues immediately after cutover

DNS propagation is not instantaneous. After a cutover, some resolvers around the world are still returning the old A records or CNAMEs. During this window:

Some visitors reach the old hosting (with old SSL, which should still be valid)
Some visitors reach the new hosting (with new SSL)
Both should work — if you provisioned SSL on new hosting before cutover

Watch for DNS resolver discrepancies immediately after cutover. If some resolvers are returning old records 24 hours after the change, investigate whether the old record TTL was properly lowered before cutover.

After the Migration

9. Verify all subdomains — not just the primary domain

After the primary domain SSL and DNS are confirmed on the new hosting, verify all subdomains:

Staging subdomains
Admin subdomains
API subdomains
Mail subdomains (if hosted on the same domain)
Any CDN-routed subdomains

Subdomain SSL often requires separate action on the new hosting. cPanel AutoSSL will provision SSL for subdomains on the same hosting account, but only if those subdomains are configured as add-on domains or subdomains within cPanel. If subdomains have been manually added to the old server's Let's Encrypt configuration, they need to be manually re-added to the new environment's certificate configuration.

10. Update CNAME targets for any CDN custom domains

If the client uses a CDN — Cloudflare, Fastly, Cloudfront, or a CDN bundled with the hosting platform — with custom domain SSL, the CNAME target for the custom domain may need to be updated to point at the CDN's new edge hostname for the new hosting origin.

Fastly, CloudFront, and similar CDNs require the CNAME for the custom domain to point at the CDN's hostname — not at the origin server. If the CDN was configured with the old hosting origin and the CNAME for the CDN's custom domain SSL has not been updated, Fastly or CloudFront will continue routing requests to the old origin (which no longer serves the client's content) until the CNAME is updated.

11. Check for renewal configuration on the new hosting

After the migration, confirm that SSL renewal is correctly configured on the new hosting:

cPanel AutoSSL: Is AutoSSL enabled for the domain? Is the Let's Encrypt plugin active?
Certbot on VPS: Is the Certbot cron running? Run certbot renew --dry-run to confirm
Vercel/Netlify: Custom domain SSL renews automatically — confirm the domain shows "SSL certificate: active" in the platform dashboard
CDN: Confirm custom domain TLS is set to auto-renew and the CNAME is pointing at the correct CDN hostname

A migration that provisions SSL correctly at launch but does not configure renewal will produce an SSL expiry failure 90 days later — after the project is closed and the client's site is in maintenance mode.

12. Add all migrated domains to monitoring

After the migration is complete and SSL is confirmed, add all domains to a monitoring system that watches:

SSL expiry (30-day lead time minimum)
CNAME integrity (the DNS configuration that allows renewal to succeed)
DNS propagation from multiple resolvers

The most common post-migration SSL failure is a renewal cycle failure caused by a DNS detail that was not correctly replicated in the new DNS zone. CNAME integrity monitoring catches these before the renewal cycle fails — not 90 days later when the certificate expires.

The Rollback SSL Problem

If a migration needs to be rolled back — rolling DNS back to the old hosting — the old hosting SSL may have expired or been deprovisioned during the migration window. Before cutting DNS back to the old hosting, verify the old hosting SSL is still valid and can be used for immediate traffic.

If the rollback window extends beyond the old certificate's expiry, the rollback requires re-provisioning SSL on the old hosting before the DNS rollback — or accepting a brief SSL error window during the rollback.

Document the old hosting SSL expiry date before beginning any migration. Include it in the migration risk assessment. If the old certificate expires before the migration is complete and validated, either accelerate the migration timeline or plan for the rollback SSL risk explicitly.