Has anyone given you a straight answer about how long your website redesign will take?
The usual response is a range wide enough to be useless. Three to six months. It depends. Somewhere between eight weeks and next year. That vagueness isn't always evasion. Most of the variance in a redesign timeline has nothing to do with the agency's speed, and everything to do with a handful of decisions that get made, or avoided, in the first two weeks. If you're still deciding whether a redesign is due at all, how often to redesign a website is the question to settle first.
The honest answer
A B2B website redesign for an established company runs six to eight weeks from kickoff to launch when the content is being written by the people building the site. That's our own build window, and it holds because we write the copy rather than sending a spreadsheet of empty cells to a client who already has a job.
The projects that stretch to four and five months are almost never stuck in design or development. They are waiting on words.
Where the weeks go in a website redesign timeline
Weeks one and two: diagnosis and positioning. What the site needs to say, to whom, and what it has to prove. This is the phase people are most tempted to compress, and compressing it is the single most reliable way to make the project late. Every unresolved question here becomes a revision round later, when changing it costs ten times more.
Weeks three to five: content and design together. Pages get written and designed as pages, not as copy poured into a template afterward. You review real pages rather than a wireframe you have to imagine your way into.
Weeks six to eight: build, migration and launch. The build is the most predictable part of the whole project. What makes this stretch is migration work that wasn't planned in week one: the redirect map, the URL inventory, the ranking baseline. Those are project management, not engineering, and they're the difference between a launch and a traffic cliff.
How long a rebuild takes, and why it's a different number
A lot of people asking about a redesign timeline are really asking about a rebuild. The two words get used interchangeably, which produces two different errors. The expensive one is buying a rebuild when a redesign would have done the job. The other is asking how long a redesign takes when the project you're describing is a rebuild. That second one is what this is about.
A redesign changes the surface: what the site says, how it's organized, how it looks, on the platform you already run. A rebuild replaces the foundation underneath, the platform and the code and the architecture, and it usually ships a new design along with it.
Six to eight weeks is the redesign number, and only when the agency writes the content. Start a rebuild from that window and add the migration underneath it. In our experience the migration is the larger half on anything with real content volume or a customer login, which puts a rebuild in months rather than weeks. The two tracks overlap, so it isn't simple addition, and what sets the date is the longest chain rather than the sum. Five things move it, and it's worth asking any agency to price the design work and the migration work separately rather than quoting you one figure for both.
The platform decision, made in the right order. A rebuild adds a question a redesign never asks: what should this run on. Teams often answer it first, because it feels like the concrete decision. That's the expensive order, and it's the one our comparison page calls the timing trap, because you end up paying to move content you're about to replace. Answered in the right order, after the positioning, it still takes real time. It's a procurement decision rather than a design one, and it tends to involve IT, a contract and a budget line that a marketing redesign never touches.
Rebuilding everything the old site could do. This is usually the largest item and the one most often left out of a timeline. Every custom form, the search, a customer login, a quote configurator, a parts lookup: assume none of it carries over until somebody checks each one. Some will, because a hosted search service or an embedded form can often be re-pointed. The rest gets built again on the new platform, which is engineering scope rather than reconnection work. It's also where outside dependencies land, because the CRM connection or the ERP feed waits on a CRM administrator, a vendor, sandbox credentials, an API key somebody has to approve. You can find every one of them in week one if someone looks, and someone should. Finding them early doesn't make them fast.
Make sure verification is priced with the rebuild work, not after it. Everything rebuilt has to be tested end to end before launch: every form submitted for real, analytics and tag management re-implemented, the login exercised, devices and browsers checked. That's where the bug tail lives, and it's the phase most likely to slip, because it's the first point where any gap in what was rebuilt becomes visible. A quote that prices the building and not the checking has left a real piece of the job out.
The content model, then the migration. In a redesign you're changing what's on pages that already exist. In a rebuild, somebody first has to design how content will be structured in the new system, the content types and fields and how they relate to each other, because most older sites don't really have a model at all. Only then can anything move. What drives the time after that is volume and condition: inventorying several hundred legacy pages, deciding which ones die, and hand-handling everything that doesn't fit the model. If the site has accounts, that's a second and separate job, because customer records, order or quote history and saved settings move on their own track and usually carry a security review with them. Then it usually moves more than once, because anything published on the old site during the project has to come across too, which is what the freeze and the final pass at the end are for.
Cutover, because the old site never stops. A redesign goes live by replacing what visitors see. A rebuild has a real switch-over: staging, DNS, the content freeze, that last migration pass, and a rollback plan if it goes wrong.
The redirect work also gets heavier. Both projects need the URL inventory, the redirect map and a ranking baseline, as the section above says. The difference is size: a redesign that keeps most of its URLs produces a short map, and a rebuild usually changes the structure outright, so the map is long and the baseline is what tells you afterwards whether the move worked.
Whether you need a redesign or a rebuild is worth settling before you ask anyone how long it'll take, because a timeline quoted against the wrong project is expensive in a way that only shows up later. Website redesign vs rebuild walks through the decision.
The four things that actually make a redesign late
Nobody owns the decision. If approvals need three people who are rarely in the same room, add weeks. Not because the work is slow, but because the work stops. The most useful thing you can do before kickoff is name one person who can say yes.
The content is the client's job. This is the big one. An agency that hands you a content template has moved the critical path onto the person with the least time. Ask directly who writes the copy, and treat "we'll collaborate on it" as meaning you. If that's the project you remember, the next one may not need as much of your time.
Scope arrives late. The integration that surfaced in week five. The eleven product pages that turned out to be forty. Both are discoverable in week one if anyone looks.
Approval happens at the end. If the first time leadership sees the work is the week before launch, you aren't reviewing, you're re-doing. Milestone reviews exist so the expensive surprise happens while it's still cheap.
What the delay costs while you wait
The instinct is to treat a slipping timeline as an inconvenience. It's a little worse than that, because the site you have is still working the whole time.
When we analysed more than 55,000 US B2B websites, 49% were visibly dated, with a median last redesign more than seven years ago. Every additional month is another month of buyers forming their first impression from the page you already decided wasn't good enough. We wrote about that compounding in every quarter you put off the rebuild, the rebuild gets bigger.
A test you can run before you sign anything
Ask a prospective agency two questions and listen for specifics.
Who writes the content, and what happens if we're slow? A firm that has thought about this has an answer involving interviews and drafts. A firm that hasn't will say something about a collaborative process.
What is on the critical path in week one? If the answer is design, the migration work is going to surface late. If the answer involves URL inventory and positioning, they've done this before.
Neither question is about speed. Both predict it better than any number in a proposal.
If you're comparing agencies, our website RFP template sends each of them the same brief in writing: it settles who writes the copy up front and requires every proposal to say how it handles the URL inventory and redirects. The answers that stay vague in writing tell you the same thing.
