Every redesign checklist on the internet is written for a company with one decision-maker. Pick a platform, agree a direction, build it, launch it. That checklist is fine, and it stops being fine somewhere around the point where the site is carrying real revenue.
What changes is not the design work. It is almost the same design work. What changes is that the site has become load-bearing — for organic pipeline, for integrations other teams depend on daily, for pages legal has opinions about — and a redesign of a load-bearing system is a migration, not a blank page. Most of the damage I have seen on projects this size came from treating it as the latter.
The number that explains the whole problem
Forrester's 2024 State of Business Buying research puts the average B2B purchase decision at 13 internal stakeholders, with nearly 89% of those decisions crossing more than one department.
A redesign at this revenue band is exactly that kind of decision, whether or not anyone has named it one. Nobody sends a memo announcing that the project now has a buying committee. It simply turns out, in week six, that the CMS choice needs IT sign-off, the cookie banner needs legal, and a regional office has been quietly assuming their pages are staying exactly as they are.
That is the actual difference between a €2M redesign and a €5M+ one. The production work is nearly identical. The wrapper around it is a different project.
Scope creep stops being annoying and starts being expensive
PMI's Pulse of the Profession research has repeatedly found scope creep affecting a large share of projects — 52% in its 2018 survey, up from 43% five years earlier. A redesign with a dozen stakeholders, each wanting one more thing, is the textbook case.
The instinct is to fix this with discipline during the project. That does not work, because the additions do not arrive as scope changes. They arrive as reasonable requests from people who were not in the scoping conversation and genuinely did not know it had happened.
The fix is earlier and duller: decide before kickoff who is allowed to add scope. Not who is consulted, not who is copied — who can actually add. In practice that is one person, and naming them is a ten-minute conversation that saves a month.
The same shape applies to approvals. A 2025 survey of 500 marketing and creative professionals found 74% say the approval process takes more effort than the creative work under review, and over 60% lose up to a full workday per week chasing approvals. On a five-approver project that does not divide, it compounds. One named approver per phase beats five people on a thread, every time.
Treat it as a migration and the technical list writes itself
Here is the part that is genuinely our problem as engineers rather than a governance abstraction.
If the current site earns organic traffic, that traffic is an asset with a specific failure mode, and preserving it is a deliverable with an owner — a redirect map, a pre-launch crawl, metadata that survives the platform change. It is not a task you discover in launch week. I wrote up the mechanics of that separately in redesigning a site without losing its SEO, because it is the single most common way a technically clean launch turns into a bad quarter.
Then inventory what else the site is quietly load-bearing for. A CRM or ERP integration a sales team uses daily. An analytics setup finance forecasts against. Compliance pages nobody wants to accidentally drop. The reliable way to get this list is to audit it, not to ask whoever has been at the company longest to remember.
And three decisions are disproportionately expensive to reverse once the build starts: the platform choice, settled with IT in the room rather than discovered mid-build; the regional and language architecture, decided as structure before a single template exists, because retrofitting multilingual onto a single-language build is close to a second project; and accessibility, which is now a dated legal obligation across the EU rather than a nice-to-have.
Capture the baseline, or lose the argument you have not had yet
This is the cheapest item on the list and the most frequently skipped.
A redesign at this size will be judged after launch, by people who were not in the room for the decisions, against numbers nobody wrote down beforehand. So write them down: organic sessions and conversions for the top fifty landing pages, conversion rate per template, average lead or order value, and current Core Web Vitals field data.
Export it. Do not trust that the analytics property will still be comparable — a replatform frequently changes tracking, and a baseline you cannot reproduce after launch is not a baseline.
The reason is not reporting hygiene. Every migration has a re-crawl dip. Without a recorded starting point, three weeks of entirely normal fluctuation reads to a committee as proof the project failed, and the reaction to that — reverting design decisions, second-guessing the redirect map — does far more damage than the dip. With a baseline, the same three weeks is a line on a chart visibly returning to where it started.
The second workstream nobody estimates
At this size the project acquires a parallel track that has nothing to do with design and is almost never in the original estimate. A vendor security questionnaire from IT. A data processing agreement and a records-of-processing update, particularly where forms, analytics or a CRM integration change. Cookie consent legal actually signs off on rather than a banner installed on launch day. Procurement onboarding, which at some companies is weeks before an invoice can be raised.
Accessibility belongs here too, and it is dated: the European Accessibility Act has applied across all 27 member states since 28 June 2025. The most commonly missing piece on sites that otherwise meet the requirements is the published accessibility statement — which is a document, not code, and therefore nobody's ticket.
None of this work is hard. All of it consumes calendar time from people who do not report to the project. That is precisely why it belongs in the plan at kickoff instead of being discovered in launch week.
What this does to the timeline
The production work stretches far less than people assume. A multi-page rebuild still runs roughly the same six-to-fourteen-week window as any business site, and even a genuinely custom platform with heavy integrations is realistically six months of build, not years.
What stretches is the governance wrapped around it. If production is six to fourteen weeks and every phase needs sign-off from a five-person committee with its own meeting cadence, four to nine months end to end is the honest band — not because the work takes that long, but because the approval layer does.
Saying that number out loud at kickoff is uncomfortable and it is the single most useful thing you can do for the project. The alternative is a fourteen-week estimate that everyone stops believing in month three, at which point every subsequent conversation is about the schedule rather than the work.
The short version
Name the approvers before design starts, one per phase. Decide who can add scope, and make it one person. Treat the existing site as a system to migrate rather than a page to replace, and inventory what depends on it. Export the baseline before anything changes. Put the security questionnaire, the DPA, the consent review and the accessibility statement in the plan at kickoff, where they cost days instead of weeks.
None of that is design advice, which is the point. Above a certain revenue, the design was never the risky part.
Read the full version
This is the condensed version. The full article has the side-by-side of what changes above and below €5M, the specific five-approver list, the platform and multilingual decisions in more detail, and the questions clients actually ask — including what counts as "enterprise" in the first place.
The website redesign checklist for companies over €5M revenue
Sources
The stakeholder figures are from Forrester's The State Of Business Buying, 2024. The scope-creep numbers come from PMI's Pulse of the Profession 2018. The approval-time figures are from a 2025 survey of 500 US marketing and creative professionals. The accessibility deadline is Directive (EU) 2019/882, applicable since 28 June 2025. The revenue-band framing and the checklist itself are mine, from client projects.
If you have run one of these on the engineering side, I would be curious which item on your list turned out to be the expensive one — my money is on the integration inventory, but the baseline export is the one people regret skipping.
Top comments (0)