The Part Of A Website Migration Nobody Plans For
The site launched on time. Redirects worked. Staging looked great.
Three weeks later, marketing couldn’t update a landing page without filing a dev ticket. Sales discovered their lead forms were routing to the wrong place. The content team’s entire publishing workflow had been wiped out.
Nobody saw it coming because nobody scoped it.
The technical migration got a detailed proposal, sprint plans, a Gantt chart. The operational reality on the other side of launch? That got zero budget, zero planning, and zero ownership.
This is the pattern we see over and over. A company spends six figures moving to a new platform. The agency delivers a technically sound website. Then the gap between “the site is live” and “the team can actually operate it” quietly unravels the whole thing.
Not because of broken redirects or bad templates. Because nobody planned for the fact that every team would need to work differently after launch. New tools, new workflows, new content processes, new responsibilities.
The proposal became the project plan. And everything outside that boundary became someone else’s problem.
If you’re planning a migration right now, we wrote about the part that almost never makes it into the scope. It should.
Freelancer vs Agency For Your Website Build
There’s a complexity range where most mid-market website projects land.
It’s too complex for a solo freelancer to comfortably own. But not complex enough to justify what a mid-size agency charges for dedicated PM, design, dev, and QA.
That grey zone is where the most project failures happen.
Not because of bad talent. Good freelancers and good agencies both exist. The failures happen because companies pick their delivery model based on budget rather than the coordination demands of the build itself.
Here’s what makes it worse. A freelancer who costs half as much but delivers a site that can’t integrate with your CRM or lacks proper SEO architecture isn’t cheaper. They’re more expensive. And an agency charging six figures who can’t explain what they’re building until they start building it isn’t more professional.
The real deciding factor is whether you understand your own project well enough to brief either option properly. Most teams don’t. And that gap between what you think you need and what the project actually requires is where the budget disappears.
We published our full thinking on this one.
Writing A Website RFP That Actually Gets Useful Responses
We’ve reviewed hundreds of website RFPs that clients brought to us after getting confusing proposals back.
The pattern is almost always the same.
The document asked vendors to describe their company history, list certifications, provide references. Pages and pages focused on the vendor. Almost nothing about the actual project.
So every agency filled in the blanks differently. Made different assumptions. Priced different scopes. And the client ended up with five proposals they couldn’t meaningfully compare.
Here’s what caught me off guard when I first saw this pattern: the budget inflation isn’t coming from greedy vendors. It’s coming from ambiguity. When a vendor encounters a vague requirement, they either price it low and recover through change orders, or price it high to cover the unknowns.
Neither outcome is good for you. One leads to scope creep. The other means you’re paying a risk premium for your own lack of preparation.
Most RFP templates make this worse. They were designed to evaluate vendors, not to communicate projects. The vendor with the best copywriter wins.
We wrote about what a substantive RFP actually focuses on instead.
how to get stakeholder buy-in for a website project
The teams that get website projects funded fast almost never open with “we need a new website.”
That surprised me the first few times I saw it. But the pattern is consistent. Across dozens of mid-market projects, the ones that stall out tend to start with wireframes, mood boards, and tech talk. The ones that get greenlit fast start with a business problem the room already cares about.
Something like: “We’re losing 40% of qualified leads between first touch and demo request.” That sentence gets attention. “We need to modernise our website” gets a sigh and a budget debate.
But here’s what most teams miss entirely. Stakeholder buy-in isn’t just about the person who signs the cheque.
Your sales lead, your IT team, your subject matter experts. Each one can quietly kill a project through delay, scope creep, or simply not showing up when you need their input. And each one has a completely different definition of what success looks like.
The CEO wants measurable ROI. Sales wants to know leads won’t disappear during migration. IT wants to know they’re not inheriting a platform nobody asked them about.
Pitching the project the same way to all of them is one of the most common mistakes. And one of the most expensive.
We mapped out the full approach to getting internal alignment before a project even kicks off. The article covers the framework we keep coming back to.
what is a website discovery phase and why does it matter
How many people in your organisation have a say in what your website should do?
Now. Would they all describe the same priorities?
Most teams assume alignment exists because nobody’s argued about it yet. That’s not alignment. That’s avoidance.
One pattern we see constantly: the sales team wants the site generating qualified leads, the CEO wants it signalling credibility to investors, marketing wants it ranking for specific keywords. Three legitimate goals. Three different sets of design decisions and content strategies pulling in different directions.
None of this is a problem if you surface it early. It becomes a massive problem when it surfaces mid-development, because now you’re reworking pages that were already built. Changes at that stage cost roughly ten times what they’d cost during planning.
The expensive version of a web project isn’t one with a big scope. It’s one where the real scope reveals itself halfway through the build.
That gap between “what we think we agreed on” and “what we actually need” is exactly what a proper discovery phase is designed to close. Most teams skip it or treat it as a single kickoff meeting. The outcomes are predictable.
We broke this down properly in our latest article.
what should a website requirements document include
Most teams write requirements that say “the site should be modern and user-friendly.”
Best-run projects define exactly what “user-friendly” means in measurable, testable terms.
Most teams list their business objectives once at the top and never revisit them.
Best-run projects rewrite their objectives after drafting every other section, because the mismatch between what you wanted and what you actually spec’d is where projects go sideways.
Most teams think a complete-looking document means alignment.
Best-run projects know that vague language different people interpret differently is worse than a blank page.
Most teams discover misalignment during development.
Best-run projects surface it before a single wireframe gets drawn.
The pattern we see most often isn’t a document that’s missing sections. It’s one that looks thorough but leaves every hard decision unmade.
We wrote about what separates the two.
how to scope a website project without missing anything
Your website scope document isn’t missing features. It’s missing the conversation that should have happened before anyone opened a spreadsheet.
Roughly 70% of scope gaps trace back to the first two weeks of a project. Not to forgotten pages. To assumptions that were never surfaced.
Marketing assumes a resource hub. Sales assumes a pricing calculator. The CEO assumes the homepage mirrors a competitor. None of it gets written down. None of it gets challenged.
Then development starts. And suddenly every “small addition” costs 3-5x what it would have cost to just ask the question earlier.
The pattern is consistent: one person gets tasked with “getting the website redone,” briefs a vendor based on their own perspective, and moves forward. Three months later, sales wants to know where their demo booking flow went. Ops discovers a subdomain nobody remembered.
Complete scope requires complete input. And most teams skip the single activity that produces it.
Not the sitemap. Not the wireframes. Stakeholder mapping.
We broke this down in our latest piece.
how long does a website redesign take
Something we keep noticing in mid-market website redesigns:
The timeline blows out. But not for the reasons people assume.
Almost nobody comes to us saying “we underestimated our discovery phase.” They say the developers were slow, or the design took too many rounds, or the CMS migration was more complex than expected.
When we look at the actual project history, the pattern is almost always the same. The team compressed or skipped the upfront planning. Started designing before anyone agreed on what pages would exist. Started building before requirements were documented.
Then every subsequent phase took longer because people were making decisions without shared context.
A 30-page site with clear requirements can launch in 12 weeks. A site of similar complexity with no documented requirements and multiple stakeholders weighing in late? Easily 9 months.
Same technical scope. Wildly different timelines. The difference isn’t the build. It’s whether the organisation was ready before the build started.
Most teams think of pre-project planning as something to get through quickly. It’s actually the single biggest predictor of whether the project finishes on schedule.
We wrote about where those weeks actually go and why the invisible half of the timeline matters more than the visible half.
What Is The Difference Between A Website Refresh And A Redesign
One of the first things we assess before any website project moves forward is whether the real problems live in the visual layer or the structural layer. Most teams blur these together, but the answer completely changes the scope, the budget, and who needs to be in the room.
A dated homepage is a visual problem. A CMS that nobody can update without a developer, broken lead flows, and navigation that confuses visitors are structural problems. Treating structural issues with a visual refresh is one of the most common ways mid-market companies burn six months and a decent budget while ending up roughly where they started.
That distinction sounds simple, but diagnosing it accurately requires pulling apart analytics, user flows, and platform constraints before anyone opens a design tool. We wrote up the full framework on our blog: “What Is The Difference Between A Website Refresh And A Redesign.”
Why Do Website Projects Go Over Budget
A pattern we see constantly in mid-market website projects: the budget overrun that nobody can point to a single cause for. It’s never one catastrophic decision. It’s dozens of small misalignments between what the vendor estimated and what the team actually needed, each one reasonable on its own, compounding into a project that costs 30-80% more than the original number.
The root is almost always the same. The proposal was written with maybe 10-20% of the information needed to produce an accurate estimate. The vendor interpreted a brief. You approved what you assumed they understood. And from that moment, every ambiguity became a future change order waiting to surface.
Most teams think this is a vendor problem or an execution problem. It’s a scoping problem. And it’s structural, not situational. We see it repeat with different teams, different vendors, different industries. The pattern is remarkably consistent.
We broke down exactly why this happens and where the budget actually goes in our latest article.