Website Migration Tracker: How to Tell When a Site Changed Hosting

Websites move hosts far more often than their owners advertise. An agency inherits a client, a plan gets outgrown, an outage triggers a decision that was already overdue. Every one of those moves leaves fingerprints — in DNS, in the IP address, in the ASN, in HTTP headers. The catch is that you almost always observe the change after it happened, and in some setups you never observe it at all. This guide covers which signals actually shift, how to read them by hand, what our migration tracker logs, and where the method quietly fails.

Why migrations are worth tracking

For an agency or a hosting vendor, a migration is a timing signal. A prospect that just moved from shared hosting to a managed platform has budget and an active project; one that moved last week is not worth pitching for another two years. For anyone auditing their own estate, a migration you did not authorise is a security event.

There is also a diagnostic use. When a site's performance or deliverability changes for no apparent reason, "the host changed three weeks ago" is often the missing variable — and nobody logged it, because the person who did the migration was a contractor who has since moved on.

The five signals that change

A hosting move disturbs a predictable set of observables. Not all of them move together, and which ones move tells you what kind of migration it was.

Nameservers. The NS records for the domain. Changing host often means changing DNS provider, and this is the change with the longest visible tail — more on that below.

IP address. The A/AAAA records. The most direct signal, and the noisiest: large platforms rotate addresses within their own estate constantly, which is not a migration.

ASN. The network that announces the new IP. This is the signal that separates a real migration from address churn: if the IP changed but the ASN did not, the site is still on the same network. A change from, say, a shared-hosting operator's ASN to a cloud provider's ASN is a genuine move. How to read an ASN result — and where it misleads — is covered in what an ASN is and why it helps identify hosting.

HTTP response headers. Server, X-Powered-By, cookie names, cache headers and any platform-specific header. A stack change usually rewrites several at once. A move from an nginx/PHP shared host to a managed WordPress platform, for example, typically swaps the Server value and adds a vendor cache header that was not there before.

CDN and TLS. A new CDN in front, a certificate issued by a different CA, or a CNAME that now points at a provider-controlled hostname. The header-level fingerprints for each major CDN are listed in CDN detection for Cloudflare, CloudFront, Fastly and Akamai.

Checking the signals by hand

You can take a full snapshot of a domain in four commands:

$ dig +short NS example.com
$ dig +short A example.com
$ whois -h whois.cymru.com " -v <ip>"
$ curl -sI https://example.com

The ASN query returns the network and the announced prefix, which is what you compare across snapshots:

AS    | IP             | BGP Prefix      | CC | Registry | AS Name
24940 | 213.133.116.44 | 213.133.96.0/19 | DE | ripencc  | HETZNER-AS - Hetzner Online GmbH, DE

Store those four outputs with a timestamp and repeat weekly. A migration is any snapshot where the ASN or the nameserver set differs from the previous one. That is the entire algorithm — the difficulty is not the detection logic, it is having a previous snapshot at all. There is no public, complete history of what a domain's DNS looked like last year; historical DNS datasets are built from passive observation and are sampled, not exhaustive, so gaps are normal.

Common patterns and what they look like

The last two rows are the interesting ones. A cloud migration where the customer kept their DNS provider shows up only in the ASN — no nameserver change, no header change. And a plan upgrade at the same provider changes the IP without being a migration at all, which is the most common false positive in any naive IP-diffing tracker.

What hostingchecker.org tracks

Every check we run is stored as a record: domain, timestamp, resolved IP, derived hosting provider slug, CDN, CMS, country. The migration tracker walks those records per domain in chronological order and logs a row whenever consecutive checks resolve to a different hosting provider. Each row is one transition: the domain, the previous provider, the new provider, and the date the change was detected.

Two deliberate design choices are worth stating plainly. First, the comparison is on the normalised provider slug, not on the raw IP — so an address change inside the same provider's network does not produce a row. Second, the date shown is the detection date, not the migration date. We can only know that the change happened somewhere between two probes, and the gap between them depends entirely on how often that domain was checked.

The same records feed the monthly insights reports, which is where the aggregate direction of travel becomes visible rather than individual moves.

Why you see migrations late — or never

This is the part most migration trackers do not tell you.

Observation gaps. A tracker sees only what it probes. If a domain is checked once in May and once in July, a June migration is dated July. Any tracker built on user-triggered lookups, ours included, has irregular sampling by construction — popular domains are effectively monitored, obscure ones are sampled once a quarter.

DNS caching and TTL. Even a perfectly timed probe can read stale data. Record TTLs on apex A records are commonly 60–3600 seconds, which is fine. Delegation is not: the NS records for a .com domain are served by the gTLD servers with a TTL of 172800 seconds — two full days. A resolver that cached the old delegation will keep sending you to the old DNS provider for up to 48 hours after the registrar change went through. Negative caching and resolvers that clamp or extend TTLs add more slop. In practice, treat any detection within about 72 hours of a nameserver change as approximate.

Anycast and geo-DNS. Large providers hand out different addresses to different resolvers. Two probes from different vantage points can disagree without anything having changed. A single differing observation is not a migration; a sustained change across subsequent checks is.

A CDN can hide the move entirely. This is the hard limit. If a site sits behind Cloudflare or another full proxy, the IP you resolve belongs to the CDN edge and stays constant no matter what happens behind it. The origin can move from a shared host to a cloud VM and every externally observable signal — IP, ASN, Server header, certificate — remains identical. Migration tracking, in other words, works well for sites with an exposed origin and works badly for the growing share of sites that do not have one. The mechanics of that blind spot are covered in why a hosting checker can be wrong.

The mirror-image false positive: adding a CDN registers as a hosting migration in any IP-based tracker, because the resolved network genuinely did change. The site did not move. Only the front door did.

Checklist: confirming a migration

• Compare ASN, not just IP. Same ASN, new IP, is almost never a migration.
• Check whether a CDN appeared. If it did, the "migration" may be a proxy change, not a host change.
• Look at nameservers separately — a DNS provider change and a hosting change are different events that often, but not always, coincide.
• Wait for a second confirming observation before recording the change; one differing lookup can be geo-DNS.
• Allow up to 48 hours of uncertainty on the date for anything involving a delegation change.
• Record what you saw, not what you inferred: store the raw IP, ASN and headers alongside the verdict, so a wrong conclusion can be re-derived later.

Summary

Hosting migrations are detectable, but only through repeated observation and only when the origin is visible. The reliable signal is a change in ASN corroborated by nameservers and headers; the unreliable ones are bare IP changes and anything read through a CDN. Any date you get is a detection date with a caching-shaped error bar attached, and as proxy adoption keeps rising, the share of sites whose moves are simply invisible from outside will keep rising with it. A tracker that admits that is more useful than one that reports a confident timestamp it cannot justify.

Want a dated record instead of a guess? Run a domain through our checker — each check is stored, so the next one can be compared against it. Track a domain.