How to build a business case for a website redesign.

Start with what the current website prevents

“The website looks old” describes an opinion, not an investment case. Identify the business consequence: qualified buyers cannot understand the offer, important pages are hard to find, the team cannot publish reliably, mobile tasks fail, search visibility is exposed, or the platform makes ordinary changes risky.

Name the people affected and the decisions they struggle to make. Separate website problems from offer, traffic, sales follow-up, or operational problems that a redesign cannot solve alone. A narrower honest case is more useful than promising the website will fix the entire funnel.

Record evidence before changing the site

Combine analytics with operational evidence. Review priority landing pages, inquiry completion, sales-qualified submissions, important task paths, search performance, speed, accessibility, content age, support questions, publishing effort, maintenance incidents, and dependencies on unavailable specialists.

Document definitions, date ranges, known tracking gaps, and external factors. The goal is not a decorative dashboard. It is a baseline that explains the current constraint and can be measured in the same way after launch. See how to measure website redesign success for a practical framework.

Choose a small set of decision-worthy outcomes

Translate evidence into outcomes the project can influence: more qualified inquiry starts, fewer abandoned forms, better completion of a priority task, stronger organic landing-page coverage, faster publishing, lower maintenance risk, or accessible use of core journeys.

For each outcome, state the baseline, desired direction, measurement source, owner, review date, and important guardrails. Avoid assigning an arbitrary percentage when the data cannot justify it. A useful success statement can be directional and still precise about what will be observed.

Compare intervention levels, not only vendors

Present at least a credible minimum and a recommended scope. The minimum may repair critical journeys and technical risk; the recommended option may also restructure content and rebuild the design system. Include the cost of delaying, maintaining the current site, or doing work that will soon be replaced.

Show which assumptions affect price and timing: content readiness, approvals, integrations, migration, compliance, platform change, and launch windows. Use the website redesign cost guide to separate the work behind an estimate.

Give decision makers a reviewable proposal

• Problem: one clear business constraint and the evidence behind it.
• Audience: priority users, tasks, and internal teams affected.
• Outcome: measures, owners, and post-launch review dates.
• Scope: what changes, what stays, and what remains outside the project.
• Investment: implementation, internal time, licences, and ongoing costs.
• Risk: dependencies, delay consequences, and launch safeguards.