A small business redesign typically takes 6 to 12 weeks, a mid-size marketing site runs 3 to 6 months, and an enterprise project can stretch to a year. The single biggest variable isn’t design or development: it’s how quickly your team supplies content and approves each stage. Once you know which band fits your project, the stage breakdown below helps you build a realistic calendar around it.

TL;DR:

• Content readiness and timely approvals can extend small or mid-size redesigns by several weeks, especially if they are delayed during development.
• Phased launches reduce risk and allow issues to be caught early, but require careful planning and a flexible schedule.
• Accessibility audits and fixes should be integrated early and throughout the project, as they often cause delays if left until the end.
• Keeping to a strict review calendar and preparing content ahead of development can prevent schedule slippage and improve project flow.
• Post-launch monitoring and support are crucial, with ongoing checks of Web Vitals and analytics to prevent issues from escalating after the site goes live.

Table of Contents

• 1. Typical timelines by website type
• 2. The stage by stage schedule you can actually plan around
• 3. Factors that stretch or shrink your timeline
• 4. How to keep your redesign on schedule
• 5. Accessibility requirements that affect your schedule
• 6. The launch checklist and your 30/60/90 day routine
• What clients underestimate about their own timeline
• Where CTA Systems fits into your redesign
• Sources
• FAQ

1. Typical timelines by website type

Not every redesign carries the same weight, so it helps to place your project in the right category before you set expectations with your team or your board. Here’s how the common bands break down.

• Quick refresh (2 to 4 weeks): updated visuals, new imagery, minor copy tweaks, no structural changes.
• Small brochure site (6 to 12 weeks): typically 5 to 15 pages, a new design system, light content rewriting, and standard integrations like a contact form or booking widget.
• Mid-size marketing site (3 to 6 months): dozens of pages, a content migration, CRM or email integrations, and often a blog or resource hub that needs restructuring.
• Ecommerce site (4 to 8 months): product catalogue migration, payment gateway testing, inventory syncing, and considerably more QA because every broken link or checkout bug costs revenue.
• Complex or enterprise project (6 to 12 months): multiple stakeholders, legacy system integrations, accessibility audits, and often a phased rollout across regions or departments.

These bands assume reasonably ready content and a manageable approval chain. Where either of those breaks down, even a brochure site can drift into mid-size territory. As a decision rule: if your business can tolerate a short window where old and new pages coexist, a phased launch (shipping key pages first, then rolling out the rest) spreads risk and lets your team catch problems early. If the whole site must switch over on one date, a big-bang launch demands far tighter testing beforehand, because there’s no room to patch quietly after the fact.

2. The stage by stage schedule you can actually plan around

Every redesign, regardless of size, tends to move through the same seven phases. Mapping your own project against these gives you a working calendar rather than a guess.

1. Discovery (1 to 3 weeks): an audit of your existing site, agreed KPIs, and stakeholder alignment on scope. The output is a signed-off brief, not a design.
2. Information architecture and wireframes (1 to 3 weeks): content-first wireframing, where you map real page content to layout before visual design starts, avoids rebuilding wireframes later when copy doesn’t fit.
3. Design and prototyping (2 to 6 weeks): budget at least two to three rounds of feedback. Case study evidence from NN/g shows that testing prototypes with users early catches usability problems before they become expensive rebuilds, so the extra round upfront pays for itself later.
4. Content creation and migration (2 to 8 weeks, run in parallel): writing new copy, sourcing imagery, and migrating existing pages usually happens alongside design, not after it, since waiting for a finished design before starting content is one of the most common causes of delay.
5. Development and integrations (3 to 10 weeks): platform setup, template building, third-party integrations (CRM, payment, booking), and a working staging environment for review.
6. Testing and QA (1 to 3 weeks): functional testing, cross-device checks, accessibility testing against WCAG 2.2, and regression testing to confirm fixes haven’t broken something else.
7. Launch (1 to 2 days, plus preparation): redirects live, analytics tracking confirmed, forms tested, and an immediate post-launch check of every critical page.

Treating these as sequential rather than overlapping is where most timelines quietly balloon. Content and design should run together wherever possible, and testing should start well before development finishes, not after.

3. Factors that stretch or shrink your timeline

Once you have a baseline, a handful of variables push it in either direction. Knowing which ones apply to your project lets you adjust your calendar honestly rather than hopefully.

• Content and asset readiness is the biggest single delay source: a redesign with finished copy and images at kickoff can run weeks faster than one where content is written during the build.
• Approval processes slow things down in proportion to how many people sign off. Agency experience across the industry suggests stakeholder approvals commonly add a 30 to 50% buffer on top of the working timeline.
• Technical complexity, including custom integrations, legacy data migrations, and bespoke features, adds development and testing time that a template-based site never encounters.
• Accessibility and compliance work, particularly external audits, can become a bottleneck if they’re arranged too late.
• SEO and migration risk rises sharply when URLs change; missing redirects or an unmapped sitemap can cost search visibility that takes months to recover.
• Team configuration, especially handoffs between an in-house team and outside contractors, adds coordination time that’s easy to underestimate.

Pro Tip: Ask for all core content, including final copy and approved imagery, before development starts, not during it.

4. How to keep your redesign on schedule

Most schedule slippage is avoidable, and the fixes are procedural rather than technical.

1. Name one final decision-maker and book fixed review slots into the calendar at kickoff, so feedback doesn’t drift into open-ended email threads.
2. Prepare or commission content in parallel with design, agreeing scope and cost upfront if you’re contracting copywriting out, so the site isn’t waiting on a blank page.
3. Test prototypes with real users early. NN/g’s case study on iterative prototyping found that early rounds of testing prevented the kind of late-stage rework that derails a launch date.
4. Phase the launch if your date is fixed: ship the highest-traffic or highest-value pages first, then roll out the rest once they’re stable.
5. Run a short toolkit of process habits: a shared review calendar, a content freeze date before development, and a formal staging sign-off before anything goes live.

None of this shortens the work itself. It just stops the work from waiting on people.

5. Accessibility requirements that affect your schedule

Accessibility isn’t a late add-on if you want to avoid a last-minute scramble. GOV.UK guidance treats WCAG 2.2 AA as the expected minimum standard for public sector websites and apps, and it’s a sensible baseline for any business site too.

• Book external accessibility audits early: they often take time to arrange, and leaving them until after development is finished creates a bottleneck.
• Run accessibility testing during your beta phase, not only at the very end, so problems surface while there’s still time to fix them cheaply.
• Consider a tested design system such as the GOV.UK Design System: adopting proven, pre-audited components can cut both development and audit time compared with building custom UI from scratch.
• Fold accessibility checks into your regular QA cycle and into the 30, 60 and 90-day post-launch reviews, so fixes don’t stop once the site goes live.

6. The launch checklist and your 30/60/90 day routine

Launch day isn’t the finish line, it’s the start of the phase where most preventable damage happens.

1. On launch day, confirm redirects are working, analytics and tracking are firing correctly, forms submit properly, Core Web Vitals are within acceptable range, and the site behaves correctly across devices.
2. In the first 14 days, check daily for crawl errors, unexpected traffic drops, search indexing issues, and broken functional flows like checkout or contact forms.
3. At 30, 60 and 90 days, review search performance, conversion paths, and any recurring user complaints, then make iterative fixes rather than a second big rebuild.
4. Where a domain migration is involved, SEO migration guidance recommends allowing at least 90 days for search rankings to stabilise and monitoring closely throughout, which is one reason phased rollouts are often safer than a single big-bang switch when a migration is also happening.

What clients underestimate about their own timeline

The biggest risk to any redesign schedule isn’t the design work, it’s how quickly the client can supply content and make decisions. Two habits predict success more reliably than anything else: appointing one person with final sign-off authority, and having core content ready before development begins, not during it.

— Will

Where CTA Systems fits into your redesign

A redesign involves more moving parts than most teams expect, and hosting, security and monitoring are usually the parts that get the least attention until something breaks. CTA Systems handles web design and hosting, domains and SSL as a single, coordinated piece of the project rather than a separate afterthought bolted on near launch.

That matters most in the weeks after launch, when your new site needs watching, not just building. Our Care Plans cover the ongoing monitoring, patching and support that a 30/60/90-day review depends on, so someone is actually checking Core Web Vitals, uptime and functionality rather than hoping nothing goes wrong. If you’re planning a redesign and want one supplier handling design through to post-launch monitoring, get in touch through CTA Systems to talk through your timeline.

Sources

• Get to WCAG 2.2 faster with the GOV.UK Design System
• Case study: iterative design and prototype testing of the NN/g homepage — NN/g
• The website redesign process, done right — Refact

FAQ

How long should a website redesign take?

Most small business redesigns take 6 to 12 weeks, while mid-size sites typically run 3 to 6 months and enterprise projects can take up to a year. The main factor that changes this is how quickly your team supplies content and approves each stage, not the design work itself.

What are the 7 stages of the web development cycle?

The typical stages are discovery, information architecture and wireframes, design and prototyping, content creation and migration, development and integrations, testing and QA, and launch. Each stage has its own deliverable that needs sign-off before the next one can properly begin.

How do I announce a website redesign?

There’s no single required method, but most businesses announce a redesign through an email to existing contacts, a short note on social channels, and sometimes a banner on the old site in the days before switchover. The more useful step is technical: confirm redirects and analytics are working before you tell anyone the new site is live.

Is web design still worth it in 2026?

A well-planned website remains one of the few assets a business fully controls for attracting and converting customers, which keeps redesign work relevant regardless of shifting trends. The value comes less from novelty and more from getting the fundamentals right: fast pages, clear content, accessible design and a stable post-launch routine.