Moving a live site to a new server sounds risky and mostly is not, provided you build the destination completely before you send anyone to it. The classic mistake is changing DNS early and then racing to finish while visitors arrive at a half-configured server.
A week before: lower the TTL
Find the current TTL on your A record. If it is 24 hours, lower it to 300 seconds now — resolvers will keep honouring the old value for one more full period, so this must happen well in advance.
This single step is the difference between a switchover that takes five minutes and one that dribbles on for a day.
Build the new server completely
Deploy the server, install the runtime, database and web server, then restore a copy of your site and data. Do not point the domain at it yet.
Test using a hosts-file entry on your own machine so the domain resolves to the new server for you and nobody else. This is the whole trick: you get to browse the real site, on the real hostname, on the new server, while every actual visitor is still served by the old one.
Work through the site properly. Log in, submit a form, upload a file, trigger an email, check anything scheduled. The problems that surface here are the ones that would otherwise surface in public.
Issue the certificate before switching
Use the DNS challenge to issue a certificate for the new server while the domain still points elsewhere. HTTP validation cannot work yet, because the name does not resolve to the new machine.
Doing this in advance means HTTPS works from the first second after the switch, rather than during a scramble while traffic is arriving.
Freeze, sync, switch
Pick a quiet hour. Put the old site into a read-only or maintenance state if it accepts writes — this is what stops orders or comments landing on a server you are about to abandon.
Do a final sync of the database and any files that changed since the first copy, then update the A and AAAA records to the new address. With a 300-second TTL, traffic moves over within a few minutes.
Watch both servers
Keep the old server running and watch its logs. Requests still arriving there are visitors whose resolver is holding a cached answer, and the number should fall to nothing within an hour or two.
Watch the new server's error logs at the same time. File permissions, missing PHP extensions and hard-coded paths are the usual first-hour surprises.
Do not decommission early
Leave the old hosting active for at least a week. It costs one more billing period and it is the cheapest insurance available — if something turns out to be missing, the source is still there.
Two things are routinely forgotten in this window. Email is separate from hosting: if your MX records point at the old provider and you cancel it, mail stops even though the website is fine. And cron jobs configured in the old control panel do not migrate themselves; check what was scheduled there before it disappears.