Advisory Note · Governance & Scope
Migrations Fail On Business Goals, Not Redirects
An advisory read on Erika Braeger: the question that decides a migration is asked before the date is set, not after the launch.
Migrations are where advisory work earns its fee, and not for the reason clients expect. By the time an advisor is asked about redirect mapping, the decisions that determine whether the project succeeds have already been made by somebody else, usually months earlier, usually for reasons nobody wrote down.
Erika Braeger of Tenspeed, speaking on the Unscripted SEO Podcast, starts in a different place from most technical practitioners.
Never Rush A Website Migration
Her first piece of advice on the subject is unadorned:
Read from a governance seat, that is a statement about scheduling authority rather than about technical care. Migrations get rushed because a launch date was announced before the scope was understood — tied to a rebrand, a campaign, a board meeting, a contract expiry. Once that date exists, every subsequent decision is made under a constraint nobody chose on the merits.
The practical implication for an in-house lead: the moment to influence a migration is when the date is being set, not when the redirect map is being built. If you are consulted after the date is fixed, you have been consulted about implementation, not about the project.
The Question That Reframes The Whole Project
What she asks first is not about platforms:
The failure mode she is naming is preference dressed as strategy. A new marketing hire is fluent in one platform. A designer prefers a particular editor. A developer wants to work in a stack that is better for their next job. None of those are illegitimate considerations, and none of them is a business case — but each can produce a project costing six figures in fees and organic revenue.
The question is diagnostic in a way that is useful even when the answer is good. A migration with a real goal — the platform cannot support the commerce roadmap, the licence is being withdrawn, three acquisitions need consolidating — produces a scope you can prioritise against, because you can ask of any decision whether it serves the goal. A migration without one produces scope that expands indefinitely, since nothing can be ruled out.
Where Advisory Adds More Value Than Execution
Braeger’s own framing of the discipline is worth pairing with this. Her concern with CMS changes is that they are undertaken casually. Our reading, as an advisory rather than as her recommendation, is that this creates four points where an outside seat is worth more than another pair of implementation hands:
- Before the date is set. Testing whether a business goal exists, and saying so plainly if it does not. This is the highest-value hour in the entire project and it is almost never bought.
- At scope definition. Deciding what is explicitly not changing. A migration that simultaneously changes platform, information architecture, URL structure, design and copy cannot be diagnosed afterwards, because every variable moved at once.
- At the go/no-go. Somebody has to be able to say the date should move, and be structurally capable of saying it. An agency being paid to deliver on that date is not that person.
- After launch. When the delivery team has rolled off and the effects are still arriving.
The second point is the one most often skipped and most often fatal. Not because changing several things is technically harder, but because it makes the post-launch conversation unresolvable — nobody can attribute a decline, so everybody defends their own component and no one fixes anything.
The Post-Launch Watch An Advisor Should Own
Our own thirty-day watch, offered as advisory practice. The structural argument for an advisor owning it is simply that the people who built the thing are gone, and the people who remain do not know what normal looks like.
- Days 1–3: does it exist? Indexation of the pages that matter, robots and canonical directives, redirects resolving in one hop rather than a chain, the analytics and Search Console properties actually recording.
- Days 4–14: is anything missing? Crawl errors, orphaned pages, templates that lost content in translation, and the pre-launch inventory of URLs checked against what now exists.
- Days 14–30: is it earning? Revenue and lead volume against the same period before, at page level rather than site level, because a site total can stay flat while the commercial pages collapse.
- Day 30: the written verdict. A short document saying what recovered, what did not, and what is now owed. Without it, an ambiguous outcome becomes a permanent argument.
None of this prevents a bad migration. What it prevents is a bad migration that nobody can prove happened, which is the version that costs the most, because it cannot be fixed and it cannot be learned from.