Launch day panic almost always comes from the same source: nobody wrote down the order of operations. Moving a live site to new hosting, or pointing a domain at a rebuilt site, is a sequence with a few hard rules and one property that surprises people, which is that DNS does not switch for everyone at the same moment. Plan around that and the whole thing becomes boring, which is the goal.
Lower the TTL a day early
The one preparation step that changes everything: at least 24 to 48 hours before launch, lower the time to live on your DNS records to something short, such as 300 seconds.
TTL tells the rest of the internet how long to cache your DNS answer. If it is set to 24 hours, some visitors will keep hitting the old server for a day after you switch, and if something goes wrong your rollback takes just as long to propagate. Lower it in advance, switch with a five minute TTL, then raise it again a few days after launch once you are confident.
Do this first, because everything else assumes it.
Prepare the new home completely before switching anything
The new site should be finished, tested, and serving correctly on its own address before DNS moves. That means content in place, forms working, the redirect map loaded, and a full staging review already done.
Get the certificate sorted in advance too. Most hosts can issue one for a domain before it points at them, and if yours cannot, know exactly how long issuance takes after cutover so you are not surprised by a browser warning during your first hour live.
Set up the server rules on the new host before the switch: HTTPS enforcement, the canonical choice between www and bare domain, and your redirect rules. Testing these afterwards under time pressure is how people introduce redirect loops, which is the failure mode that is hardest to debug because it caches.
Freeze content, sync, then switch
If the old site has a database or a CMS anyone can edit, declare a content freeze before the final sync. Otherwise an editor publishes something during the move and it exists only on the server you are abandoning.
The order on the day: final content sync, verify the new site on its temporary address one more time, then change DNS. Keep the old server running and untouched for at least a week afterwards, because during propagation some visitors are still reaching it, and because it is your rollback.
If the old and new sites are on the same domain, that is the entire switch. If the domain itself is changing, the old domain must stay registered and serving permanent redirects indefinitely, since links and search results pointing at it will keep arriving for years.
Verify within the first hour
The moment DNS moves, work through a short list rather than waiting for someone to complain.
Load the homepage on a device that has never visited the site. Check the certificate is valid and HTTPS enforcement works. Test both www and non www, and both HTTP and HTTPS, so all four resolve to one canonical URL in one hop. Submit a form and confirm the message arrives. Confirm analytics is recording. Check that the site is actually indexable, which means verifying no stray noindex tag and a robots.txt that allows crawling.
Then run your old URL list against production and confirm every redirect resolves. Automate it; this is the check that finds the rows that were wrong on staging for environment reasons.
Tell the search engines, then watch
Submit the new sitemap in Search Console and request indexing for the most important pages. Expect some ranking movement for a few weeks even when everything was done correctly, and expect crawl errors to appear as the crawler works through old URLs.
Watch server logs and Search Console daily for the first fortnight, fix 404s as they appear, and resist making other changes during that window so you can attribute what you see. The full ranking protection routine matters most in exactly this period.
Keep the boring assets safe
Two things get lost during hosting moves more than anything else: email and domain control.
If email runs on the same domain, its MX records must be preserved exactly. Moving hosting while accidentally resetting DNS to a new host’s defaults will take your company’s email offline, and that is the failure people remember. Copy every existing record before changing anything.
Similarly, make sure your organisation controls the registrar account and the hosting account, not an agency or an individual who might leave. That, plus a backup you have actually restored, is what turns a launch into a routine event rather than a risk.
Planning a cutover and want someone who has done it many times to run it? hello@beconfidency.agency.
If you want the build and the launch owned end to end, that is exactly what our web development service is for.