How to plan a website redesign.

A redesign plan is a sequence of decisions, not a calendar with design in the middle.

Most website redesign plans look organized until the first real conflict appears. A ranking page has to be rewritten. A department wants a new section. A stakeholder asks for a feature the site does not need. A form integration is discovered late. Planning works when those conflicts have a place to go before they become emergencies.

The planning article sits in the Website Redesign Guides because planning is where the site’s existing value either gets protected or quietly lost. The plan should explain what happens first, what waits, who owns each decision, and which launch risks cannot be pushed to the end.

TC Architecture Firm shows why planning starts with what should not be lost.

A firm-level redesign does not mean erasing the founder-led site that came before it. In the TC Architecture Firm work shown on the work page, the important planning question was not “how do we make this look newer?” The better question was how to help the site catch up to the company’s growth while preserving the human strength of the original message.

That kind of plan changes the order. You do not start by inventing a visual style from scratch. You identify the message that still matters, the proof that needs to move forward, the pages that should support stronger buyers, and the contact path that has to stay simple. Planning protects the continuity while making room for the next version.

A usable plan names dependencies before assigning deadlines.

Deadlines are necessary, but they do not make a redesign plan real. The plan becomes real when dependencies are visible. Content cannot be approved until positioning is clear. Design cannot finalize service pages until the content hierarchy is known. Redirects cannot be written until old URLs and new destinations are mapped. Analytics cannot be verified if access is discovered after launch. Each dependency should be documented before the project calendar pretends the work is linear.

The best planning document is usually shorter than people expect. It should name the core objective, protected assets, required pages, risky URLs, content owners, technical owners, launch blockers, and review dates. It should also make clear which decisions are strategic and which are production details. A logo placement debate should not receive the same weight as a question about removing a page that ranks and produces qualified leads.

Planning also prevents the redesign from becoming a hallway democracy. If every stakeholder can add pages, change priorities, or rewrite headlines late in the project, the plan is not strong enough. A good plan gives everyone a place to contribute early and a standard to judge late requests. That standard is not “do we like it?” It is whether the request protects existing value, clarifies the business, helps the buyer, supports search, or improves conversion.

The plan should remember why each major choice was made.

A redesign can last for months, and teams forget. They forget why a page stayed, why a service got its own URL, why a proof section moved higher, or why a form was shortened. A simple decision record prevents the project from reopening the same debate every two weeks. It does not need to be complex. One sentence per major decision is often enough.

That record becomes especially useful near launch, when pressure rises and late requests arrive. Instead of defending memory, the team can point back to the reason. Good planning creates continuity between the first strategic conversation and the final pre-launch checklist.