Separate four kinds of problem
| Problem | Likely starting point |
|---|---|
| The offer is difficult to understand | Content and page-structure work. |
| The site is hard to use on mobile | A focused usability and frontend assessment. |
| A specific action is broken or slow | Diagnose and repair the failing component. |
| The platform cannot support necessary business rules | Assess deeper development or replacement. |
Several may apply, but keeping them separate makes a proposal easier to evaluate. A fresh visual design will not automatically fix form delivery. A new framework will not write a clearer service description.
Identify what already earns its place
List the pages that bring suitable visitors, the content customers use and the workflows staff rely on. Include search URLs, enquiry forms, integrations and internal reports. A feature that looks untidy may contain a business rule that would be expensive to rediscover.
Speak to the people using the system every day. Ask which workarounds exist and why. The decision should account for both the public website and the operations behind it. For a spreadsheet-driven process, see when an application is justified.
Test the case for repair or redesign
If the underlying system is maintainable and supports the required tasks, a repair or redesign can retain useful work. Ask what can change without replacing accounts, content or integrations. A short technical assessment may reveal a smaller route to the same outcome.
When the concern is speed, use performance diagnosis rather than assuming hosting or the CMS is responsible. When the concern is a lack of leads, check the enquiry journey before treating the whole website as the problem.
Recognise when replacement may be justified
Replacement deserves consideration when essential changes cannot be made reliably, unsupported dependencies cannot be dealt with sensibly, or the data and workflow model no longer fits the business. The case should explain why incremental work is insufficient and what the new system will make possible.
For old business software, include data migration, reporting, staff training and the transition period. The cost is not just recreating screens. A staged replacement may reduce disruption if there is a clear boundary between the old and new responsibilities.
Compare proposals against the same outcome
- What specific user or staff task will work better?
- Which existing pages, records and integrations will remain?
- What evidence supports replacement rather than repair?
- What is included in migration, testing and handover?
- What ongoing responsibilities will the business take on?
- How will success be checked after launch?
Ask for assumptions and exclusions. If one proposal includes a careful migration and another does not, they are not equivalent even if both say “new website”. The website cost guide helps compare scope.
Plan the change, not just the finished design
Preserve useful URLs where possible, map moved content and test the important actions before launch. Agree access, backups and a recovery route. Use the migration checklist to include those tasks in the project.
If the final decision is a redesign, write down what the underlying system will retain. If it is a rebuild, write down the reasons and the operational requirements that must survive. Both decisions are easier to defend when tied to observable problems rather than a preference for new technology.
Discuss what needs to change
Send the current website and the main constraint you are trying to remove. We can discuss the scope of a repair, redesign or new build.