Moving a website to a new server: an HTTPS and DNS checklist

Disclosure: UCELI provides cloud servers and domain services. This article was prepared with AI assistance and reviewed as general educational material. It does not describe a UCELI migration service or guarantee a particular outcome.

A new server must answer for the right hostname, present a trusted certificate and serve the application correctly. Cached DNS can still direct visitors to the old server.

This checklist is for teams with permission to test their own website and infrastructure. It focuses on a move where the public URL stays the same. Adapt it to your architecture and test in an authorized environment. A single check cannot guarantee zero downtime.

1. Record the current setup

Before changing anything, document the hostnames and DNS records used by the website. Note the current A and AAAA records, their TTLs, whether a CDN or reverse proxy is in front, and where TLS terminates. Record the configuration and authorized operator.

Also identify the application’s data dependencies: databases, file uploads, background workers, sessions and third-party integrations. A copy of the website files alone may not reproduce a working service. Make a backup and verify that you can restore it in a safe environment.

2. Plan for the old DNS TTL

A DNS TTL affects how long a resolver may cache an answer. If you lower a TTL immediately before the move, clients that already cached the old record can still use the old, longer TTL. Lowering it ahead of time can help, but timing depends on the existing record and the DNS service. Local caches may also take longer to reflect a change.

Cloudflare’s TTL documentation explains this behavior and its own proxied-record settings. Those provider-specific defaults do not automatically apply to another DNS service. Google’s hosting-move guide recommends preparing DNS changes in advance when moving infrastructure without changing URLs.

3. Check HTTPS on the new server before cutover

If the new server can accept a direct authorized connection, curl --resolve lets one request use a chosen address for a hostname and port. The URL still contains the hostname, so curl uses that hostname for TLS Server Name Indication (SNI) and certificate verification. It does not change DNS for other applications.

The following uses the reserved documentation hostname example.com and documentation address 192.0.2.10. Replace them with a hostname and server address you are authorized to test; the example address is not a real test server.

curl -q --noproxy '*' \
  --resolve example.com:443:192.0.2.10 \
  --silent --show-error --connect-timeout 5 --max-time 15 \
  --output /dev/null \
  --write-out 'remote_ip=%{remote_ip} http=%{http_code}\n' \
  https://example.com/

-q disables the default curl configuration; --noproxy bypasses curl-configured proxies. Use it only where direct access is authorized. The timeouts bound the test, and remote_ip identifies the connected network endpoint. Do not use --insecure to hide certificate errors. By default, this example does not follow redirects; the mapping covers only the specified hostname and port. An HTTP GET can have side effects, so choose an authorized, safe test endpoint. This command does not use --fail, so an HTTP 4xx or 5xx does not necessarily produce a nonzero curl exit code; inspect the status separately. A 200 status does not prove the intended backend, business data or all application flows are correct. Avoid real orders and sensitive test data.

The curl documentation explains the hostname, port and SNI behavior. Addresses in 192.0.2.0/24 are reserved for documentation by RFC 5737.

4. Account for proxies and CDN behavior

A direct request to the new server may bypass a CDN, WAF or load balancer that normally serves visitors. Even the displayed remote IP can belong to a proxy or load balancer rather than the final backend. This test does not validate the complete public path. An origin certificate trusted by a CDN may not be trusted by your local client, and some origins intentionally accept connections only from the proxy. An environment-configured outbound proxy can also change where the test connects.

Use the authorized procedure for your setup. Test the public proxy path separately when appropriate, verify where certificates terminate, and never weaken a firewall or expose an origin merely to make the example work. DNS-only and proxied records can behave differently; confirm your provider’s actual settings.

5. Prepare the cutover and rollback

Decide who will make the change, how you will observe errors, and what conditions will trigger a rollback. Verify the old and new services can handle the transition. Plan how writes, sessions and background jobs behave while some clients may still reach the old address. Reverting DNS does not instantly move every visitor back, and it does not automatically reconcile data written on the new server.

After the change, check DNS responses and application behavior from representative networks. Keep the previous environment available for the period your plan requires, while avoiding conflicting writes. Remove temporary test settings only after verification and restore an appropriate TTL when ready.

UCELI lists cloud server locations and configurations on its cloud server page. Available configurations and final terms depend on the selected region and order; this checklist does not promise managed migration or a particular level of support.

Questions about UCELI configurations? Email support@uceli.com.

Related reading from UCELI: How to estimate a cloud server’s monthly data transfer.

Budget the overlap

Keeping both servers available during a move can affect the cash you need. Record when the old service is paid through, whether it will renew during the rollback period, and the applicable cancellation and termination rules. Add the new server’s first payment and any incremental backup or transfer costs. Separate amounts already paid from amounts still due, keep unknown charges visible, and check each provider’s current terms. A stopped server is not necessarily free.