Few website decisions are as hard to walk back as a CMS replatform. Once the old system is switched off, the URLs are rewritten, the content model is reshaped and the team has spent its budget, there is no quiet way to return to where you were. Yet many replatforming projects are approved on the strength of one internal recommendation, often from the people who most want the new tool. This article diagnoses why that pattern keeps producing painful migrations and sets out a practical fix: an independent second opinion on the replatform plan before anyone commits.

The problem: one answer, many interested parties

A typical replatform starts innocently. The marketing team is frustrated with slow publishing. A developer has been experimenting with a headless CMS and likes it. An agency pitches a rebuild. Within a few weeks, a recommendation lands on a manager’s desk: move to the new platform this quarter.

Look at who shaped that recommendation. The developer has invested evenings in the new tool. The agency will be paid to build it. The marketing lead has promised stakeholders faster pages. None of these people are acting in bad faith, but every one of them has a stake in the answer being yes. The manager approving the plan is, in effect, getting a first opinion from a room full of advocates.

Symptoms that the decision needed another look

Teams that skipped an independent review tend to report a familiar cluster of issues after launch. Seen together, they point to the same root cause:

• Traffic dips after cutover because redirect mapping covered the main pages but missed long-tail URLs that quietly brought in visitors.
• Editors struggle because the new content model suited developers but not the people publishing every day.
• Integrations break when forms, analytics tags or the CRM connection were assumed to “just work” on the new stack.
• Costs creep as hosting, licences and maintenance turn out higher than the original pitch suggested.

Each of these was visible before migration to anyone who looked with fresh eyes. They were missed not because the team lacked skill but because nobody without a stake was asked to look.

Diagnosis: why insiders miss what outsiders catch

Three forces make it hard for the original team to see the gaps in its own plan.

Familiarity blindness

People who have lived with a plan for weeks stop reading it. They see what they expect to see. An outside reviewer reads the redirect sheet line by line because it is new to them.

Sunk effort

Once a team has built a prototype, questioning the platform feels like throwing that work away. The pressure is rarely spoken aloud, but it shapes which risks get raised in meetings.

Narrow framing

Internal discussions often focus on the shiny part of the project, such as page speed or developer experience, while editorial workflow, SEO continuity and long-term cost get less airtime. A reviewer with no favourite tool will naturally ask about the whole picture.

The solution: a structured second opinion before cutover

An independent second opinion is a single, focused re-examination of the replatform decision by someone who had no hand in the recommendation and gains nothing whichever way it goes. It is not a new agency pitch, and it is not a long-running advisory arrangement. It is one fresh look at one decision.

Step 1: State the decision precisely

“Should we modernise our website?” is not reviewable. “Should we move the marketing site from our current CMS to this specific headless platform, with this content model and this redirect plan, launching on this date?” is. The sharper the question, the more useful the review.

Step 2: Choose a reviewer without a stake

Good candidates include a senior developer from another part of the business, a freelance architect who will not be bidding for the build, or a peer at a non-competing company. The test is simple: would this person benefit if you chose one way? If yes, keep looking.

Step 3: Hand over the real material

Give the reviewer the documents the team actually worked from, not a slide summary:

• the current site map and the full URL inventory;
• the proposed content model and editorial workflow;
• the redirect mapping, including how unmatched URLs will be handled;
• a list of every integration, form and tracking script;
• the cost estimate and the assumptions behind it.

If your original site planning was thorough, much of this already exists. Teams that followed a careful process for planning a business site before any code is written usually have the requirements documents ready to hand over.

Step 4: Ask for objections, not approval

Frame the request as “What would stop you signing off on this?” rather than “Does this look okay?” The first invites the reviewer to hunt for weak points; the second invites a polite nod. Ask them specifically to consider editorial workflow, search continuity, integrations and running cost, since those are the areas insiders most often underweight.

Step 5: Reconcile the two views

The reviewer will probably agree with some of the plan and challenge other parts. Resist the urge to treat the review as a vote. Instead, list each point where the two views diverge and ask why. In practice, disagreements tend to come down to a handful of specific items: a redirect pattern, a page type the new model handles poorly, a licence that scales with traffic. Each of those can usually be tested directly with a small pilot or a direct question to the vendor.

The final decision still sits with the business owner. The second opinion simply ensures that decision is made with a full view of the risks rather than the most enthusiastic view.

Where the review pays off most

Content structure is a frequent blind spot. A new platform may model pages beautifully for developers while making it harder to maintain the pages that carry the most commercial weight. A reviewer who checks the plan against the core pages every business website relies on will quickly spot if an about page, service page or contact flow has been treated as an afterthought in the new model.

Design decisions also deserve a second look. A rebuild is often bundled with a visual refresh, and the two get approved together. Separating them, and asking the reviewer to consider whether the proposed design actually supports visibility goals, helps avoid locking in a look that later proves hard to change.

A parallel from outside the web world

The idea is borrowed from fields where irreversible choices are routine. In health care, people facing major procedures often ask a second specialist to review the same findings first, and some online health platforms now package that request as a standard feature. The MyMedicPlus health and medical-travel portal, for example, lists a service for submitting a diagnosis to be looked at again by an expert, alongside guides to treatments and tests. This article cannot judge any medical finding, and it would be wrong to read it as doing so; only qualified clinicians can. The comparison is here because it shows how ordinary it has become, in high-stakes fields, to request a fresh look before committing.

Conclusion: make the second look a standard gate

The cheapest moment to catch a replatforming mistake is before the old system is switched off. An independent second opinion, focused on one clearly stated decision, with the real documents on the table and an explicit request for objections, costs a few days. Skipping it can cost months of lost traffic, frustrated editors and rework. Make the review a standard gate in your migration process, and treat the disagreements it surfaces as the most valuable part of the exercise.