When Should You Migrate a Website?
The straight answer is less often than people do. The useful thing this page can offer is a test for whether a migration solves a real problem or is a preference dressed as one, because talking somebody out of an unnecessary migration is worth more to them than helping with an avoidable risk.
The Question Behind The Question
Almost nobody arrives at this question undecided. They have been persuaded by somebody, they have a proposal in front of them and what they are actually looking for is permission to proceed.
Who did the persuading. Usually somebody with an interest.
A designer who would build it, an agency that prefers a different platform, a developer who finds the current system awkward. None is acting in bad faith. All are answering a different question from the one the business needs answered.
Why permission is the wrong thing to want. It skips the test.
Encouragement is easy to find and costs nothing to give. A test is uncomfortable, because it can produce an answer that wastes work already done.
The test itself. One question, answered candidly.
What specific thing can the business not do today that it could do afterwards. If the answer is concrete, the migration is probably justified. If it is a feeling about how the site looks, it probably is not.
What follows. The two lists.
Blocks two and three set out the reasons that survive that question and the reasons that do not.
Good Reasons
Each answers the question in block one with something concrete, which is what separates them from the list that follows.
The platform cannot do what the business needs. The clearest case.
Something the business requires and the current system genuinely will not support. Not awkward. Impossible.
A rebrand that is happening regardless. The migration is a consequence.
Where the name is changing for business reasons, the domain follows. The migration is not the decision. It implements one already made elsewhere.
The domain is wrong for the business. A real constraint.
A name that describes something the business no longer does, perhaps one permanently confusing to customers. That is a commercial problem the site cannot solve on its own.
Consolidating fragmented sites. Bringing things together.
A business running several sites, perhaps a main site and a separate blog, is dividing whatever it has earned. Consolidation is one of the few migrations undertaken for search reasons that is usually justified.
Security or support ending. A deadline set by somebody else.
Where the platform or a critical component is reaching the end of its supported life, staying put stops being an option. A genuine forcing event.
Poor Reasons
These are the reasons most migrations actually happen. None is unreasonable as a wish. None is a reason to accept the risk.
Wanting a fresh look. The commonest of all.
A site can be redesigned without its addresses changing. If the motivation is appearance, that can be changed without touching anything carrying risk. A smaller, cheaper and safer project.
Disliking the addresses. Covered on the types page.
Tidier addresses are pleasant. They are rarely worth replacing every address on the site for. It is worth asking who exactly is bothered by the current ones.
A new agency preferring a different platform. Worth examining.
Sometimes the preference reflects genuine capability. Sometimes it reflects what that agency is set up to build. Ask what the business gains rather than what the supplier finds easier.
Believing a new site will fix a ranking problem. The most expensive.
This is the commonest and the most consequential. It is wrong often enough to deserve its own block. That is block four.
A New Site Does Not Fix Rankings
If a site is not performing in search, the reasons are usually content, links and structure. A new website changes none of those. It carries them across and adds a fresh set of risks on top.
Why the belief is so persistent. It feels like a fresh start.
An old site feels like the problem because it is the thing you are looking at. Replacing it feels like decisive action. The alternative sounds like being told the problem is your own content.
What actually transfers. The problems.
Thin pages stay thin on a new platform. A site nobody links to still has nobody linking to it. A confusing structure rebuilt faithfully is still confusing. None of that is a platform characteristic.
What gets added. New risk.
Every migration risk in this cluster now applies on top of the original problem. A business underperforming can end up underperforming from a lower position.
Say this plainly. It is widely sold.
Rebuilding as a solution to poor search performance is recommended frequently, including by people who will be paid to do the rebuilding. It is occasionally right and it is wrong far more often than it is proposed.
The one case where it is correct. Worth conceding.
Where the platform itself genuinely prevents the fixes, which is rare and is specific rather than general. If somebody says a rebuild will fix rankings, ask which specific limitation is blocking which specific fix.
What To Fix First Instead
Most ranking problems have an answer that costs a fraction of a rebuild. Working through these first also establishes whether the platform is genuinely the obstacle.
The content on the pages. Usually the answer.
Whether pages actually address what people are searching for, in enough depth to be a credible result. This is the commonest cause and the one nobody wants it to be.
The structure. How pages relate.
Whether the site is organised so that related pages support each other, plus whether important pages are reachable rather than buried. That is arrangement rather than platform.
The technical faults. Frequently fixable in place.
Speed problems, indexing problems and errors that have accumulated. Our technical material covers these. Almost all of them can be addressed without moving anything.
Whether anybody links to the site. The slow one.
The hardest to change and the least affected by a rebuild. A new site starts with the same links the old one had if the migration goes well, fewer if it does not.
The order to work in. Cheapest and most likely first.
Content, then structure, then technical, then links. A rebuild sits after all four, not before them.
When Not To Migrate At All
Some situations make a migration a bad idea regardless of how good the reasons are. In each of these, waiting is the correct answer.
During a peak trading period. The obvious one, ignored constantly.
Migrating into the busiest weeks of the year means any disruption lands when it costs most. The temptation is to have the new site ready for the busy season, which is precisely backwards.
While a penalty or manual action is unresolved. Settle it first.
An unresolved issue of that kind needs addressing on the site it applies to. Migrating in the middle of it adds a second variable to a situation that already needs careful diagnosis.
Without a benchmark. The one people skip.
If nobody has recorded how the current site performs, there is no way to know afterwards whether anything was lost. That makes every subsequent conversation an argument between opinions.
When nobody owns the search side. The one that predicts failure.
A project where nobody has been made accountable for search will produce the pattern described throughout this cluster. Naming somebody costs nothing, so a project unwilling to do it is telling you something.
Timing Within The Year
The right window is the quietest trading period for that particular business. There is no month that suits everybody. Advice naming one is describing somebody else's business.
Why the calendar differs so much. Sectors invert each other.
A retailer's quiet period is a heating engineer's busiest. A firm serving schools has a different shape again. The only useful calendar is the one drawn from the business's own trading history.
How to find the window. Look backwards.
Take enquiries or sales across the previous couple of years and find the genuine trough. That is the window. It is frequently not where people assume it is.
What to allow for. The settling period comes after.
The migration is not finished at launch. The window needs to cover the weeks that follow as well, which means launching at the start of a quiet period rather than at the end of one.
The trap. Wanting it ready for the busy season.
Businesses frequently want the new site live before their peak. That puts the settling period inside the period that matters most, which is the opposite of what the timing is for.
Where the seasonal patterns are set out. By trade.
Our sector material covers when demand actually peaks for a number of trades, which is a more reliable guide than a general assumption.
Timing Within The Week
Launch when people are available to watch it. Most projects launch when the office is closed, which is exactly the wrong choice for exactly the wrong reason.
Why Friday evening is so popular. It feels safe.
Fewer visitors, less exposure, a weekend to sort out anything that breaks. That reasoning is entirely sensible for visible failures and entirely wrong for the ones that matter.
What it actually produces. Two days of nobody looking.
The failures described throughout this cluster are invisible. A site can be live, fast and blocked from search for an entire weekend, with nobody checking because nobody is working.
The better shape. Early in the week, early in the day.
Launching when the developer, whoever handles search and whoever can make decisions are all available means a problem found in the first hour is fixed in the second.
What that requires. Accepting some exposure.
A midweek launch means more people see any visible problem. That is a real cost and it is a smaller one than an invisible problem sitting undiscovered while everybody is away.
Doing It In Stages
A phased migration moves part of the site at a time. Where it is possible it reduces risk considerably, because problems appear at a scale that can be absorbed.
Why it helps so much. The first section is a test.
Moving one section reveals whether the mapping works, whether the redirects behave and whether anything unexpected happens. Everything learned improves the sections that follow.
When it is possible. Separable sections.
Where a site has parts that stand reasonably alone, such as a blog, a resource library or a distinct product area, those can move independently of the rest.
When it is not. Three situations.
A domain change, because the whole site moves at once by definition. A platform change, because running two systems in parallel is usually impractical. And a redesign, where half a site in each style is not something anybody will accept.
What to do when it is not possible. Compensate elsewhere.
Better preparation, hand-checked mapping for anything valuable and a longer watching period, per how to plan a site migration. The definition is in what is a site migration, the record you need first is in site audit before migration. The full series is on the website migration guide.
A new site
does not fix
rankings.
The decision tested before the project is scoped, the cheaper answers worked through first because most ranking problems have one, the quiet window found from your own trading history rather than a general assumption, the launch timed when people are available to watch it, with the whole thing declined where it is not warranted.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
