Moving a domain: DNS, registrar and hosting
Move DNS, transfer the registration and change host without taking the site or email offline.
Saves the combined checklist in this browser with typical answers. You can refine each change afterwards.
Moving a domain's DNS, registrar and hosting at the same time is the most common way to cause an outage. One at a time, in the right order, it's routine.
This plan combines the three, with the checks between them.
Doing these together: read this first
Move DNS first, then transfer the registration
Do one at a time. Move DNS, check the website and email still work for a few days, then start the registrar transfer. Doing both at once makes any problem hard to trace.
Don't move the website and the DNS on the same day
Lower the DNS record lifetimes (TTL) a day ahead, move one thing, confirm it works, then move the other.
Change one way of signing in at a time
More than one of these changes affects how you sign in or recover accounts. On each account, update one sign-in or recovery method, check you can still sign in and receive codes, then update the next. Never remove an old method before the new one works.
The combined checklist
76 tasks from typical answers. Yours will match your answers.
Before the change42
Export every record from the current providerDNS providercritical
Do this: Export each zone as a BIND zone file or through the API. If there's no export, copy every record from the dashboard: type, name, value, priority, weight, port and TTL. Export every zone you're moving, not just the main domain.
Why: Your DNS provider holds the only complete copy of your records, and most providers block zone transfers, so `dig` alone can't list everything.
Check it worked: Record counts per type in the export match what the provider's dashboard shows.
Email records: MX, SPF, DKIM selectors and DMARCDNS providercritical
Do this: Check the export includes MX records with priorities, the SPF record, every `_domainkey` selector (including CNAME-style DKIM from Microsoft 365 or sending services) and `_dmarc`. Copy long TXT values exactly, including split strings.
Why: Email depends on MX records for receiving and on SPF, DKIM and DMARC for being trusted. DKIM keys live at selector names (like `google._domainkey`) that can't be discovered by querying DNS.
Check it worked: For MX, the SPF TXT record and each DKIM selector, compare `dig @old-ns` with `dig @new-ns`; values must match character for character.
Recreate the zone at the new providerDNS providercritical
Do this: Import the zone file where supported, then review every record the import skipped or changed. Remove the old provider's NS and SOA records from the import; the new provider sets its own.
Why: The new provider must answer every query exactly as the old one does before any traffic reaches it.
Check it worked: The new provider's record list matches your export, type by type.
DNSSEC: avoid a validation outageDNS providercritical
Do this: Either turn DNSSEC off first (remove the DS record at the registrar, wait at least a day, switch nameservers, then enable signing at the new provider and add its DS record), or use a multi-signer migration if both providers support it.
Why: With DNSSEC on, the registry's DS record must match keys published by whichever provider answers, and two providers can't simply serve the same signed zone with different keys.
Check it worked: `dig DS example.com +short` matches the new provider's DS values (or is empty while off), and `dig example.com +dnssec` answers without SERVFAIL.
Compare old and new answers before switchingDNS providercritical
Do this: For every name and record type in your export, query the old and new nameservers directly and compare. A short script looping over the export works well for larger zones.
Why: Querying the new nameservers directly shows exactly what the world will see after the switch, while you can still fix it.
Check it worked: `dig @old-ns name TYPE +short` and `dig @new-ns name TYPE +short` return identical answers for every record, apart from intended changes.
Verification records for other servicesDNS providerhigh
Do this: Keep every verification record from the export, including ones you don't recognise, unless you're certain the service is gone. Note which service each one belongs to.
Why: Google, Microsoft, Apple, Meta, Atlassian, certificate authorities and many software tools prove domain ownership with TXT or CNAME records, and some recheck them periodically.
Check it worked: `dig @new-ns example.com TXT +short` returns the same set of TXT records as `dig @old-ns example.com TXT +short`.
Less common records: CAA, SRV, AAAA, wildcards and deep subdomainsDNS providerhigh
Do this: Go through the export by record type and confirm each CAA, SRV, AAAA, wildcard and multi-level subdomain record has been recreated.
Why: These are easy to miss in a manual copy. CAA controls which certificate authorities may issue for you, SRV records run calling and chat services, AAAA records serve IPv6 visitors, and wildcards catch unlisted names.
Check it worked: `dig @new-ns example.com CAA +short` and your SRV lookups (for example `dig @new-ns _sip._tls.example.com SRV +short`) match the old provider's answers.
Check you can change nameservers at the registrarDNS providerhigh
Do this: Sign in to the registrar, find the nameserver setting and confirm two-factor works.
Why: The switch itself happens at the registrar, not at either DNS provider.
Check it worked: You can open the domain's nameserver settings yourself.
Registrar features that rely on its DNSDNS providerhigh
Do this: List forwarding and redirects at the registrar and recreate them with the new provider or another service before switching.
Why: When your registrar hosts DNS, extras like email forwarding, URL forwarding and parked pages work through its nameservers.
Check it worked: Test each forwarded email address and URL after the switch.
Lower TTLs before the switchDNS providerhigh
Do this: At least one full TTL ahead (often a day or two), lower TTLs on important records to around 300 seconds at the current provider, and use similar values at the new one. The NS records at the registry have their own TTL (often two days for .com) that you can't shorten, so plan for both providers to serve identical data for that long.
Why: Resolvers cache answers for each record's TTL (time to live). Lower TTLs mean changes and fixes reach everyone quickly.
Check it worked: `dig example.com A` shows the lowered TTL before switch day.
Apex NS records point at the new providerDNS providerhigh
Do this: After import, check the zone's apex NS records list only the new provider's nameservers (or exactly the set you intend to run).
Why: The zone carries its own NS records, which should match the nameservers you'll set at the registrar.
Check it worked: `dig @new-ns example.com NS +short` returns the same nameservers you'll enter at the registrar.
Terraform, OctoDNS or other infrastructure as codeDNS providerhigh
Do this: Add the new provider in code, import or create the records there, and remove the old provider from state only after the switch. Run plans against both providers until the migration is done.
Why: If DNS is managed in code, the code is the source of truth, and the next apply acts on whichever provider it points at.
Check it worked: A plan against the new provider shows no changes after import.
Subdomains delegated to other nameserversDNS providerhigh
Do this: Recreate each subdomain's NS record set at the new provider, and its DS records if the child zone is signed.
Why: NS records for a subdomain hand it to another DNS service, such as a cloud provider or an internal team.
Check it worked: `dig @new-ns sub.example.com NS +short` returns the delegated nameservers.
Decide proxy settings record by recordDNS providerhigh
Do this: Proxy only the web hostnames you intend to put behind the CDN. Keep mail, SSH, VPN and any hostname that needs the real IP as DNS-only. Set the TLS mode to validate your origin's certificate.
Why: Providers that also act as a CDN may proxy imported web records by default, which changes how traffic reaches your servers.
Check it worked: Load each proxied hostname over HTTPS, and check mail and SSH hostnames resolve to your real IP.
Freeze DNS changes during the migrationDNS providermoderate
Do this: Announce a change freeze to your team, web developer and IT provider. If a change is unavoidable, make it at both providers and note it.
Why: From the export until the old zone is retired, both providers must hold the same data.
Check it worked: Neither provider's change log shows one-sided edits during the window.
Write down a rollback planDNS providermoderate
Do this: Record the old nameservers exactly and agree what would trigger a rollback. Rollback is also slowed by NS caching, so fixing forward at the new provider is often quicker.
Why: If something breaks after the switch, pointing the nameservers back works only while the old zone is intact.
Check it worked: The rollback steps and old nameserver names are written where the team can find them.
Export the full DNS zone from the current registrarDomain registrarcritical
Do this: Export the zone file (BIND format) if the registrar offers it; otherwise copy every record's type, name, value, priority and TTL, including TXT verification records, DKIM, SRV and CAA.
Why: If the current registrar hosts your DNS, the records live in its system, not with the domain.
Check it worked: Compare the export against live answers for key names, for example `dig example.com MX +short` and `dig selector._domainkey.example.com TXT +short`.
Handle DNSSEC before changing DNS or registrarDomain registrarcritical
Do this: If DNS is moving to a new provider, turn DNSSEC off (remove the DS record), wait at least a day, then change nameservers, re-enable DNSSEC at the new provider and add its DS record. If DNS isn't moving, check the DS record is unchanged after the transfer.
Why: With DNSSEC on, the registry publishes a DS record that must match the keys of whoever serves your DNS.
Check it worked: `dig DS example.com +short` matches what your DNS provider shows (or is empty while DNSSEC is intentionally off), and `dig example.com +dnssec` resolves without SERVFAIL.
Move DNS somewhere that won't stop at transfer timeDomain registrarcritical
Do this: Recreate the zone at the new registrar's DNS (if it can host the zone before the transfer) or at an independent DNS provider. Check the new nameservers answer correctly, switch the nameservers at the current registrar, wait a day or two for caches to expire, then start the transfer.
Why: DNS hosted by the current registrar typically stops when the transfer completes, even though the domain itself moved safely.
Check it worked: `dig NS example.com +short` shows the new nameservers from several public resolvers, and the website and email work before you request the authorization code.
Use a registrant email that isn't on the domain you're movingDomain registrarhigh
Do this: Set the registrant email to an address you read, ideally on a different domain from the one you're moving. Make the change a few days before starting, and ask the registrar whether it triggers a transfer lock.
Why: If DNS or email for this domain has a problem mid-transfer, approval and verification emails sent to an address on the same domain can't reach you.
Check it worked: Send a test message to that address and check the registrar's contact page shows it.
Check the domain is eligible to transfer nowDomain registrarhigh
Do this: Look up the creation date, last update and status codes. Check the domain isn't expired, in redemption or under a dispute, and that the registrant wasn't changed recently.
Why: For most generic domains (like .com, .net and .org), ICANN's Transfer Policy lets registrars refuse a transfer soon after registration or a previous transfer (currently within 60 days), and requires a lock after certain registrant changes. ICANN is updating this policy, so check your registrar's current rules.
Check it worked: ICANN Lookup shows the dates and status codes, with no serverTransferProhibited, redemptionPeriod or pendingDelete status.
List everything the current registrar providesDomain registrarhigh
Do this: Go through the domain's settings and the billing page at the current registrar. Note DNS, forwarding, mailboxes, hosting, certificates and privacy, and decide where each will live afterwards.
Why: Registrars often bundle DNS, email or URL forwarding, mailboxes, site builders, certificates and privacy services with the registration.
Check it worked: Each service on the list has a new home or a deliberate decision to drop it.
Email forwarding at the current registrarDomain registrarhigh
Do this: Recreate forwarding at the new registrar or move to a proper email service, update MX records, and test before changing nameservers.
Why: Registrar email forwarding runs on the registrar's DNS and mail servers.
Check it worked: From an outside account, send a message to each forwarded address and confirm it arrives.
Stagger transfers and track each domainDomain registrarmoderate
Do this: Start with a low-risk domain to learn the process, then move the rest in batches. Track each domain's expiry, DNS host, code request date and transfer status in a sheet.
Why: Moving several domains at once multiplies approval emails, codes and expiry dates to keep track of.
Check it worked: Every domain on the sheet shows as completed at the new registrar.
Pick a quiet week and compare termsDomain registrarmoderate
Do this: Avoid launches, campaigns and holidays. Check the new registrar's renewal price (not just the first-year price), whether DNS, privacy and two-factor sign-in are included, and whether it supports every domain ending you own.
Why: A transfer needs a few days of attention to emails and settings, and registrars differ on renewal prices, included services and support.
Check it worked: You have a target week and the new registrar's renewal price in writing.
Write down the current settingsDomain registrarmoderate
Do this: Save screenshots or exports of the nameservers, contacts, DS records, glue records and renewal settings with your tracking sheet.
Why: A record of nameservers, contacts, DNSSEC (DS) records and custom nameserver (glue) entries lets you rebuild or roll back if anything changes during the transfer.
Check it worked: Run `dig NS example.com +short` and `dig DS example.com +short` and save the output with the date.
URL forwarding and parked pagesDomain registrarmoderate
Do this: Recreate each redirect at the new registrar, your DNS provider or your web host, with HTTPS if people use https:// links.
Why: Web or URL forwarding is served by the registrar's own servers through its DNS.
Check it worked: `curl -sI http://example.com` and `curl -sI https://example.com` return the expected 301 and Location.
WHOIS privacy and transfer emailsDomain registrarmoderate
Do this: Before the transfer, make sure registrar emails still reach you (some registrars ask you to turn privacy off first). After it completes, turn privacy or redaction on at the new registrar.
Why: Privacy services hide your contact details in public records and may relay registrar emails through a forwarding address.
Check it worked: After the transfer, check the domain in ICANN Lookup and confirm your personal details aren't shown.
Take full backups you controlWeb hostcritical
Do this: Download a full copy of the site files (including hidden files like .htaccess and the .well-known folder) and a database dump, and store them somewhere outside both hosts.
Why: Host-managed backups usually live inside the account you're about to close.
Check it worked: Open the archive, check its size looks right, and restore the database dump into a scratch database to prove it's complete.
Mailboxes hosted by the old web hostWeb hostcritical
Do this: Decide where email will live (the new host or a dedicated email provider), create the mailboxes, copy existing mail over IMAP, then update MX, SPF and DKIM records. Treat it as its own move, separate from the website switch.
Why: With cPanel-style hosting, email lives on the same account as the website, and the domain's MX records point at the old server.
Check it worked: `dig example.com MX +short` points at the new mail service, old messages are visible there, and a test message from outside arrives.
DNS zone hosted by the old web hostWeb hostcritical
Do this: Export the zone and recreate it at the new host's DNS or an independent DNS provider, compare answers, then change nameservers at the registrar well before cancelling.
Why: If the domain's nameservers point at the old host, every record lives in that account.
Check it worked: `dig NS example.com +short` shows the new nameservers, and key records match the old answers.
Environment variables, secrets and config filesWeb hostcritical
Do this: Copy config files (for example wp-config.php or .env) and environment variables securely, then update the database host, name, user and password for the new host. Keep secrets out of version control along the way.
Why: Database credentials, API keys, salts and service URLs live in config files or environment variables that aren't part of the site content.
Check it worked: On the new host, the site connects to its database and API-backed features (payments, maps, email) work in testing.
Migrate the databaseWeb hostcritical
Do this: Export with mysqldump or pg_dump and import on the new host using the same character set (utf8mb4 for most modern MySQL sites), on a compatible database version. Don't change the site URL during the import unless you're also changing domain.
Why: The database holds your pages, orders, users and settings.
Check it worked: Row counts on key tables (users, orders, posts) match between the old and new databases.
Services that allowlist your server's IP addressWeb hostcritical
Do this: Find the new host's outbound IP address, add it to every allowlist before the switch, and remove the old IP after the move.
Why: Payment gateways, partner APIs, remote databases and SMTP relays often accept connections only from known IP addresses.
Check it worked: Make a real test call to each service from the new server, for example a sandbox payment.
Test on the new host before switching DNSWeb hostcritical
Do this: Add a hosts-file entry mapping your domain to the new server's IP (or use `curl --resolve`) and test real pages, sign-in, forms and checkout. Avoid rewriting a CMS's site URL to a temporary address just to test; switching it back is a common source of broken links.
Why: You can see the site on the new host with its real domain by overriding DNS on your own computer only.
Check it worked: `curl -kI --resolve example.com:443:NEW_IP https://example.com/` returns 200 (drop -k once the real certificate is in place), and key journeys work through the hosts-file override.
Inventory what the current host doesWeb hosthigh
Do this: In the control panel or on the server, list every site, subdomain, database, cron job, mailbox and forwarder, DNS zone, redirect rule, certificate and add-on. Note the PHP or runtime version, disk usage and the server's outbound IP address.
Why: Hosting accounts quietly accumulate jobs: extra sites, subdomains, databases, cron jobs, mailboxes, DNS zones, redirects and certificates.
Check it worked: Every item in the control panel appears on your list with a plan for where it goes.
New hosting account: access, billing and contactsWeb hosthigh
Do this: Turn on two-factor sign-in, give each person their own login, add a payment card that won't expire soon, and set billing and technical contacts to addresses someone reads.
Why: The new hosting account now controls your website, so its sign-in, billing and alert contacts matter from day one.
Check it worked: Review the account's users, payment method and contact settings.
Match runtime versions and server settingsWeb hosthigh
Do this: Match the runtime version (or test the upgrade deliberately), install required extensions, and copy memory, upload and timeout limits. Translate .htaccess rules if the new web server doesn't read them.
Why: Sites depend on a specific PHP, Node or Python version, extensions, upload and memory limits, and web-server rewrite rules.
Check it worked: Compare the runtime version and extensions on both hosts, and test a few rewritten URLs on the new one.
Copy files and mediaWeb hosthigh
Do this: Copy files with rsync or SFTP (keeping timestamps), then set ownership and permissions for the new host's web-server user. Re-sync just before the switch if content changes daily.
Why: Uploads, themes, plugins and generated files need to arrive intact and with the right permissions.
Check it worked: File counts and total size match between hosts, and a test upload works on the new host.
Scheduled tasks (cron jobs)Web hosthigh
Do this: Copy every cron entry with its schedule and user, adjust paths for the new host, and disable the old host's jobs at the switch. For WordPress, decide whether WP-Cron or a real system cron runs scheduled tasks.
Why: Backups, emails, imports and clean-up tasks run on schedules set in the control panel or server, not in your site files.
Check it worked: Each job's log on the new host shows a successful run, and the old host's cron list is empty after the switch.
Forms and outgoing email from the siteWeb hosthigh
Do this: Send site email through authenticated SMTP or a transactional email service rather than the server's mail function, and make sure SPF and DKIM cover it.
Why: Contact forms and site notifications often use the server's built-in mail function, which some hosts restrict or block.
Check it worked: Submit each form on the new host and check the email arrives with SPF and DKIM passing.
Lower DNS TTL before the switchWeb hosthigh
Do this: A day or two ahead, lower the TTL on the site's A, AAAA and CNAME records to about 300 seconds.
Why: Cached DNS answers decide how long visitors keep reaching the old host after you switch.
Check it worked: `dig example.com A` shows the lower TTL before the switch.
During the change9
Change the nameservers at the registrarDNS providercritical
Do this: Replace all nameservers at the registrar with exactly the ones the new provider assigned, character for character. Don't mix old and new providers unless they're deliberately set up to serve the same zone.
Why: This is the moment resolvers start asking the new provider for your records.
Check it worked: `dig NS example.com +short` and `dig +trace example.com` show only the new nameservers at the registry.
Certificates renewed with DNS validationDNS providercritical
Do this: Update certbot DNS plugins, cert-manager issuers, Caddy, Traefik or acme.sh to the new provider with a token scoped to the zones they need, or point `_acme-challenge` names at a delegated validation zone.
Why: DNS-01 validation (used for wildcard certificates and internal hosts) creates TXT records through the DNS provider's API at each renewal.
Check it worked: Run a dry-run or staging renewal, for example `certbot renew --dry-run`, and check cert-manager certificates report Ready.
Watch the overlap periodDNS providerhigh
Do this: Keep both providers serving identical data. Query several public resolvers over the first day or two and watch website, email and app errors.
Why: For up to the NS record's TTL (often a day or two), some resolvers still query the old provider.
Check it worked: `dig @1.1.1.1 example.com NS +short`, `@8.8.8.8` and `@9.9.9.9` all return the new nameservers.
Unlock the domain and get the authorization codeDomain registrarhigh
Do this: Turn off the registrar (transfer) lock and request the authorization code when you're ready to use it, because codes can expire. For generic domains, ICANN requires registrars to provide the code within five calendar days of your request. Store it like a password.
Why: The transfer needs the domain unlocked at the current registrar and an authorization (auth or EPP) code that proves you're the holder.
Check it worked: ICANN Lookup no longer shows clientTransferProhibited, and you have the code.
Start the transfer and approve the emailsDomain registrarhigh
Do this: Order the transfer at the new registrar, enter the code and pay. For most generic domains the transfer typically adds a year to your current expiry. Watch both registrars' emails, and approve the transfer at the current registrar if it lets you, which usually speeds things up.
Why: The new registrar submits the transfer with your code, and confirmation emails may come from either registrar.
Check it worked: The new registrar shows the transfer as pending, then completed.
Track the transfer until it completesDomain registrarhigh
Do this: Check the status daily at the new registrar. If it's rejected, read the reason, fix it and resubmit. For most generic domains, expect it to finish within about a week.
Why: Transfers can be rejected (wrong code, lock, recent change) or sit pending while waiting for an approval.
Check it worked: ICANN Lookup lists the new registrar as the domain's registrar.
Plan a final database sync at the switchWeb hostcritical
Do this: Rehearse the migration first. At the switch, put the old site in maintenance mode, export and import the database again, then change DNS. Afterwards, check the old host's logs for anything that still arrived and re-enter it.
Why: If the site keeps taking orders or sign-ups, the database keeps changing after your first copy.
Check it worked: The latest order or sign-up timestamp on the old host matches the new host.
SSL certificate on the new hostWeb hostcritical
Do this: Issue the certificate before the switch using DNS validation, copy the existing certificate and key to the new host temporarily, or be ready to issue it immediately after the DNS change. Cover both the root domain and www.
Why: Certificates validated over HTTP can only be issued once the domain points at the new host, which leaves a gap at the switch.
Check it worked: `curl -vI https://example.com` and `curl -vI https://www.example.com` show a valid certificate served by the new host.
Point DNS at the new hostWeb hostcritical
Do this: Update the root, www and any site subdomains to the new host's addresses. Remove AAAA records for the old host if the new one doesn't use IPv6, or replace them with its IPv6 address.
Why: Changing the A, AAAA or CNAME records is what moves visitors to the new host.
Check it worked: `dig +short example.com A`, `dig +short example.com AAAA` and `dig +short www.example.com` return the new host's addresses from several public resolvers.
Immediately after11
Secure the new DNS provider accountDNS providerhigh
Do this: Turn on two-factor for everyone, use individual logins, give API tokens the narrowest scope (one zone, edit records only), and set billing and security contacts.
Why: Control of DNS means control of your website, your email routing and certificate issuance for your domain.
Check it worked: Review the account's members and API tokens; each has a named owner and a limited scope.
DNS and uptime monitoringDNS providermoderate
Do this: Point uptime checks at your key hostnames, add DNS checks for critical records (MX, apex and www), and alert on certificate expiry.
Why: DNS problems often show up as intermittent failures from some networks only.
Check it worked: Monitors are green and a test alert reaches the right person.
Secure the new registrar accountDomain registrarcritical
Do this: Use a unique password and an authenticator app, passkey or security key rather than text messages alone. Set the account recovery email to an address on a different domain, and give other people their own logins instead of sharing one.
Why: Whoever controls the registrar account controls your website and email: they can change nameservers or transfer the domain away.
Check it worked: Sign out and back in to confirm two-factor is required, and review the account's user list.
Turn the transfer lock back onDomain registrarhigh
Do this: Re-enable the registrar lock at the new registrar. For high-value domains, ask whether a registry lock is available for your domain ending.
Why: The lock you removed for the transfer is what blocks unauthorised transfers away.
Check it worked: ICANN Lookup shows clientTransferProhibited on the domain again.
Turn on auto-renew and check the payment methodDomain registrarhigh
Do this: Turn on auto-renew, add a payment card that won't expire soon (and a backup card if offered), and check the new expiry date.
Why: Renewal settings and saved cards don't come with the domain to the new registrar.
Check it worked: The domain shows auto-renew on and the expected expiry date.
New registrar: check registrant, admin and billing contactsDomain registrarhigh
Do this: Confirm the registrant name, organisation and email came across correctly, and set billing and technical contacts to addresses that someone reads.
Why: Contact details are copied from the registry, but billing and technical contacts at the new registrar start empty or default to the account owner.
Check it worked: The new registrar's contact page shows the right details for each contact type.
Answer the registrant verification emailDomain registrarhigh
Do this: Watch the registrant email for a verification message from the new registrar after the transfer and respond promptly.
Why: ICANN requires registrars to verify registrant contact details, and a transfer or contact change can trigger a new verification email.
Check it worked: The new registrar shows the registrant contact as verified.
Inbound webhooks during the switchWeb hosthigh
Do this: Copy webhook signing secrets to the new host, watch each provider's delivery log after the switch, and replay any events that landed on the old host.
Why: Payment and service webhooks follow DNS, so during the overlap some may still reach the old host.
Check it worked: Each provider's webhook log shows recent 2xx deliveries handled by the new host.
Backups at the new hostWeb hosthigh
Do this: Set up automated daily backups of files and database, keep a copy off the host, and test a restore.
Why: Your old backup routine stayed with the old host.
Check it worked: Restore a recent backup to a staging site or scratch database.
Search engines during the moveWeb hostmoderate
Do this: Check robots.txt and the CMS's search-visibility setting on the new host, keep the old host running until its traffic drops to zero, and watch Search Console for crawl errors.
Why: Google's guidance for moving hosts without changing URLs is to keep the old host running until its traffic stops, and to expect a temporary dip in crawling while Google adjusts to the new server.
Check it worked: Search Console's crawl stats show successful requests after the switch, and robots.txt allows crawling.
Uptime monitoring and alertsWeb hostmoderate
Do this: Point uptime checks at the new host, add certificate-expiry alerts, and watch the error log daily for the first week.
Why: New servers have new failure modes, and the first days are when problems surface.
Check it worked: Monitors are green and a test alert reaches the right person.
Verify5
Check email deliverability after the moveDNS providercritical
Do this: Send from your domain to Gmail and Outlook.com accounts and back. Check SPF stays within its 10-DNS-lookup limit, every DKIM selector resolves, and DMARC reports show passing mail.
Why: Email failures don't announce themselves; you only notice the replies that never come.
Check it worked: Gmail's Show original reports SPF, DKIM and DMARC as PASS, and a message from outside reaches your inbox.
Test every hostname and certificateDNS providerhigh
Do this: Load each hostname from your export over HTTPS, check its certificate, and confirm custom domains still show as verified in each provider's dashboard.
Why: Websites, APIs, subdomains and custom domains at software providers each depend on their own records.
Check it worked: Each hostname returns the expected response with a valid certificate.
Check DNS and the website after the transferDomain registrarcritical
Do this: Check the nameservers and DS record match your notes, and load the website and any subdomains over HTTPS.
Why: The transfer should only change who you pay. You want proof that nameservers, DNSSEC and the site are exactly as before.
Check it worked: `dig NS example.com +short` and `dig DS example.com +short` match your saved output, and the site loads with a valid certificate.
Send and receive test emailDomain registrarhigh
Do this: Send from an outside account to a domain address and back, and check the received message's authentication results.
Why: Email depends on MX, SPF and DKIM records that a DNS mistake can quietly break.
Check it worked: Both messages arrive, and Gmail's Show original reports SPF, DKIM and DMARC as PASS.
Test everything on the live domainWeb hostcritical
Do this: Once DNS has moved, check key pages, forms, sign-in, checkout, admin, redirects and email notifications from a normal browser and a phone on mobile data.
Why: Testing through a hosts file isn't quite the same as real visitors on real DNS.
Check it worked: Every key journey works, and the old host's access log shows traffic falling away.
Clean up6
Retire the old zone after a safe overlapDNS providerhigh
Do this: Leave the old zone unchanged for at least a week after the switch (longer if it still gets queries), then delete it, revoke its API tokens and cancel the plan if nothing else uses it.
Why: Some resolvers and long-running clients keep asking the old nameservers for a while after the switch.
Check it worked: The old provider's query statistics, if available, have dropped to near zero before you delete.
Remove dangling delegations and recordsDNS providerhigh
Do this: After retiring old zones, check that no NS or CNAME record in your zone still points at a provider zone or resource you've removed.
Why: A delegation or CNAME that points at a zone or resource you've deleted can sometimes be claimed by someone else at that provider.
Check it worked: Every NS and CNAME target in your zone resolves to something you control.
Raise TTLs again once stableDNS providerlow
Do this: After a week or so without issues, raise TTLs on stable records (for example to an hour or more).
Why: Very low TTLs increase query volume and make you more sensitive to brief provider problems.
Check it worked: `dig example.com A` shows the raised TTL.
Close out the old registrar accountDomain registrarmoderate
Do this: Once every domain has moved and add-ons are replaced, cancel remaining services, remove saved payment cards and download invoices for your records. Close the account if nothing else is in it.
Why: Leftover services, saved cards and auto-renewals at the old registrar can keep charging or hold data.
Check it worked: The old account shows no active domains or services and no stored payment method.
Cancel the old host only after an overlapWeb hosthigh
Do this: Wait until DNS has fully moved, the old host's access logs show no real visitors for several days, email and DNS have moved, and you've downloaded a final backup. Then cancel, noting the host's notice period.
Why: Cancelling is the step you can't undo, and it often deletes everything in the account.
Check it worked: The old host's access log shows only bots or nothing for several days before you cancel.
Remove your data from the old hostWeb hostmoderate
Do this: Before closing the account, delete databases, backups and files containing customer data, or confirm how and when the host deletes them (verify their current policy).
Why: Databases and backups at the old host contain customer data.
Check it worked: The old account shows no databases or backups before closure.
Later3
Set your own renewal remindersDomain registrarmoderate
Do this: Add a calendar reminder a month before expiry that doesn't depend on the registrar, and check the new expiry date reflects any year added by the transfer.
Why: Registrar reminder emails go to one address and are easy to miss or lose to a spam filter.
Check it worked: Your calendar shows the reminder and the date matches ICANN Lookup.
Update your records of where the domain livesDomain registrarlow
Do this: Update your password manager entry, IT documentation and renewal calendar with the new registrar, account owner and expiry date, and tell your web developer or IT provider.
Why: The next person who needs the registrar, including you a year from now, needs to know where to look.
Check it worked: Someone else on the team can find the registrar login and expiry date from your documentation.
Update documentation and contactsWeb hostlow
Do this: Update your password manager, runbooks and developer notes with the new host, server details, backup location and support contacts.
Why: The next person to fix the site needs to know where it lives and how it's deployed.
Check it worked: Someone else can find the hosting login and backup location from your notes.