The Short Answer: 12 to 24 Weeks for Most Mid-Market Companies
A typical website redesign for a B2B company with 10 to 250 employees takes 12 to 24 weeks from kickoff to launch. That range is wide for a reason: the actual duration depends far more on your organisation’s readiness, decision-making speed, and scope clarity than on the technical complexity of the build itself. A 30-page marketing site with clear requirements can launch in 12 weeks. A 150-page site with multiple stakeholders, legacy content, integrations, and no documented requirements can easily stretch to 9 months or longer.
The uncomfortable truth is that most redesign timelines blow out not because of development problems, but because of scoping problems. Teams start building before they’ve agreed on what they’re building. That single issue accounts for the majority of delays we see across projects. If you take one thing from this article, let it be this: the time you invest in pre-project planning directly determines whether your redesign finishes on schedule or drags on for months beyond the original estimate.
What Actually Fills Those Weeks
When people ask how long a redesign takes, they’re usually picturing the visible work: new designs, new code, a shiny new homepage. But the visible work is roughly half the timeline. The other half is the planning, alignment, and preparation that makes the visible work possible. Here’s how those weeks typically break down for a mid-market B2B redesign.
Discovery and Requirements: 2 to 6 Weeks
This is where you define what the redesign actually needs to accomplish, what pages and content types exist, what integrations are required, which stakeholder groups need input, and what success looks like. Discovery is the phase most teams try to compress or skip, and it’s the phase that causes the most damage when done poorly. A thorough discovery process includes auditing your current site, interviewing internal stakeholders, reviewing analytics data, mapping user journeys, and documenting functional requirements. When this is done well, the rest of the project moves with surprising efficiency. When it’s rushed, every subsequent phase takes longer because people are making decisions without shared context.
Content Strategy and Information Architecture: 2 to 4 Weeks
Before anyone designs a single page, you need to know what content will exist on the new site and how it will be organised. This means creating a sitemap, defining page templates, writing or revising key messaging, and planning the content migration strategy for existing pages. Many teams underestimate this phase because they assume they’ll “just move the content over.” In practice, content migration is one of the most time-consuming parts of any redesign. Old content rarely fits new templates without significant editing, and someone has to make decisions about what stays, what goes, and what gets rewritten.
UX and Visual Design: 3 to 6 Weeks
Design typically starts with wireframes for key page templates, moves into high-fidelity mockups, and ends with a set of approved designs that the development team can build from. The biggest variable here is feedback speed. A design phase that should take three weeks can easily take six if stakeholders take a week to review each round or if new decision-makers appear mid-process with conflicting opinions. We consistently see that teams who designate a single design approver finish this phase in half the time of teams who route designs through a committee.
Development and Build: 4 to 8 Weeks
This is where designs become a functioning website. The development timeline depends on the platform choice, number of unique templates, custom functionality, and integrations with tools like your CRM, marketing automation platform, or e-commerce system. A WordPress marketing site with 5 to 8 templates and a HubSpot form integration is a very different build from a headless CMS site with custom API integrations, a client portal, and multilingual support. The former might take four weeks of development; the latter might take ten or more.
Content Population and QA: 2 to 4 Weeks
Once the site is built, content needs to be loaded into the CMS, images need to be sourced and optimised, forms need to be tested, and every page needs to be reviewed across browsers and devices. Quality assurance is the phase that gets squeezed when the project runs late, which is a dangerous habit. Launching a site with broken links, missing images, and inconsistent formatting creates a worse impression than the old site did. Budget real time for this. Two weeks is the minimum for a site with more than 30 pages.
Training and Launch: 1 to 2 Weeks
Your team needs to know how to use the new CMS before launch day. Training, final redirects, DNS changes, and the launch itself typically take a week or two. It sounds quick, but there are always last-minute items: a page someone forgot about, an executive who wants one more change, a redirect map that needs updating. Building a buffer here prevents the all-too-common scenario of a frantic midnight launch.
The Factors That Actually Control Your Timeline
If you’ve read through those phases and noticed the wide ranges, you’re asking the right question: what determines whether your project lands at the short end or the long end? It’s rarely the technical difficulty. These are the real factors.
How Clear Your Requirements Are Before You Start
This is the single biggest predictor of timeline accuracy. When a team starts a redesign with a vague brief like “we need a modern website that generates more leads,” every phase takes longer because fundamental questions keep surfacing during design and development. What does modern mean? What counts as a lead? Which pages matter most? What integrations are required? These questions should be answered before the project starts, not discovered halfway through. Across our projects, the ones that finish on schedule almost always share one trait: they invested in structured scoping before engaging a build team. If you want a deeper look at why this matters so much, our blueprint-first guide walks through the entire methodology.
The Number of Decision-Makers Involved
Every additional person in the approval chain adds calendar time to your project. Not because their input is bad, but because scheduling reviews, resolving conflicting feedback, and reaching consensus all take time. A project with one empowered decision-maker can move through design reviews in days. A project where designs go through the marketing director, the VP of sales, the CEO, and the head of product will add weeks to the timeline, often without improving the outcome. The most effective approach we’ve seen is to gather input broadly at the start, then delegate approval authority to one or two people for the duration of the build.
Content Readiness
Here’s a pattern we see repeatedly: the design and development phases finish on time, and then the project stalls for weeks or months because content isn’t ready. Content is the most common bottleneck in website redesigns. Someone has to write it, someone has to approve it, and it has to work within the design. If you’re planning to write new copy for your site (and you should be, if the current copy isn’t performing), start that process during the design phase, not after development is complete. Treat content production as a parallel workstream, not a task you’ll get to later.
Platform Complexity and Integrations
A redesign that stays on the same CMS with no new integrations is fundamentally faster than one that involves a platform migration. Moving from one CMS to another adds 2 to 6 weeks depending on the platforms involved, the amount of content being migrated, and the complexity of any custom functionality that needs to be rebuilt. Similarly, each integration with an external system (CRM, marketing automation, ERP, payment processor) adds both development time and testing time. A site that needs to sync contact data with Salesforce, pull product information from an ERP, and process payments through Stripe is a meaningfully different project from a site with a contact form.
Feedback Turnaround Time
This one is mundane but powerful. Most project delays are measured in days of waiting, not days of working. If your team takes five business days to review a design comp instead of two, and that happens four times during the design phase, you’ve added three weeks to the project without anyone noticing. Set clear expectations at the start: all feedback will be consolidated and returned within 48 hours of delivery. Enforce that standard. It sounds simple, but it’s the single easiest way to keep a project on schedule.
Why Most Timeline Estimates Are Wrong
If you’ve received proposals from agencies or freelancers, you’ve probably noticed that their timeline estimates vary wildly. One says 8 weeks, another says 16, and a third says “it depends.” None of them are lying; they’re just estimating based on different assumptions.
The 8-week estimate might assume you’ll provide all content on time, have a single decision-maker, need no custom integrations, and make no significant changes after design approval. The 16-week estimate might build in buffer for content delays, multiple stakeholder reviews, and the inevitable “one more thing” requests. The problem isn’t the estimates; it’s that the assumptions behind them are rarely made explicit.
This is why we advocate for separating the scoping process from the build process. When you lump discovery, requirements definition, and project planning into a proposal written before anyone truly understands the project, you get estimates based on guesses. When you invest in structured scoping first, you get estimates based on documented requirements, identified integrations, and agreed-upon content plans. The second approach produces timelines that are accurate to within a week or two. The first produces timelines that are accurate to within a quarter.
Typical Timelines by Project Type
While every project is different, these benchmarks reflect what we consistently see across mid-market B2B companies. They assume a reasonably organised team with responsive stakeholders.
- Simple marketing site refresh (15 to 30 pages, same CMS, no new integrations): 8 to 12 weeks
- Full marketing site redesign (30 to 75 pages, new design system, minor integrations): 12 to 18 weeks
- Redesign with platform migration (any size, moving to a new CMS): 16 to 24 weeks
- Complex redesign with custom functionality (portals, dashboards, e-commerce, multi-language): 20 to 32 weeks
- Enterprise-scale redesign (250+ pages, multiple stakeholder groups, heavy integrations): 6 to 12 months
These ranges assume that content is produced in parallel with design and development. If you plan to write all content after the site is built, add 4 to 8 weeks to each range.
How to Shorten Your Timeline Without Cutting Corners
Speed and quality aren’t mutually exclusive if you focus on removing waste rather than rushing work. The fastest redesign projects we’ve seen share these characteristics.
They invest more time upfront in scoping. It sounds counterintuitive, spending more time to finish faster. But a two-week structured discovery phase can save six or more weeks during design and development by eliminating ambiguity, aligning stakeholders early, and preventing the mid-project pivots that derail timelines. The teams that rush straight into design because they “don’t have time for planning” are almost always the teams that finish last.
They limit the approval chain to two people maximum. Broad input at the beginning is fine. In fact, it’s recommended. But once the project is underway, route approvals through one or two designated people who have the authority to make binding decisions. Every additional reviewer adds calendar time and increases the risk of contradictory feedback.
They start content production early. The most efficient projects we’ve worked on treated content as a first-class workstream that started during discovery and ran in parallel with design. By the time development was complete, the content was ready to load. By contrast, the longest projects were almost always ones where content was an afterthought.
They define “done” before they start. Scope creep is the most reliable way to blow a timeline. Every project should have a documented list of what’s included and, equally important, what’s not included. When someone requests a new feature mid-project, the response should be: “We can add that to phase two” rather than “Let me see if we can squeeze it in.” Phase thinking protects timelines.
They commit to rapid feedback cycles. A 48-hour feedback window for all deliverables, with consolidated comments from all stakeholders, is the single most impactful operational decision you can make. Get this right and you will shave weeks off the project without anyone working harder.
The Hidden Phase Nobody Talks About: Pre-Project Alignment
Most timelines you see in proposals start at “project kickoff.” But there’s a phase before kickoff that often takes longer than anyone expects: getting your own organisation aligned on what the project should accomplish and how much you’re willing to invest.
In our experience, mid-market companies spend 4 to 12 weeks in this pre-project phase. They’re socialising the idea internally, gathering budget approval, evaluating potential partners, and trying to get the leadership team to agree on priorities. This phase is invisible in most timeline discussions, but it’s real calendar time. If you’re reading this article, you’re probably in this phase right now.
The most productive thing you can do during this period is document your requirements, even roughly. Write down the business goals, the pages you know you need, the integrations that are non-negotiable, and the internal constraints (budget range, launch deadline, team availability). This document doesn’t need to be perfect. It just needs to exist. Having it will make every subsequent conversation with potential partners faster and more productive, and it will give you a far more accurate basis for evaluating timelines and costs.
What Happens When a Redesign Runs Late
Late projects don’t just cost more time. They cost more money, more goodwill, and more organisational energy. When a redesign drags on, several predictable things happen. Team morale drops as the project starts to feel like it will never end. Stakeholder confidence erodes, making it harder to get timely approvals because people disengage from a project they’ve lost faith in. The competitive gap widens as the months tick by with your old site still live. And in many cases, the final product suffers because everyone just wants it to be over, so quality standards quietly lower in the last stretch.
The financial cost is real too. A project that was scoped at 16 weeks but takes 28 weeks will almost certainly cost more than the original budget, whether through change orders, additional agency hours, or the hidden cost of your team spending an extra three months managing the project instead of doing their actual jobs.
What to Do Right Now
If you’re planning a website redesign, here’s how to set yourself up for a realistic and achievable timeline. First, audit your current site: count your pages, list your integrations, and note any functionality that must be preserved. Second, identify your decision-makers and get their explicit commitment to a feedback turnaround standard. Third, assess your content situation honestly. Do you have usable content, or does most of it need to be rewritten? If it needs rewriting, who will do it and when? Fourth, separate your scoping from your build. Invest in a structured discovery process that gives you documented requirements and validated scope before you commit to a build timeline. This one step will do more to protect your timeline than any other action you can take.
A well-scoped redesign with aligned stakeholders and a clear content plan will consistently finish within its estimated timeline. A poorly scoped redesign with unclear requirements and fragmented decision-making will consistently run over. The timeline isn’t something that happens to you. It’s something you shape through the decisions you make before the project starts.
Ready to get started?
