Decision guide
Migrate or rebuild: how to tell which project you are actually running
Almost nobody decides this. It gets decided for them, somewhere around week nine, by whichever answer the content forces.
The two projects look identical at the start. Both begin with a platform choice, both have a content phase, both end with a cutover. They diverge on one question that rarely gets asked out loud: is the site you have an asset you are moving, or a constraint you are leaving?
Getting this wrong in one direction wastes money. Getting it wrong in the other produces the worst outcome available — a migration that turns into a rebuild in month three, still carrying a migration budget and a migration deadline, with everybody blaming the platform.
Ask what you would keep if you started today
Not what exists. What survives an honest look.
Take the site's pages and sort them into three piles: would publish again today, would publish again after editing, and would not publish again. Do it on a sample if the site is large — a couple of hundred pages is enough to see the shape.
If most of it lands in the first two piles, the content is an asset and you are migrating. If most of it lands in the third, you are not moving a site, you are moving an archive, and the honest project is a rebuild that draws on the archive selectively. Teams that skip this step end up paying full migration price to relocate pages nobody would defend.
This exercise has a useful side effect. Retiring content is the only thing that makes a migration cheaper, and it is far easier to get sign-off on deleting a page before the project starts than after somebody has already paid to move it.
Ask whether the structure still describes you
Information architecture ages faster than content does.
Site structure is usually a fossil of how the organisation was arranged when the site was built. Departments that merged, products that were renamed, a section added for a campaign that ended in 2022 — all of it is still load-bearing in the navigation.
A migration preserves that structure by design. That is the point of it: URLs stay recognisable, redirects are simple, and the thing that made the site findable keeps working. But if the structure is the problem, preserving it faithfully means paying to carry the problem to a new platform, where it will be someone else's fault.
The test: can somebody who joined last year navigate to the three most important things on the site without using search? If not, the architecture is the project, and the platform is a detail.
Ask what is actually causing the pain
The platform gets blamed for a lot of things it did not do.
Write down the reason you are moving, then ask whether the current platform causes it. It frequently does not. Slow publishing is often approval workflow rather than software. Inconsistent pages are often the absence of a design system. Content nobody can find is usually architecture. Every one of those survives a platform change untouched.
Where the platform genuinely is the cause — it is losing security support, it cannot model the content you now need, licensing has become indefensible, or you cannot hire anyone who knows it — a migration solves the problem directly and you should get on with it.
Then decide, and say which one out loud
The naming matters more than it sounds.
Migrate when the content is valuable, the structure still works, and the platform is the thing that has failed. Rebuild when the structure has stopped describing the organisation and most of the content would not be published again. Those are different projects with different shapes, different budgets, and different ways of going wrong.
The reason to say it out loud is that unnamed projects default to whichever framing was in the budget request. A rebuild running under a migration plan produces exactly one outcome: the timeline is set by the easy part, the difficulty arrives with the content, and by the time anybody says the word rebuild, half the money is spent.
The hybrid nearly everyone actually runs
In practice most projects are a migration of content into a rebuilt structure — keep what is worth keeping, discard the rest, and let the architecture be new. That is a perfectly good answer, and it is what teams usually arrive at anyway.
The only thing worth protecting in that shape is diagnosability. Changing platform, architecture and design in one release means that when traffic moves afterwards, nothing tells you which change caused it. If you can separate any of the three, separate it. Where you cannot, at least baseline everything first — every URL, title and description — so there is something to compare against.
FAQ
Frequently asked questions
What is the difference between a migration and a rebuild?
A migration moves existing content and structure onto a new platform and keeps the information architecture largely intact. A rebuild starts from what the site should be and treats the old content as a source to draw from. The difference is not effort — rebuilds are not always more work — it is whether the existing structure is an asset you are preserving or a constraint you are escaping.
How do I know if I should rebuild instead of migrate?
Three signals, and any two together usually settle it: the information architecture no longer matches how the organisation describes itself, most of the content would not be published again today, and the reason you are moving is something the current structure causes rather than something the platform causes. If all you need is a different platform under the same site, that is a migration.
Is a rebuild more expensive than a migration?
Not reliably, and that surprises people. A rebuild of a much smaller site can cost less than migrating a large one, because migration cost scales with volume while rebuild cost scales with scope. The expensive outcome is the third option nobody chooses on purpose: a migration that becomes a rebuild halfway through, priced as a migration.
Can I migrate the content but rebuild the design?
Yes, and it is the most common shape in practice. Just be aware that doing both at once removes your ability to diagnose what changed — if traffic moves afterwards you cannot separate the platform from the design. Where the schedule allows, move first and redesign second.
What happens if I choose wrong?
Choosing rebuild when a migration would have done wastes money but usually produces a working site. Choosing migration when a rebuild was needed is the one that hurts: the structural problems arrive with the content, the team spends the budget fighting them, and everyone concludes the platform was the mistake.
Once you know which project you are running, the migration assessment scores the difficulty without needing a live site, and the migration guides cover the specific platform pairs. Our scan of 27,385 live sites is open data if you want to check the numbers behind any of it.