Most organization-wide website redesigns take four to nine months from discovery through launch. A smaller site with prepared content and fast approvals may launch in three to four months. A large government, nonprofit, association, university, or enterprise website can take nine to eighteen months or longer, especially when it includes extensive content migration, integrations, accessibility requirements, or multiple approval groups.
The honest answer is not a single number. It is a range based on what must be decided, created, migrated, tested, and approved.
For a communications leader, that distinction matters. A redesign schedule is not only a production calendar. It affects campaign planning, staff capacity, budget confidence, public trust, and the date you can responsibly announce to leadership.
What is a realistic website redesign timeline?
A realistic timeline depends on the size and risk of the project, not simply the number of templates being designed. The following ranges are useful for early planning, but they should not replace discovery.
| Redesign type | Typical timeline | Common characteristics |
|---|---|---|
| Focused marketing site | 3–4 months | Limited page count, few integrations, content mostly ready, one approval group |
| Mid-sized organizational website | 4–9 months | User research, information architecture, custom design, CMS development, content migration, accessibility and quality testing |
| Large or high-risk digital platform | 9–18+ months | Thousands of pages, multiple audiences, complex integrations, governance requirements, procurement constraints, many stakeholders |
These are planning ranges, not guarantees. HubSpot has reported that many redesigns take three to four months and recommends beginning planning 90 to 120 days before the desired launch date, while emphasizing that larger and more complex projects need more time. That benchmark is useful for a relatively straightforward redesign; public-sector and enterprise projects often require a longer runway because their content, compliance, and approval needs are more demanding. (HubSpot)
If a vendor gives a firm launch date before asking about content volume, decision-makers, integrations, accessibility, procurement, and migration, the estimate is probably based on assumptions you have not seen.
What happens during each phase of a website redesign?
A redesign usually moves through six overlapping phases. Agile delivery allows some work to happen in parallel, but it does not eliminate the decisions each phase requires.
| Phase | Typical duration | What the organization must provide or approve |
| Discovery and alignment | 2–5 weeks | Goals, audiences, analytics access, stakeholder input, success measures, decision rights |
| Content and information architecture | 3–8 weeks | Content inventory, page priorities, navigation decisions, ownership and migration rules |
| UX and visual design | 4–8 weeks | Wireframe feedback, brand direction, component and template approvals |
| Development and integration | 6–14 weeks | CMS configuration, feature decisions, integration access, technical review |
| Content migration and training | 4–12 weeks | Final copy, redirects, media cleanup, editor participation and acceptance |
| Testing, launch, and stabilization | 3–6 weeks | Accessibility review, quality assurance, launch approval, support coverage |
Discovery and alignment
Discovery translates “we need a better website” into an agreed definition of success. The team identifies priority audiences, top tasks, organizational goals, technical constraints, and measurable outcomes.
This phase is also where the project should establish who recommends, who approves, and how quickly decisions must be made. Agileana’s Digital Strategy services emphasize stakeholder alignment, user research, and actionable roadmaps because unresolved priorities rarely disappear. They usually return later as change requests.
Content and information architecture
Content is often the largest schedule risk. A new design cannot fix outdated, duplicated, ownerless, or poorly organized information by itself.
The team needs to decide what to keep, revise, combine, archive, and remove. It also needs a clear navigation structure and labels that make sense to users rather than mirroring an internal org chart. If the current site has thousands of pages, the content effort may continue through design and development.
UX and visual design
Design includes more than a homepage concept. It covers user flows, page layouts, reusable components, mobile behavior, interaction patterns, and accessibility requirements.
A component-based system can speed future publishing because communications teams can build approved page layouts without requesting a developer for every campaign. Agileana’s Web Design practice brings together user research, information architecture, visual consistency, responsive design, and accessibility.
Development and integration
Developers turn approved components and requirements into a working content management system. This phase may include search, forms, analytics, authentication, constituent databases, donation or membership tools, multilingual features, and third-party services.
The timeline grows when integrations are undocumented, access is delayed, or another vendor controls a required system. Web Development should therefore be planned around the organization’s broader digital ecosystem, not treated as an isolated build.
Content migration and training
Migration can be automated, manual, or a mix of both. Automation moves volume quickly, but it cannot decide whether a page is still useful, whether its title is clear, or whether an old PDF should remain online.
Training should happen before launch, with enough time for editors to practice real publishing tasks. That reduces the risk of a technically successful launch followed by a communications bottleneck.
Testing, launch, and stabilization
Testing should cover functionality, content, mobile layouts, browsers, performance, redirects, analytics, security, and accessibility. Accessibility belongs throughout the project, but final testing confirms that templates, components, and migrated content work together.
Launch also needs a rollback plan, named decision-makers, monitoring, and support coverage. Ongoing Web Operations helps maintain accessibility, security, performance, and compliance after the redesign is public.
What makes a website redesign take longer?
The biggest delays usually come from organizational uncertainty rather than the act of writing code.
Content is not ready. If subject-matter experts begin rewriting hundreds of pages late in the project, migration and review can overtake the build.
Too many people can veto, but no one can decide. Broad participation is valuable. Unclear decision authority is not. A small approval group should make final calls against agreed goals.
The scope changes after design or development begins. A new portal, integration, language, or workflow may be valuable, but it changes the work. Teams need a visible process for assessing schedule and budget effects before accepting it.
Accessibility is postponed. Fixing systemic accessibility problems at the end is slower and riskier than including accessibility in research, design, development, content, and testing from the beginning.
The old website is poorly understood. Missing inventories, undocumented integrations, unknown form owners, and incomplete analytics create surprises. A technical and content audit reduces that uncertainty.
Feedback arrives slowly or conflicts. A five-day review that takes three weeks does not merely add two weeks once. It can disrupt the availability and sequence of several teams.
The launch date is tied to a campaign without schedule protection. If the date truly cannot move, scope must be able to move. A phased launch can protect the campaign while lower-priority features follow later.
How can communications leaders keep the redesign on schedule?
Start by choosing a target window, not announcing a public date. Confirm the date only after discovery has tested the assumptions behind it.
Then create a simple governance model:
- Name one executive sponsor and one day-to-day product owner.
- Define who approves strategy, content, design, technology, accessibility, and launch.
- Give reviewers short, published response windows.
- Require feedback to connect to user needs, project goals, evidence, or compliance requirements.
- Maintain one prioritized list of requirements and decisions.
Protect staff time for content. Your vendor can provide inventories, templates, migration support, and editorial guidance, but the organization still owns policy decisions and subject-matter accuracy.
Plan for risk explicitly. Ask prospective partners:
- What assumptions does this timeline depend on?
- Which client decisions are on the critical path?
- How will accessibility be tested throughout the work?
- How will scope changes affect the launch date and budget?
- What happens if content is late?
- What is included in launch support and post-launch stabilization?
Finally, consider whether every feature must launch at once. An essential first release can support priority audiences and campaigns while the team adds lower-priority capabilities through planned iterations. Agile should create transparency and manageable releases; it should not be used as an excuse for an undefined schedule.
Agileana’s work with mission-driven and public-sector organizations shows why planning, design, development, and operations need to connect. The Visit the National Archives case study is one example of work spanning web design, development, project management, and strategic communications.
How early should you begin planning?
For a desired launch in the next six months, begin discovery now. For a large, complex, or procurement-heavy site, begin planning nine to eighteen months before the target date.
Work backward from moments that cannot move—annual meetings, enrollment periods, legislative deadlines, campaign launches, funding announcements, or fiscal-year constraints. Reserve time for procurement and contracting before the delivery schedule begins. Also protect several weeks after launch for stabilization rather than treating launch day as the end of the project.
The safest timeline is not the longest one. It is the one that makes assumptions visible, assigns decisions, includes content and accessibility from the start, and gives leadership an honest view of tradeoffs.
Ready to turn a target date into a defensible plan?
If your organization is considering a redesign, Agileana can help define the scope, risks, decision process, and realistic delivery range before you commit to a public launch date. Explore our Digital Strategy and Web Design capabilities, or contact Agileana to discuss your goals.
Frequently Asked Questions
Can a website be redesigned in three months?
Yes, if the scope is focused, content is ready, integrations are limited, and decision-makers can review work quickly. A three-month schedule is risky for a large site or one requiring extensive migration, research, accessibility remediation, or custom integrations.
How long does a small website redesign take?
A focused marketing website may take about three to four months. The schedule depends less on page count alone than on how much content, custom functionality, stakeholder review, and testing the project requires.
How long does a large website redesign take?
Large government, nonprofit, association, university, or enterprise redesigns commonly require nine to eighteen months or longer. Content volume, procurement, integrations, accessibility, security, and multi-level approvals can all extend the schedule.
What is the most common cause of website redesign delays?
Late content and slow or unclear approvals are among the most common causes. Teams reduce these delays by assigning content owners, setting review deadlines, and giving a small group clear decision authority.
Should accessibility testing happen only before launch?
No. Accessibility should shape research, design, development, content, and quality assurance from the beginning. Final testing is still necessary, but postponing accessibility until the end can create expensive rework and launch risk.