Choose the size of the change
Compare the options side by side, then choose the scope that fits.
| Approach | Useful when | Check before committing |
|---|---|---|
| Focused improvement | The platform works, but a form, page or message creates friction. | Can the specific problem be fixed and measured without replacing the site? |
| Redesign | The content and integrations are useful, but navigation and presentation need a coherent update. | Can the current platform support the new layout, accessibility and performance requirements? |
| Rebuild | Confirmed platform, maintenance or integration limits prevent the required experience. | Are content migration, URL mapping, hosting, testing and ongoing ownership included? |
Walk the journey before judging the look
Choose one task: a homeowner requests an inspection, a patient asks about a consultation, or a business owner books an introduction. Walk from the entry page to the actual confirmation on a phone. Check whether the offer is understandable, the action is visible, the form preserves information after an error and the team receives a usable record. Write down the exact point of friction. A broken notification may need a delivery fix rather than a new homepage.
Separate content, design and platform problems
Unclear service descriptions are a content problem. A hard-to-use navigation or crowded mobile form is an interface problem. An unsupported integration, unreliable deployment or unavailable permission model may be a platform problem. These can overlap, but they require different work. Ask the person proposing a rebuild to name the limitation and show why a smaller improvement cannot address it. Avoid paying to recreate a working integration simply because the visual design is changing.
Keep what already helps customers
Inventory useful pages, enquiry sources, incoming links and the records your team relies on. Search Console and analytics can help identify entry pages; staff can explain which enquiries are useful. Keep established URLs where practical. If a URL must change, map it to the most relevant replacement and test the permanent redirect. Do not send unrelated retired pages to the homepage. Include page titles, canonical URLs, sitemap updates and enquiry destinations in the migration review.
Include the operating costs
Compare the initial work alongside content preparation, hosting, platform subscriptions, ongoing maintenance and the team's time. Confirm who controls the domain, accounts, source code and deployment. A rebuild that reduces one technical constraint may introduce another subscription or support dependency. Ask what can be edited without a developer and how access will be handed over. The written scope should identify what is retained, changed and outside the engagement.
Agree acceptance and rollback before launch
Use a checklist based on the actual business journey: navigation and forms work on supported devices, records reach the right team, redirects preserve relevant destinations and analytics respect consent. Compare speed under comparable conditions rather than comparing a local preview with a live site. Keep a recoverable copy of the current version and agree who can restore it if launch creates a problem. A visual approval does not establish successful enquiry delivery.
Review one change before expanding
A useful first step might be correcting a service page and its enquiry form. Review completed enquiries, failed submissions and the staff's follow-up effort over a comparable period. For a redesign or rebuild, keep the release date and affected URLs so changes can be evaluated later. Search performance can move for reasons beyond the site; a launch and a traffic change occurring together do not prove that one caused the other.