A website migration should be approved against agreed checks, with a named person responsible for unresolved risks. Seeing the new design work in a demonstration is not enough. I want to know what happens to the existing pages, how the important journeys have been tested and who can act if something breaks.

The word “migration” can hide very different projects. A change of domain, a new publishing system and a rewritten service catalogue each affect the website differently. Combining them makes the release harder to assess because several moving parts can alter the same page at once.

My first request would therefore be a plain description of what is changing. It should be specific enough that the team can point to anything that remains uncertain.

Agree on the purpose before approving the replacement

A migration needs a business reason that can guide trade-offs. Perhaps the existing system prevents important updates, the company is consolidating brands or the website cannot support a required customer journey. That reason should stay visible throughout the project.

Suppose a hypothetical professional-services company is replacing its website because editing has become cumbersome. During design, its detailed service pages are merged into a single attractive overview. The editing problem may be solved, but the project has also changed how customers learn about individual services.

I would ask for that second decision to be assessed separately. The migration should not become a convenient moment to remove detail merely because the new layout has less room for it.

This is also a useful way to manage scope. A proposed improvement can be worthwhile without belonging in the same release. Separating decisions makes approval more meaningful and leaves a clearer record of what each change was intended to achieve.

Give every important page an agreed destination

Before launch, I would want an inventory of the existing pages that matter commercially or serve an important user need. Each should have an explicit destination or a documented reason for being retired.

The destination should answer the same underlying need wherever possible. An old installation guide and a new service homepage are not interchangeable just because both mention the same product. The person following the old link still needs installation information.

Google's migration guidance recommends mapping old URLs to their new equivalents, using appropriate permanent redirects and avoiding irrelevant destinations. It also covers correct error responses where content is removed without a suitable replacement. The choice needs to be made page by page where the relationship is not straightforward.

I would assign content decisions to someone who understands the offer. Developers can implement an approved mapping, but they should not have to infer whether an old service is discontinued, renamed or simply missing from the design.

Treat missing content as a decision, not an accident

A page can retain its address while losing the information that made it useful. For that reason, the comparison should include content and functionality, not only URLs.

Imagine a hypothetical equipment supplier whose new product template omits compatibility details. The page opens, the images look right and the contact button works. Yet a customer can no longer establish whether the product fits their situation. A visual acceptance review could miss the loss unless the requirement was recorded.

I would ask each business owner to identify the information their customers need to proceed. This might include specifications, exclusions, downloads or the distinction between related services. Those requirements should inform the checks on representative pages.

The point is not to preserve everything indiscriminately. Old content can be wrong, redundant or unnecessary. I want its removal to be intentional, with an explanation that somebody accountable has accepted.

Define what would prevent launch

An unresolved issue should not become acceptable simply because the launch is close. Before that pressure builds, agree which failures would block release and which can be handled through a clearly assigned follow-up.

For me, an important service page that cannot be reached deserves a different response from a minor spacing inconsistency. The categories should reflect the site's actual business risks rather than a generic checklist copied from another project.

Google's guidance specifically warns that development restrictions, including noindex rules, need to be reviewed for launch. It also recommends testing the new site and monitoring the move. I would turn those principles into named acceptance checks, with evidence showing what was tested and where.

The team should know who has authority to postpone the release. If everyone assumes somebody else can make that call, the approval process is incomplete even when the technical checklist looks thorough.

Make the post-launch response part of the plan

The people who can repair the website need to be available when the release goes live. A launch arrangement that ends with handing over a password leaves too much unresolved.

I would specify where issues are reported, who decides their priority and who confirms that a repair works on the public site. The marketing team also needs a way to distinguish a broken journey from a measurement problem. Otherwise a missing report can be mistaken for missing visitors, or a broken form can hide behind apparently normal traffic.

A recovery plan should describe the practical options if the new site fails a critical check. Reverting a release is not always simple, particularly when new submissions or transactions have already been recorded. The technical team should explain those limitations before the business relies on rollback as reassurance.

Keep decisions visible during recovery. Quietly changing several things at once can make it harder to understand what fixed the problem or whether another issue was introduced.

Approve the release with its uncertainties visible

Google notes that search rankings can fluctuate while a significant move is processed. That possibility should be explained without using it as a blanket excuse for avoidable faults. A processing period and a broken destination are different matters.

I would approve a migration with a clear account of what has passed, what remains open and who owns the remaining work. That is more useful than a declaration that the new website is “SEO ready”.

The business does not need to inspect every technical detail personally. It does need enough evidence to understand the decision it is making. When the destinations, content responsibilities, launch conditions and response arrangements are settled, approval becomes a considered release decision instead of a deadline nobody feels able to question.