What Are the Different Types of Site Migration?
The types matter because each one puts a different thing at risk. Identifying which you are doing is the first planning decision anybody makes. The more useful point comes later: the commonest real world migration is four of these running at once, which is exactly why it needs planning.
Why The Type Decides The Risk
Migrations are not a single kind of project with a single kind of risk. Each type moves a different thing, threatens a different asset and needs a different sort of care, which is why naming the type comes before anything else.
What varies between them. Three things.
Whether external links still reach the site. Whether the addresses people have bookmarked, shared and linked to still work. And whether the site itself behaves differently once it is running somewhere new.
Why that changes the plan. Effort goes where the risk is.
A domain change concentrates almost all its risk in one place, so almost all the planning goes there. A platform change spreads it thinly across dozens of small defaults, which needs a different kind of checking entirely.
What people usually do instead. Treat them as one thing.
A generic migration checklist applied to every project spends equal effort on unequal risks. That is how a domain change ends up receiving the same attention as a colour scheme change.
The real complication. Named in block ten.
Almost nobody is doing only one of these. The types are useful as a way of separating the risks inside a project rather than as a way of labelling the project itself. That distinction is what the second half of this page is about.
Domain Migration
Moving to a different web address entirely. Usually a rebrand, sometimes a merger, occasionally a business realising its original domain no longer describes what it does.
Why it is the riskiest. Everything external points at the old place.
Every link any other website has ever made, every citation in a directory, every bookmark and every printed reference points at a domain that will no longer be the business. All of it depends on redirects working correctly and continuing to work.
What carries over. With care, most of it.
Where every old address points at its precise equivalent on the new domain, the intention is that accumulated value follows. That is the purpose of the exercise and it is why the mapping matters more here than anywhere.
What does not. Anything nobody redirected.
Addresses missed from the map simply stop existing. On a large or long-lived site the missed addresses are frequently old ones nobody remembers, which are also the ones most likely to carry links earned years ago.
The part people underestimate. It is permanent.
The old domain has to keep resolving and keep redirecting, indefinitely. A domain allowed to lapse two years later takes every one of those links with it, quietly, long after anybody is watching.
Platform Migration
Moving the site onto a different system while keeping the same domain. The move itself is rarely the problem. What the new platform does automatically is.
What changes without anybody deciding. Three categories.
Addresses, because every platform has its own way of constructing them. Markup, because platforms generate their own and it differs. Speed, because a different system loads differently and usually more heavily.
Why that is harder to catch. Nobody chose it.
A decision somebody made can be reviewed. A default nobody knew existed cannot, because it does not appear on any plan or specification. It appears in the built site, visible only if somebody thinks to look.
What to establish early. The constraints.
How the new platform will structure addresses, whether that structure can be changed, how many redirects it will accept and what it generates on every page without being asked. All four are answerable before anything is built.
Why they matter before the build. They shape the map.
A mapping built against a structure the platform cannot produce has to be redone. Establishing the limits first means the map is built once, which is covered in how to plan a site migration.
CMS Migration
Changing the system used to manage content, frequently while keeping the same hosting and the same domain. In practice this overlaps heavily with a platform migration and it is worth being straightforward about that rather than pretending otherwise.
Where the distinction is real. Scope.
A platform change may replace hosting, delivery and the content system together. A content system change may replace only the layer authors work in, leaving the rest untouched. The second is the smaller project.
Why the risk is still substantial. Content moves imperfectly.
Exports between content systems lose formatting, custom fields and the relationships between pages. What arrives is recognisably the content and frequently not identical to it, which is a search risk disguised as a tidying task.
The specific thing to check. What the old system was producing.
Content systems generate more than words. Address structures, page titles, markup and sitemaps are frequently produced by the system or by extensions to it. None of that arrives with the content.
Where this is covered in detail. The platform pages.
The specifics differ enough by system to deserve their own treatment, which is why WordPress CMS migration SEO exists separately.
URL Restructure
Changing addresses without changing anything else. No new platform, no new domain, no redesign. Just tidier addresses. It is a full migration with every risk that implies.
Why it gets treated casually. It looks small.
Nothing visible changes. The site looks identical, the content is identical and the work sounds like housekeeping rather than a project. That framing is exactly why it is done without a map or a benchmark.
What is actually happening. Every address is being replaced.
From the outside, every page has moved. Every link, every bookmark and every existing position attaches to an address that no longer serves anything. That is the same event as a domain change, at page level.
The uncomfortable question. What is it for.
Tidier addresses are pleasant and they are rarely worth the risk on their own. Where a restructure genuinely improves how the site is organised, it can be justified. Where it exists because somebody dislikes how the current addresses read, it usually cannot.
When it is genuinely worth doing. Alongside something else.
If the site is being rebuilt anyway, restructuring at the same moment costs one migration rather than two. That is the one case where combining changes is the safer choice. Block eleven explains why it is the exception.
HTTP To HTTPS
Moving a site from the insecure protocol to the secure one. This was a substantial migration event for most of the web and it is now largely behind us, though it still turns up.
What it involved. Every address changing.
The protocol is part of the address, so switching it changes every address on the site at once. That made it a full migration for sites that had never thought of themselves as migrating anything.
Why it caused problems. Partial implementation.
Sites that switched some pages and not others, then served both versions simultaneously without saying which was authoritative, created duplicates of themselves. That is a tagging problem as much as a redirect one, covered in canonical and hreflang tags during migration.
What it means today. A different conversation.
A site still running on the insecure protocol has a larger problem than a migration. Browsers warn visitors about it. The migration question is not really the one that needs answering first.
Why it still appears here. Legacy addresses.
Long-lived sites frequently still carry redirects from that transition, layered underneath later ones. Those accumulated layers are where redirect chains come from, which is the quiet failure the redirects guide covers.
Subdomain To Root Domain
Bringing a blog, a shop or a support section that lives on a separate subdomain back into the main site. This is one of the few migrations undertaken specifically for search reasons rather than for business ones.
The reasoning. Consolidation.
A business running its content on one address and its main site on another has split its efforts across two places. Bringing them together concentrates everything the business has earned into one property.
Why it is worth being careful. The upside is not guaranteed.
Consolidation is a reasonable expectation rather than a promise. It is only realised if the move is executed well. A consolidation done badly loses more than the separation was costing.
The specific risk. Sections are large.
A blog that has run for years may have more addresses than the main site. Treating it as a small annexe being tidied away underestimates the mapping work considerably.
What to check first. Whether the platforms can coexist.
The subdomain frequently exists because the content runs on a different system. Consolidating means either moving that content onto the main platform, which is also a platform migration, else serving it from the main domain some other way.
Design And Content Changes
Changing what is on the pages is a migration in effect, even when every address stays exactly where it was. This is the type nobody plans for, because it leaves no technical trace at all.
What happens during a redesign. Words disappear.
A new design is usually cleaner, lighter and more visual than the one it replaces. Cleaner frequently means shorter. Pages that carried substantial explanation end up carrying a headline, an image and a button.
Why nobody notices. There is nothing to find.
No address broke. No redirect failed. No error appeared anywhere. The site works perfectly and simply says considerably less than it used to, which no technical check will ever report.
Why it matters. The content was doing the work.
Whatever a page ranked for, it ranked for because of what was on it. Removing half of that removes the reason. A decline following a redesign that changed no addresses is frequently this and is almost never diagnosed as this.
The protection. A record beforehand.
A crawl of the old site captures what every page said. Without it, there is no way to demonstrate afterwards that anything was lost, which is why the audit stage exists and why it cannot be done later.
Internationalisation
Adding language versions or country versions of a site. This is a migration because it changes what exists at which addresses. It also introduces a category of problem the other types do not have.
What makes it different. Multiple versions of the same page.
Once a page exists in two languages or for two countries, the site has to declare which version suits which audience. That declaration lives in the markup and it contains addresses.
Why that is fragile. The declarations must agree.
The relationship between versions has to be stated on both sides. A migration that changes addresses on one side breaks the pair, doing so without producing any visible error.
The structural decision. Made early or regretted.
Whether versions live on separate domains, on subdomains or in folders is decided at the start and is expensive to change later. It is a migration decision dressed as an architecture decision.
Where the detail sits. Its own guide.
Most readers here do not have language versions, so this is kept short. The mechanism is in canonical and hreflang tags during migration.
Most Real Migrations Are Several At Once
Everything above describes a single change in isolation. Almost no real project is a single change. Recognising that is the most useful thing this page can offer.
The typical rebuild. Count them.
A business commissions a new website. It moves to a different platform, the addresses change with it, the design is entirely new and the content is rewritten and shortened. That is four migrations, running simultaneously, in a project called a redesign.
Why that matters more than the individual risks. Attribution.
If performance changes afterwards, there are four candidate explanations and no way to separate them. The redirects may be fine and the content may be the problem. The content may be fine and the platform may be slower.
What that does to the recovery. It doubles the work.
Diagnosis becomes elimination rather than investigation. Each possibility has to be ruled out in turn, while the site continues performing badly. Every check takes time that a single-change project would not have spent.
Why nobody separates them. It is cheaper not to.
Doing everything at once is one project, one budget and one disruption. Splitting it is two or three of each. That is a real argument and it is worth making the trade knowingly rather than by default.
Do One Thing At A Time Where You Can
Where changes can be separated, separating them makes every subsequent question answerable. Where they cannot, the preparation has to be better to compensate.
The sequencing that works. Structural first, cosmetic after.
Move the platform, let it settle, then redesign. Or redesign on the existing platform, let it settle, then move. Either order is better than both together, because each change gets a clean reading.
What settling means here. Enough to read.
Long enough that performance has stabilised and any effect of the first change is visible. That is a judgement rather than a fixed period. It is described on the processing time guide as a shape rather than a number.
When it genuinely cannot be split. Two situations.
A rebrand, where the domain, design and content all change because the business has changed. And a platform that is being retired, where staying put is not an option. Both are legitimate and both are still four migrations.
What to do instead in that case. Compensate with rigour.
A more complete crawl, a more careful benchmark, mapping done by hand for anything that matters and a longer monitoring window. The overview of that sequence is in what is a site migration, the store version is in Shopify migration SEO. The full series is on the website migration guide.
A redesign is
four migrations
nobody split.
The type identified before the effort is allocated, the platform constraints established before the map is built, changes separated where they can be so each one gets a clean reading, the content recorded because a redesign that drops words leaves no technical trace, with the old domain kept alive indefinitely.
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.
