THE SHORT ANSWER
Keep the existing site usable while the replacement is reviewed. Map important pages, protect domain and email settings, test customer actions, assign a launch owner and check the public result afterward.
List the jobs the current website already does
Start with the public site rather than the new design. Write down the pages people use: services, location, hours, contact, quote requests, appointments and downloads. Put the existing address beside each one. The point is to create a useful inventory, not an impressive spreadsheet.
Ask the person answering inquiries which website questions come up often. A form that quietly sends leads to an inbox can be overlooked during a redesign. So can a service page customers bookmarked. Make sure the new site handles those tasks before deciding a replacement is ready.
Make a second list of what must change. Old staff details, out-of-date services and broken forms deserve attention. Protecting the working parts does not mean preserving mistakes.
Review the replacement away from the public site
Keep the existing website available while a replacement is prepared in a separate preview or staging location when your hosting setup permits it. The preview should be clearly identified. Nobody should accidentally mistake test pages for the live business.
Read the new version on a phone and a larger screen. Check that service names, hours, contact instructions and location details match real operations. Check buttons and where they lead. Decorative mockups are not substitutes for an actual working contact form.
Give the person who handles inquiries a chance to inspect the process. The developer can verify that a form submits, while the office needs to confirm the resulting message arrives and makes sense. Visual approval alone does not establish that the handoff works.
Give important old page addresses a destination
Collect page addresses that people may find in search results, bookmarks or links on other sites. Match each old page to the closest useful new destination. Do not send a page about a discontinued service to an unrelated homepage just because it is convenient.
When an address changes permanently, Google Search Central recommends a permanent server-side redirect, such as a 301 or 308, when appropriate. A redirect map helps a developer check that visitors reach the relevant new page. A new design does not require changing every useful existing URL.
After launch, open the old addresses in a signed-out browser. Confirm the right pages appear and that there are no unexpected missing-page errors. Keep the address map available for repairs and future maintenance.
Know who controls the domain and business email
Find out who manages registration, DNS, the website host and the email service. These may be different companies. Replacing the website does not automatically require replacing the email setup or moving the domain to another registrar.
DNS records serve different purposes. Cloudflare's documentation distinguishes records used for website addresses from mail delivery records such as MX. Someone responsible for the launch should record the actual settings before any change and identify exactly which ones need adjustment.
Do not paste passwords into project notes or ordinary emails. Use suitable account permissions and keep a record of who changed what. If business email stops arriving afterward, the team should be able to check the relevant changes rather than guess.
Test customer actions from beginning to end
Open the proposed new website like a visitor who does not know where everything is. Try it on a phone. Find the contact button, submit a clearly marked test using only your own contact details, and confirm with the responsible person that the request arrived. Then test the ordinary reply route.
If appointments are available, confirm the booking action reaches the correct service, location and provider. Do not reserve a real customer slot just to prove a button works. Use a supported test mode or coordinate a controlled test without creating a false booking.
Forms need useful feedback when information is missing or submitted. W3C guidance explains how validation and accessible notifications can help. A page that appears to say 'sent' is not proof that a usable inquiry reached the office. Test both sides.
Agree on who handles the switch and a way back
Choose a suitable launch window and name a person responsible for the final check. Avoid your busiest business hours when possible. Confirm which host, domain and website settings will change, and prepare a backup or rollback procedure that fits the actual platform.
Write down the checks that must pass before the old version is retired. The homepage should load securely. Main service pages need correct details. Contact and booking routes should work. Important old links should reach relevant new pages. Business email should continue to function.
Ask who handles unexpected problems and how the previous configuration could be restored. A rollback plan should describe something the team can genuinely perform. It should not depend on a setting no one has checked.
Verify the public website after release
Repeat the most important tests on the real domain, not only on the preview. Open the website from a signed-out browser and on a phone. Check the main service pages, the contact pathway and the new destination for old URLs.
Google's site-move guidance recommends monitoring Search Console, sitemaps and crawl errors after significant URL changes. Analytics can help identify unusual patterns, but a quiet traffic day alone does not establish that a website is broken. Compare what the data shows with specific page tests.
Keep a shared issue log during the first review period. Record the failed page, device, observed behavior, person responsible and whether the repair was retested. That makes the replacement a manageable business project instead of a guessing game.