A redesign involves three assets that are often spoken about as if they were one: the domain registration, the DNS zone, and the website host. The registration establishes the business or person entitled to use the domain. DNS tells browsers, mail systems, and other services where to go. Hosting stores and serves the new site. A normal redesign can replace the host while leaving registration and most DNS records exactly where they are. That separation is the key to a calm launch.

The path a visitor followsA launch usually changes the destination at the end of the chain, not ownership at the beginning.
01Domain registrarHolds the registration account and renewal settings
02Authoritative DNSPublishes records for web, mail, and verification
03New web hostReceives requests after the relevant record is changed
04VisitorMay use a resolver that has a cached earlier answer

Know which account controls each layer

Before anyone opens a DNS screen, document the registrar, the DNS provider, the old host, the new host, the email provider, and the people who can sign in. These may be five different companies. The safest arrangement is for the business to be the registrant, use a role-based business email for recovery, enable available account security, and grant vendors the narrow access they need. ICANN describes the registrant as the holder of rights to the registered name; that is a stronger position than discovering that a former freelancer opened the account in a personal name.

What usually changes at launch

ItemPurposeTypical redesign action
Domain registrationOwnership, renewal, contact detailsLeave in place; verify access and renewal
NameserversChoose the provider publishing the DNS zoneLeave in place unless the DNS provider is intentionally changing
A, AAAA, or CNAME recordsDirect the website hostnameChange only the hostnames covered by the launch plan
MX recordsDirect incoming emailPreserve unless the email provider is also changing
TXT recordsVerification, SPF, DKIM, and other policiesInventory and preserve unless an owner approves a specific change
TLS certificateAllows secure HTTPS connectionsConfirm the new host can issue and serve it for every live hostname

Choose between changing a web record and changing nameservers

Change web records onlyChange nameservers
ScopeMoves selected web hostnamesDelegates the entire DNS zone to another provider
Email riskLow when MX and mail TXT records are untouchedHigher unless every required record is recreated correctly
Best fitA redesign with the same registrar and DNS providerAn intentional DNS-platform migration with a complete zone export and audit
RollbackRestore the previous web destinationRestore delegation or repair the replacement zone; more moving parts

Many redesigns need only a change to an A, AAAA, or CNAME record for the root domain or `www`. The exact record depends on the new host's official instructions. Changing nameservers is a broader move: it tells the internet that a different provider is now authoritative for the whole zone. That can be appropriate, but it should be treated as a separate migration. If the project includes both changes, test the copied zone and assign an owner for mail, web, and each important subdomain.

Prepare the DNS change before launch day

A low-risk preparation sequence

01

Export and annotate the live zone

Save a dated copy or screenshots of every record. Add a plain-language owner and purpose for web, mail, verification, payments, help desk, and campaign subdomains.

02

Confirm the host's exact targets

Obtain the production IP addresses or canonical hostnames from the new platform. Do not copy values from a different client's account or an old help article.

03

Test on a staging hostname

Use a private preview or a temporary subdomain so the team can test pages, forms, integrations, redirects, and access controls without moving the public domain.

04

Review TTL deliberately

TTL tells caching resolvers how long an answer may be reused. If your provider permits it, a planned temporary reduction can shorten some caches, but it cannot guarantee a universal cutover time. Restore an appropriate steady-state value after the launch is stable.

05

Verify HTTPS readiness

Make sure the new platform knows every intended hostname and can serve a valid certificate after DNS points there. Test both the root domain and `www`, plus any live subdomains included in the project.

06

Schedule people, not just records

Name the person making the change, the person testing, the person who can approve rollback, and the contact for email or hosting escalation. Keep credentials available without sharing them in a group chat.

VISUAL CHECKPOINT · RedesignThe path a visitor follows

A launch usually changes the destination at the end of the chain, not ownership at the beginning.

Protect email and other invisible services

A working homepage is not proof that the DNS change is complete. MX records route incoming mail. TXT records may support SPF, DKIM, DMARC, Google or Microsoft verification, payment services, and security tools. CNAME records may connect a client portal, scheduling tool, status page, or email marketing service. List these dependencies before launch, then test them independently. If the website and email projects are not intentionally linked, there is usually no reason to alter the mail records.

  • Send a message to and from an address on the business domain, then confirm receipt rather than trusting an admin screen.
  • Check forms from the browser through the inbox or CRM, including spam handling and autoresponders.
  • Visit important subdomains such as portal, shop, help, or booking and confirm their certificates and destinations.
  • Verify payment, scheduling, chat, analytics, and search-verification integrations that depend on DNS or the final domain.
  • Keep the old hosting account active through the agreed observation period so rollback is technically possible.

Expect overlap while cached answers expire

People call the transition 'DNS propagation,' but the practical issue is distributed caching. Different resolvers may hold the earlier answer for different lengths of time, subject to the prior TTL and their behavior. During that overlap, one tester may reach the new site while another still sees the old host. Do not publish a guaranteed minute when every network will agree. Instead, make both environments safe, avoid taking the old site down immediately, and monitor from more than one network.

The launch evidence log

CheckpointEvidence to recordRollback trigger example
DNS answerTimestamp, resolver or network, returned destinationRequired hostname has no valid answer
HTTPSCertificate valid for each public hostnameCertificate error blocks ordinary visitors
Homepage and key pagesHTTP status and visual checkProduction serves an error or wrong project
Lead pathSuccessful test form or booking with destination confirmedLeads cannot reach the assigned team
EmailInbound and outbound testsMail delivery stops after an approved DNS change
RedirectsSample of valuable old URLs reaching mapped pagesLarge or critical set returns errors

Make rollback a written decision

A rollback plan must name the previous values, the person allowed to restore them, the conditions that justify doing so, and the checks required afterward. Restoring an earlier DNS value does not instantly recall every cached answer, so the old and new hosts should remain coherent during the transition. If new transactions or content can be created on both systems, decide how they will be reconciled before the switch. A brochure site has a simpler rollback than an ecommerce store or member portal.

Use the broader website redesign and migration library to plan redirects, analytics, content, and post-launch checks around the DNS work. Then give the person running the cutover the separate website redesign launch checklist, because a correct DNS record cannot compensate for missing redirects, broken forms, or an untested production build.

Will a website redesign change who owns my domain?

Not in a normal redesign. The registration can stay in the business's existing registrar account while web DNS records point to a new host. A registrant or registrar transfer is a separate process and should not be bundled into launch day without a clear reason.

Will changing the website break business email?

Changing only the correct web record should not reroute email, but replacing nameservers or the whole DNS zone can remove MX and mail-related TXT records. Inventory, preserve, and test them. Ask the email provider for its current official values rather than relying on an old screenshot.

How long will DNS take to update?

There is no responsible universal promise. The earlier TTL, resolver caches, provider behavior, and the scope of the change all matter. Plan for an overlap in which some visitors can reach the old destination while others reach the new one.

Should I transfer my domain to the new web designer?

Usually the business should keep the registration in an account it controls and grant suitable access. A transfer may be justified for governance or consolidation, but it is not required merely to redesign the website.

Can we switch the domain before the new SSL certificate is ready?

Do not assume that is safe. Confirm how the new host validates and issues certificates, add every intended hostname, and have an HTTPS test in the go-live gate. The platform's own instructions control the exact sequence.