Why a relaunch rarely fails on the design
Anyone planning a relaunch thinks about the look first. What actually derails it usually sits elsewhere: content nobody maintains, a structure derived from the org chart rather than from how people use the site, and URLs that reach nobody after the switch.
So we do not start with drafts. We start by taking stock. Which pages exist, which ones are actually opened, which ones bring enquiries? Only after that can you decide sensibly what comes along.
Update or relaunch
Not every outdated installation needs rebuilding. If the structure and the templates still carry the site and only the version is old, an update is the faster and cheaper route.
The case for a relaunch rests on other grounds: an information architecture that no longer fits, templating that has become impenetrable over the years, or a jump across several major versions in which almost everything has to be touched anyway. Which of the two applies is something we clarify beforehand. The guide Update or relaunch goes into it at length.
The switch itself
Before the switch, the new site runs in full on an environment of its own. There we check the old URLs against the prepared list, verify the redirects, and look at whether the titles and descriptions on the important pages are right.
The changeover itself is then a short, planned step. The old installation stays in place at first so there is a way back. Over the following weeks we keep an eye on Search Console and the error logs, because some gaps in a redirect plan only show up under real traffic.