How to Test Your New Host Before Moving Your Site

You test a new web host before migrating by running the same probes your site will run every day, from DNS lookups to HTTP responses, plus a few you hope never to need. The practical pre-migration checklist is not about loading the homepage once, it is about measuring latency, timeouts, header behavior, and support responsiveness from the exact network path your visitors will use. Do this before you touch your DNS records, and you will catch most problems that turn a move into a weekend of regret.

Start with the network path, not the browser

Your browser hides the handshake. So open a terminal and use curl to see what the host actually sends back. The first command to run is a verbose request against the host's own test domain or an IP you were given. You want to see the TCP connect time, the TLS handshake, and the HTTP response headers. Run this from a machine that is not on the same network as the host, preferably from a VPS or a cloud shell in a different region than your current audience.

curl -sS -o /dev/null -w "connect: %{time_connect}s\n" \
     -w "tls: %{time_appconnect}s\n" \
     -w "total: %{time_total}s\n" \
     -w "http_code: %{http_code}\n" \
     https://test.example.com/

Look at the time_connect value first. If it is above a few hundred milliseconds from a nearby location, the host's network is congested or their edge is far from you. The time_appconnect tells you how fast their TLS stack finishes. A slow TLS handshake often means an overloaded front-end proxy or a misconfigured certificate chain. Then check http_code. Anything other than 200 or 301 on a static test page means their web server is rewriting or blocking requests in ways you will have to debug later.

Probe the HTTP headers for hidden traps

Headers reveal more than the page content. Run a plain curl -I against a few paths, including a nonexistent one, to see how the host handles errors. You are looking for three things: the server software, the compression settings, and the caching headers. If the host runs a reverse proxy like Varnish or Cloudflare in front of Apache or Nginx, you need to know that because it changes how you flush caches and how you set Cache-Control.

curl -I https://test.example.com/nonexistent-page
HTTP/2 404
date: Tue, 04 Mar 2025 12:00:00 GMT
server: nginx
cache-control: no-cache
content-type: text/html; charset=UTF-8

Notice the server header. If it says nginx but the host told you they run Apache, their config is layered. That is fine, but you must test .htaccess rules or mod_rewrite logic against the real stack, not against what they claim. Also check the cache-control header on a static asset. If it is missing or set to no-store, your images and CSS will reload on every visit, which will make your site feel slow no matter how fast the CPU is.

Test DNS propagation and your own resolver

Before you move anything, you need to know how fast the host's nameservers answer and whether they support the record types you use. Run a dig query against their nameserver directly, not against your local resolver. This isolates their DNS infrastructure from your ISP's cache. You are checking for two things: response time and record completeness.

dig @ns1.hostexample.com yourdomain.com A +noall +answer +stats
;; ANSWER SECTION:
yourdomain.com.  300  IN  A  203.0.113.10
;; Query time: 34 msec
;; SERVER: ns1.hostexample.com#53

If the query time is over 100 milliseconds consistently, their nameservers are slow or overloaded. That matters because every new visitor to your site after the cutover will do a fresh lookup, and a slow DNS response adds a full round trip to the page load. Also query for MX, TXT, and CNAME records if you use email or SPF. A host that only gives you an A record and ignores your MX will break mail delivery on day one.

Test the control panel and the API, not just the website

The web server may be fast, but you will live in the control panel or the API for every daily task. So log in and perform the operations you actually do: create a subdomain, add a cron job, change a PHP version, restart a service. Time each action. If a simple toggle takes more than a few seconds to reflect, the panel is writing to a database that is either slow or overloaded. That will become your bottleneck when you need to fix something during an incident.

If the host offers an API, test it with a read-only call first. For example, a typical API endpoint for listing domains would look like this. Use curl with your token and check the response time and the JSON structure. A slow API means their automation layer is fragile, and you will need that automation when you migrate databases or update DNS records in bulk.

curl -sS -H "Authorization: Bearer YOUR_TOKEN" \
     https://api.hostexample.com/v1/domains | head -c 500

Look at the response headers for rate-limit values. If the host imposes aggressive rate limits on API calls, your backup scripts or deployment pipelines will fail intermittently. Also check whether the API returns proper HTTP status codes, 200 for success, 401 for bad auth, 429 for throttling. A host that returns 200 with an error message in the body is going to make automated monitoring painful.

Simulate a traffic spike with a load test

Do not trust a single request. Use a simple tool like ab (ApacheBench) or wrk to send a few hundred concurrent requests to a static file and to a dynamic page. The static file test shows you the raw throughput of their network stack. The dynamic page test shows you how their PHP or database layer behaves under pressure. Keep the test short, under 30 seconds, to avoid triggering their abuse detection.

ab -n 500 -c 50 https://test.example.com/index.php
Requests per second:    142.37 [#/sec] (mean)
Time per request:       351.123 [ms] (mean)
Failed requests:        0

If the failed requests count is above zero, the host is dropping connections under load. If the time per request grows linearly as you increase concurrency, their worker processes are saturated. A good host will show a flat response time curve up to a point, then a graceful decline. A bad host will start returning 502 or 503 errors, which means their proxy or PHP-FPM pool is misconfigured for anything beyond a single visitor.

Test support with a real problem, not a question

Support is a feature, and you test it like one. Open a ticket that describes a specific technical issue, for example, a question about their PHP opcache settings or their firewall rules for a custom port. Note the time to first response and whether the answer is a canned reply or a real explanation. Then ask a follow up question. The first response may be fast, but the second one reveals whether they actually read your ticket or just have a bot that matches keywords.

Also test their knowledge base for the specific things you need. Search for their documentation on cron syntax, on setting up a reverse proxy, and on migrating a database dump. If the documentation is missing those pages or is outdated, you will spend hours on the phone later. A host with thin docs is a host that assumes you will never need help.

What to do next

Run this checklist twice, once on a quiet weekday and once on a weekend evening when their load is highest. Keep the output from every command in a file and compare the numbers. If the host passes all the probes, then set up a temporary subdomain on their server, copy a small portion of your site there, and run the same tests against that subdomain. Only then should you change your DNS. If any test fails, you have saved yourself a migration that would have failed in production. The cost of this checklist is an hour of your time, and the payoff is not having to explain to your users why their site was down for a day.