How to migrate a single subdomain without touching the rest of the site

Migrating a single subdomain, for example moving shop.example.com to a new host while example.com and www.example.com stay where they are, is a smaller job than a full site move, but it needs its own plan. The shared risk is DNS: because a subdomain is an independent DNS name, you can move it without touching the rest of the zone.

Plan the boundaries

• Confirm which records belong to the subdomain. A subdomain is handled by its own A or CNAME record plus any service records underneath it (MX for mail on that name, TXT for verification, or AAAA for IPv6). Export these before you touch anything.
• Decide between A and CNAME. If the new host gives you an IP address, use an A record (or AAAA). If it gives you a hostname such as loadbalancer.provider.example, use a CNAME. Many modern hosts provide a "value" you can point at.
• Check wildcard coverage. If a wildcard record like *.example.com already resolves shop.example.com, an explicit record for that subdomain takes precedence, but document it so you know why the wildcard stops matching.

Stage and cut over

1. Build the new copy first. Upload the subdomain's files and database to the destination host and get it running on a temporary URL or an IP-based address before any DNS change.
2. Test over the destination's direct address. Bypass DNS by editing your local hosts file to point shop.example.com at the new server, and confirm pages, images, and any forms work from that location. Check that the SSL certificate covers the subdomain (a wildcard or multi-domain certificate usually does).
3. Lower the DNS TTL before the move. Drop the subdomain record's time to live to something like 300 seconds a day or two ahead so cached answers expire quickly once you point it elsewhere.
4. Point the record at the new host. Update only the subdomain's record. You do not need to touch the parent domain or any unrelated records.
5. Reissue SSL if needed. The destination host must be able to validate control of the subdomain. For Let's Encrypt this is normally a DNS-01 or HTTP-01 challenge run automatically by the host.

Verify after switch

• Purge your own caches. Open the subdomain in a fresh or incognito window and force the resolver to see the new answer with Resolve-DnsName shop.example.com on Windows or dig shop.example.com on macOS and Linux.
• Check the certificate resolves. Visit the subdomain with https:// and confirm the padlock is valid and the certificate chain matches the new host, not the old one.
• Test deep pages, not just the home page. A subdomain with its own app (shop, support portal, member area) often has pages that depend on environment-specific URLs, so verify a few real routes.
• Reassure HTTPS rather than HTTP. Confirm there is no redirect loop between http:// and https:// on the new host, since the two may be configured independently of the parent site.
• Watch mail and verification records. If the subdomain previously sent mail or ran analytics domain verification, confirm the relevant MX, TXT, or SPF records are present on the destination or restored.

Prevention

Keep a small runbook for the subdomain: the record names, their TTL, the certificate type, and the hosting provider credentials. That makes the next migration, or a rollback, a few minutes rather than an investigation.

When to involve a professional

Involve your hosting provider if your control panel does not expose an A or CNAME editor for subdomains, or if the subdomain serves a payment or member area where an interruption would be costly. A short TTL and a tested rollback plan remove most of the risk on your own.