Write down the constraint
“I am tired of looking at it” is a preference. “Customers cannot finish the inquiry on a phone” is a problem you can investigate. Start with the problem, then compare ways to fix it.
Separate a repair from a foundation problem
Fictional example: a service page buries the offer and has an unclear button. Rewriting the page and fixing the destination may be enough. If essential pages cannot be edited without breaking the layout, or the platform cannot support a required workflow, a rebuild deserves closer consideration.
A technical review should establish the actual limitation. An old-looking design alone does not prove the foundation is unsafe or unsuitable.
Compare complete costs
For repair and rebuild, include content work, development, migration, training, maintenance, and disruption. Ask what each option will fix—and what it will leave alone. Do not compare a small repair quote with an undefined “new website.”
Protect what already works
Inventory important URLs, useful content, incoming links, forms, analytics and consent behavior, and necessary integrations. Preserve URLs where possible. If a URL must change, plan its redirect and verify the destination. Keep a recoverable version of the existing site.
Define acceptance before launch
Check the actual visitor journey on desktop and mobile, including keyboard use, errors, confirmation, and inquiry delivery. Use an authorized test environment or a coordinated test; do not send mystery leads to production.
A rebuild is a way to remove a verified constraint. It is not a substitute for explaining the offer or deciding who follows up.