How to Move Hosts When You Cannot Change the DNS Yet

You can move hosting without changing DNS by building and testing the entire site on the new server first, then flipping traffic with a single change at the old provider, and keeping the old server alive as a rollback target until you are satisfied. Because the domain's nameservers still point at the old provider, the cutover happens in that provider's DNS zone, not at the registrar, which makes it fast and easy to reverse.

The key mental model is that a domain name does not belong to a host. It belongs to whoever controls the authoritative nameservers for the zone. Until you delegate the domain elsewhere, the old provider is still the authority, and that is an advantage: you can aim records at a new origin without touching registration at all.

Why the old DNS zone is your control panel for the move

When a browser resolves your domain, it asks a resolver, which asks the authoritative nameserver for the zone. That server answers with the record set you have configured. If you leave the nameservers alone and only edit the records, the resolver chain is unchanged and there is nothing to propagate except the record values themselves.

The record that matters most is the one pointing at your web origin. Usually that is an A record for the apex and a CNAME for www, though many setups use a single A record for both, or an alias record type that the provider resolves internally. Before you change anything, record what exists. Run a query against the authoritative server directly so you see the real zone rather than a cached answer:

dig +short NS example.com
dig +short A example.com @ns1.oldprovider.example
dig +short CNAME www.example.com @ns1.oldprovider.example

The first line tells you which servers are authoritative. The second and third show what they currently answer. Save that output. It is your rollback reference, and it is the only thing you need to restore service if the new origin misbehaves.

Lower the record's time to live before the cutover if the provider lets you. A shorter TTL means resolvers hold the old answer for less time, so a mistake corrects itself faster. Do this well ahead of the switch, because the old, longer TTL has to expire before the shorter one takes effect.

Build and verify the new origin before any traffic moves

On the new server, install the stack, copy the files, import the database, and configure the web server to answer for your hostname. Nothing about this step is visible to the public, because no DNS record points there yet. You reach the new origin by IP address or by a temporary hostname.

If your site depends on the Host header for virtual host selection, the site will not render correctly when you request it by IP. Force the header with curl so the new server believes it is serving the real domain:

curl -sS -H 'Host: example.com' http://203.0.113.10/ -o /dev/null -w '%{http_code}\n'
curl -sSI -H 'Host: example.com' https://203.0.113.10/

You want a normal status code and the expected headers. The -I form shows the response headers only, which is where you check for redirects, caching directives and the certificate being served. If TLS is terminating on the new box, the certificate must already cover your hostname, or the handshake will fail before any of this is meaningful.

Some applications hardcode the site URL in a configuration file or database row. Grep for the old hostname and fix every occurrence before cutover, or the new server will emit redirects back to the old one. A quick check:

grep -rn 'example.com' /etc/nginx /var/www/example.com/config 2>/dev/null

Then test the application itself, not just the web server. Log in, submit a form, upload a file, run a checkout if you have one. A page that returns 200 can still be broken behind the login.

Cutting over without changing DNS: the record swap

The cutover is the moment you edit the A and CNAME records in the old provider's zone to point at the new origin. Do it during a quiet period, and do it as one edit rather than a series of them. Keep the TTL low for a day or so afterward, then raise it back.

Immediately after saving, query the authoritative server again to confirm the new answer is live in the zone, then query a public resolver to watch the change spread:

dig +short A example.com @ns1.oldprovider.example
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8

The first line should show the new address at once. The other two may lag while their caches expire. That gap is normal and is exactly why you lowered the TTL earlier.

Watch the old server's access logs during the transition. Requests will taper off as caches expire. If the new server's logs show errors at the same time, you still have the old origin running and the old record values saved, so you can revert the zone edit in seconds. This is the whole reason the move is safe: DNS is the switch, and switches can be flipped back.

Things that quietly break during a cutover

Mail is the most common casualty. If MX records point somewhere in the old zone and you move the whole zone later, or if you change nameservers without recreating the mail records, mail stops. Leave mail where it is for now, or recreate the records exactly before you delegate.

Subdomains are the second. A record for api or staging may point at the old infrastructure and get forgotten. Enumerate the zone before you touch anything and account for every name.

Certificates are the third. If the new origin serves TLS, the certificate must be valid for the hostname and the chain must be complete. Test with a client that verifies, not one that skips verification.

Sessions and caches are the fourth. If your application stores sessions on the old server, users logged in during the transition may be dropped. Draining the old origin, or accepting a brief re-login, is usually the pragmatic answer.

What to do next when you cannot change DNS yet

Start by dumping the current zone and saving it somewhere outside the old provider's control, because that file is both your migration checklist and your rollback plan. Build the new origin, force the Host header until the site behaves identically, then lower the TTL and wait for it to expire. When you are ready, make the record swap, watch both sets of logs, and keep the old server running until the new one has carried a full business cycle without surprises. Only after that should you think about moving the nameservers themselves, and by then it is a separate, much less urgent task.