A hosting move can succeed at copying pages while leaving HTTPS broken on an alias, an older endpoint or a resource host. A domain change adds another layer: the old names still need to deliver visitors safely to the new ones. Use this checklist before the change, immediately afterward and during the transition.

You need an inventory of public hostnames, access to the relevant hosting and DNS accounts, and an agreed person who can correct or roll back the change. This guide organizes verification; use your platforms’ migration instructions for the actual configuration work.

Prepare before switching traffic

  • List the primary domain, www variant, subdomains and old names that must redirect.
  • Record the current and intended destination for each name, including IPv4, IPv6 and any CDN.
  • Arrange the required certificate coverage and activation on the destination.
  • Identify separate edge and origin certificate responsibilities.
  • Agree on a rollback owner, decision point and content-update plan.

A provider preview may use its own hostname and certificate. Treat that as evidence about the preview, not proof that your public custom domain is ready. Use a provider-supported check that preserves the intended hostname and normal TLS verification when available.

When planning DNS changes, account for caching. TTL describes how long DNS answers may be cached; lowering it does not erase answers already cached under an earlier TTL. Different observers may therefore reach different endpoints during a transition. Cloudflare’s TTL documentation explains caching and notes that local caches can delay observed changes. A low TTL is not a zero-downtime guarantee.

Check routing and the served certificate

After the switch, verify each public hostname reaches the intended service and presents appropriate certificate coverage, dates and chain. Check both IPv4 and IPv6 paths when your site advertises them. A forgotten address record can send some visitors to the previous server.

With a CDN, inspect its connection to the origin as well as browser-facing HTTPS. Those are separate connections with separate certificate requirements; Cloudflare’s edge and origin explanation illustrates the distinction. Keep any previous endpoint that may still receive traffic functional and appropriately secured during the planned overlap.

Walk through the redirect routes

Check direct HTTPS, HTTP-to-HTTPS behavior, alternate hostnames and old domain URLs. Confirm that important old paths reach the intended new paths rather than all landing on the homepage. Look for loops, unnecessary hops, unexpected domains and lost query information where it matters to the application. MDN explains HTTP redirect behavior.

The starting HTTPS hostname needs a valid connection before it can deliver a redirect. Keep its certificate and hosting arrangement working for as long as that redirect remains part of the migration plan. Also verify important application requests; redirect handling can depend on the response status and request method.

Check resources and real user journeys

Open representative pages and use the browser’s developer console and network view to inspect failures. Include templates with images, fonts, scripts, embedded content and downloads. Follow login, account and other relevant journeys without submitting unnecessary real data.

An HTTPS page can still reference HTTP resources. Browsers upgrade some mixed content and block other types, so a page that appears partly correct can hide a broken dependency. MDN’s mixed-content guide explains the behavior. Correct resource URLs through the CMS or application’s supported process, then confirm that the secure resources exist and load.

Preserve policy and renewal ownership

Review existing HSTS settings before the move. Browsers can retain that HTTPS-only policy, so falling back to HTTP is not a reliable rollback. Avoid expanding HSTS scope casually during the same change; MDN documents its persistence and subdomain effects.

Finally, assign renewal responsibility on the new setup and retain it for old redirecting names. Check validation access after DNS or routing changes. Escalate unresolved certificate failures to the endpoint owner; coordinate rollback with any new content or account changes. Record actual observations and outstanding exceptions before calling the migration complete.

Sources