The point of testing before DNS changes is that a failure costs nothing. The domain still points at the old host, the live site is untouched, and anything wrong is something you fix quietly rather than in front of visitors.
Doing it the other way round (switching first, testing after) makes every visitor your test, and rolling back means waiting for DNS to propagate a second time.
Set up a hosts file entry
This maps the domain to the new server on your machine only. Everyone else continues to reach the old one.
Edit the hosts file, /etc/hosts on macOS and Linux, C:\Windows\System32\drivers\etc\hosts on Windows, opened as administrator, and add:
203.0.113.45 example.com 203.0.113.45 www.example.com
Use the server address from your welcome email, and include both names.
Confirm it took effect before concluding anything about the site: load the address and check you are seeing the new server instead of a cached copy of the old one.
Remove these lines when you are finished. Forgetting means you keep seeing the new server after the switch and cannot tell whether it actually worked.
What to walk through
Not just the homepage. The homepage is what everybody checks and it is the page least likely to be broken.
A deep page: a post, a product, something several levels down. This is where rewrite rules fail, and the symptom is a working homepage with 404s everywhere else.
An archive or category page.
Images. Missing images usually mean stored URLs still point at the old domain or old path.
A form. Submit it and confirm the message actually arrives. Forms fail silently more than anything else on a migrated site.
The admin area. Log in and load a few screens.
Checkout, if there is one, all the way to the payment step.
What each failure means
Homepage works, everything else 404s. Rewrite rules were not regenerated. In WordPress, open Settings then Permalinks and save without changing anything.
Site loads without styling, or images are missing. Stored URLs still reference the old domain or path. Fix with a search-and-replace tool that understands serialized data. A plain SQL replacement corrupts theme and widget settings.
Error establishing a database connection. The credentials in the configuration file do not match the new database, or the database user was never granted privileges on it.
Form submits and nothing arrives. Either mail routing, or the application using the server's basic mail function. Configuring the application to send through authenticated SMTP is the reliable fix.
Certificate warning. Expected at this stage. Certificates cannot be issued until the domain resolves here, because the authority verifies control by reaching it. Ignore it during testing and run AutoSSL after the switch.
Ignore the certificate warning, for now
Worth repeating because people stop testing at this point and open a ticket.
While you are testing via a hosts entry, the domain still officially points elsewhere, so no certificate has been issued for it here. The browser is correct to complain. Click through and carry on testing.
Then switch, then check again
Once everything works, change the nameservers, and remove the hosts file entry.
After DNS resolves here, three things need checking that could not be checked before.
Run AutoSSL and confirm the padlock. This is the first moment it can succeed.
Test email properly. Send a message to an address on the domain from outside. Mail failing is silent, unlike a website failing.
Check SPF and DKIM. They referenced the old host and are now wrong, which is why mail from a freshly migrated site so often lands in spam. There is more on regenerating them in understanding SPF, DKIM and DMARC.
Keep the old hosting for a week
During propagation, some visitors and some mail reach the old server. Orders and form submissions landing there are the things that genuinely get lost.
Do not cancel the old account the same day. Check its mailboxes before shutting anything down, and give it at least a week. Understanding DNS propagation goes into why the window is as long as it is.
Compare the two sites rather than judging one
Deciding whether the new copy is correct by looking at it invites missing whatever quietly did not arrive.
curl -s https://example.com/ | wc -c
curl -s --resolve example.com:443:NEW-IP https://example.com/ | wc -c
diff <(curl -s https://example.com/ | tr '>' '\n') \
<(curl -s --resolve example.com:443:NEW-IP https://example.com/ | tr '>' '\n') | head -30
Resolving the name to the new address for a single request fetches the new site under the real hostname while the domain still points at the old one.
Compare the sizes first. A difference of a few percent is normal. A difference of a third means something substantial is missing, and the line by line comparison shows what.
Check the pages that write, not only the pages that read
A copied site almost always displays correctly. What fails is anything that stores something, because that depends on permissions and on the database user.
curl -s -o /dev/null -w '%{http_code}\n' --resolve example.com:443:NEW-IP https://example.com/wp-login.php
ls -ld ~/public_html/wp-content/uploads
tail -20 ~/logs/example.com.error.log
Submit a form, upload a file and log in. Those three exercise the parts that a page load does not, and each fails in a way that is invisible from the front page.
Permission and ownership problems are the usual cause, since files copied by one method arrive owned by whoever performed the copy rather than by the account. Understanding file permissions and ownership covers correcting them.
Watch the old server after the switch
The most useful week for finding what was missed is the one after the domain has moved, and the evidence is on the machine you are about to cancel.
tail -f ~/logs/example.com | grep -vE ' 30[12] '
awk '{print $7}' ~/logs/example.com | sort | uniq -c | sort -rn | head
Requests still arriving at the old server days after the change are systems using a fixed address rather than the domain: a payment callback, a monitoring check, an integration configured years ago.
Each one is something that will break the day the old account is cancelled, and this is the only period during which you can find them without causing an outage to do it.