Changing the domain a site lives on is the largest single change you can make to a website's addresses. Every page moves, every inbound link points somewhere that no longer exists, and email moves with it whether or not you planned for that.
It is entirely doable. The order below is what determines how much traffic survives.
Keep the old domain
The decision people get wrong first.
The old domain must keep working, and keep being renewed: for years, because it is what the redirects run on. Letting it expire two years later severs every inbound link at once, and by then nobody connects the two events.
Budget for it as a permanent cost. It is small, and it is the cheapest part of protecting what you built.
Map the URLs before anything moves
List every page on the old domain with its address, and note which ones get traffic.
Then decide each one's destination on the new domain. If the structure is staying the same, that mapping is a single rule; if you are restructuring at the same time, it is a page-by-page list.
Do not restructure and change domain in one move if you can avoid it. Two large changes at once means you cannot tell which one caused a drop. How to Redirect a Domain or Page deals with writing the rules.
Set the new domain up alongside
Point the new domain at the server, add it to the account, issue the certificate, and confirm it serves the site over HTTPS.
Keep it out of search results until the switch, so the same content is not published at two addresses in the meantime, and remember to remove that block on the day, because it is the most common launch mistake there is. How to Prepare a Website Launch Checklist deals with checking for it.
Change the site's own address
Update the application's configured address to the new domain, then deal with the part that does not follow.
Every image URL and internal link stored inside your content still contains the old domain. That needs a search and replace across the database, using a tool that understands serialised data. A plain SQL replace corrupts theme and builder settings. There is more on doing it safely in How to Change Your WordPress Site URL.
Internal links pointing at the old domain would otherwise work only because of your own redirects, which adds a hop to every internal click.
Then redirect, one hop, permanently
301 from each old address to its equivalent new one. Not to the homepage; that is treated as pages that vanished rather than moved, and a visitor following a link to a specific article has to start over.
Check that each redirect is a single hop. A chain, old HTTP to old HTTPS to new HTTPS to new with www, is common when several rules stack, and each hop costs a round trip:
curl -IL https://old-example.com/some-page/
Read every line of that output. One 301 straight to the final address is the target.
Mail moves too, and it is separate
Addresses at the old domain stop working when you stop hosting mail for it, and nobody tells you.
Decide explicitly: keep receiving at the old domain indefinitely, forward it to the new one, or announce the change and let it stop. Whichever you choose, keep the MX records working for at least a year, people email old addresses for a very long time.
On the new domain, set up SPF and DKIM before you start sending from it. A new sending domain with no authentication starts from nothing, and mail drifts into spam while you work out why. Understanding SPF, DKIM and DMARC Records walks through the records.
Tell the search engines deliberately
Verify the new domain in your search console and use the change-of-address tool. That does not replace the redirects. The redirects do the work: it makes the transfer faster.
Submit a sitemap for the new domain, and keep the old property verified so you can watch its crawl errors during the transition. How to Verify Your Site and Set Up Analytics goes into the verification.
Update what you control off-site
Redirects handle visitors. They do not update anything else.
Social profiles, business listings, email signatures, printed material, third-party integrations and any service posting to your site by URL. Work through them in the first week.
For the highest-value inbound links (the handful of sites sending real traffic) ask them to update. A direct link is worth more than a redirected one, and most people will do it if asked once.
Expect a dip, and know what is normal
Rankings usually move for a few weeks and recover. That is normal for any address change.
What is not normal is traffic that does not return after a couple of months. That usually means redirects are missing, chained, or pointing at the homepage. Check the crawl errors rather than waiting.
Keep the redirects permanently. Links on other sites are never updated, and a redirect removed after "traffic recovered" quietly breaks them years later.
Verify the mapping before the switch, not after
A redirect map is easy to write and easy to get subtly wrong, and testing it while both sites exist is the only cheap moment.
curl -s https://old.example.com/sitemap.xml | grep -o 'https://[^<]*' > old-urls.txt
while read u; do
n=$(echo "$u" | sed 's|old.example.com|new.example.com|')
printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$n")" "$n"
done < old-urls.txt | grep -v '^200' | head -20
Every old address must have a destination that answers. Anything that does not is a page that will produce an error the moment the redirect goes live.
Check the count as well. A map covering a fraction of the old addresses is a partial move, and the pages left out are usually the older ones that carry the accumulated links.
Watch what still arrives at the old name
The redirect handles visitors. Several systems use the address directly and never follow one.
tail -f ~/logs/old.example.com | grep -vE ' 30[12] '
awk '$9 !~ /30[12]/ {print $7}' ~/logs/old.example.com | sort | uniq -c | sort -rn | head
Requests still arriving weeks later, not following the redirect, are payment callbacks, integrations and monitoring checks configured with the old name.
Each is something that breaks when the old domain is eventually released. This log is the only list of them that exists, and it is available only while the old domain is still yours.
Keep the old domain longer than feels necessary
The redirect has to keep working for as long as anything points at the old name, which is years rather than months.
whois old.example.com | grep -iE 'expir|status'
Links in printed material, in other people's articles and in email signatures do not expire. Releasing the domain turns all of them into errors, and whoever registers it next inherits that traffic.
Renew it for as long as the redirect matters, and keep the renewal on the same automatic arrangement as the new one so it is not dropped by somebody tidying up. Domain auto-renewal covers keeping it.