Moving a website sounds simple until someone says, "Just update the DNS."

DNS changes are often part of the job, but they are not the whole job. Your domain registration, website hosting, DNS, and email may all be managed by different companies. A successful migration starts by understanding which provider is responsible for what—and changing only what actually needs to change.

This checklist uses a move from Register.com to Squarespace as an example, but the same basic process applies to most website and domain migrations.

First, separate the moving parts

Four services are commonly bundled together in conversation even though they are technically different:

  • •Domain registrar: The company where the domain is registered and renewed.
  • •DNS host: The service that stores the domain's DNS records.
  • •Website host: The platform that serves the website.
  • •Email provider: The service that delivers mail for addresses using the domain.

They may all be managed by one provider, or each may live somewhere different.

Moving a website to Squarespace does not necessarily mean transferring the domain registration to Squarespace. You can connect the existing domain to the new website while keeping it registered at Register.com. A registrar transfer can happen separately if it offers a long-term benefit.

Before changing anything

1. Confirm administrative access

Make sure you can sign in to:

  • •The current registrar
  • •The DNS-management account
  • •The old website host
  • •Squarespace
  • •The organization's email administrator
  • •Any third-party service that uses the domain

Confirm that recovery email addresses, phone numbers, payment information, and two-factor authentication are current.

2. Record the existing DNS configuration

Before editing DNS, export the zone file if the provider supports it. Otherwise, take clear screenshots or copy every record into a document.

Pay particular attention to:

  • •Root or @ records
  • •www
  • •MX records
  • •TXT records
  • •SPF, DKIM, and DMARC records
  • •Verification records
  • •Subdomains
  • •Records used by forms, newsletters, calendars, or other integrations

This record becomes both your migration map and your rollback reference.

3. Decide whether to connect or transfer

Connecting the domain keeps the registration at Register.com while pointing the website to Squarespace.

Transferring the domain moves the registration itself to Squarespace. A transfer may require unlocking the domain, obtaining an authorization code, confirming registrant contact information, and waiting through registrar or registry restrictions.

Connecting is usually the smaller immediate change. Transferring may make sense later if consolidating vendors will simplify administration.

Do not cancel the existing domain or hosting service before the migration is complete.

A simple Register.com-to-Squarespace example

Imagine the domain is registered at Register.com, DNS is also managed there, the new website has been built in Squarespace, and email is hosted by Google Workspace or Microsoft 365.

The basic process is:

  1. •Add the existing domain inside Squarespace.
  2. •Select the option to connect a third-party domain.
  3. •Copy the exact DNS records supplied by Squarespace.
  4. •Open the DNS-management area in Register.com.
  5. •Replace only the website-related records that conflict with the Squarespace instructions.
  6. •Preserve the existing email records.
  7. •Wait for the connection to verify.
  8. •Test the website and email before retiring the old host.

Provider values can change, so use the records shown inside the Squarespace domain panel at the time of the migration. Do not copy record values from an old article, screenshot, or unrelated domain.

DNS records in plain language

  • •A record: Points a hostname to an IPv4 address.
  • •AAAA record: Points a hostname to an IPv6 address.
  • •CNAME: Makes one hostname an alias of another hostname.
  • •MX record: Tells the internet where to deliver email.
  • •TXT record: Stores verification or policy information, including many email-security settings.
  • •NS record: Identifies the authoritative DNS provider for the domain.
  • •TTL: Tells DNS resolvers how long they may cache a record before checking again.

Lowering a TTL ahead of a planned migration can help changes be noticed sooner, but it does not guarantee that every network will update at exactly the same time.

Protect the email

Website migrations often go wrong because someone replaces every DNS record instead of changing only the website records.

Unless the email provider is also changing, preserve:

  • •MX records
  • •SPF records
  • •DKIM records
  • •DMARC records
  • •Email-verification TXT records
  • •Mail-related CNAME records

After the website change, send test messages both to and from an address on the domain. Check that SPF, DKIM, and DMARC still align with the real sending provider.

A website that loads while email silently fails is not a successful migration.

Test before calling it finished

Check:

  • •The root domain loads
  • •The www version loads or redirects correctly
  • •HTTPS works without certificate warnings
  • •Old important URLs redirect appropriately
  • •Contact forms submit and deliver notifications
  • •Images, downloads, and embedded media load
  • •Mobile navigation works
  • •Inbound and outbound email work
  • •Newsletter and third-party integrations still work
  • •Important subdomains still resolve
  • •Analytics and search-verification tools remain connected

DNS changes can take time to propagate. Keep the old hosting account active during the transition whenever possible, and monitor the site and email for at least the next couple of days.

The short version

Before a migration:

  • •Know where the domain, DNS, website, and email live
  • •Save the existing DNS records
  • •Confirm access to every account
  • •Decide whether you are connecting or transferring
  • •Use the destination platform's current record values
  • •Change only the records that need to change
  • •Protect the email records
  • •Test everything
  • •Document the final configuration
  • •Do not cancel the old service too early

Migrations are less about making one clever DNS change and more about avoiding one careless one.

If you would rather have someone map the systems, coordinate the move, and test the result, let's talk.