You migrate a large website in phases by splitting it into self contained sections, moving one section at a time with full redirects, and verifying each before starting the next, so a problem affects only the section in flight rather than the whole site. The phases are usually drawn along natural boundaries: by content type, such as the blog, then the product catalog, then the resource library, or by directory or section of the site. For each phase you migrate that section to the new platform, set a 301 from every old URL in it to its new address, and confirm rankings and traffic hold before moving on. The trade off is that during the transition you are running two systems at once, the old platform still serving the unmigrated sections and the new one serving the migrated ones, which adds complexity: you must avoid the same content being live on both, keep redirects consistent, and manage one domain spanning two systems. Phasing is the right approach for very large or complex sites where an all at once move is too risky; small sites are better moved in one go. WPBuildAI scans your site and returns the full URL list grouped so you can see the sections, plan the phases, and track which URLs each phase must redirect.
Phasing stretches the window you have to maintain: Google’s guidance is to keep redirects live for at least a year after the move is complete, so a migration run across four stages leaves the final stage’s redirects your responsibility well into the following year.
Why phase a migration at all
The reason to phase is risk containment. On a very large site, moving everything at once means that any mistake, a redirect gap, a content loss, a stray noindex, hits the entire site simultaneously, and the recovery is correspondingly large. Phasing shrinks the blast radius: if something goes wrong, it affects only the section currently in flight, which you can fix or roll back without touching the rest. It also lets teams give each section proper attention rather than rushing the whole site, and it spreads the work over time. The cost is added complexity during the overlap, which is why phasing earns its place only at scale. For a small site the overhead outweighs the benefit, but for a large, complex one, containment is worth the extra coordination.
Decide whether your site should be phased
Be honest about scale before choosing this approach, because phasing is not free. A small or medium site is better migrated in one well tested move, where the simplicity of a single cutover beats the overhead of running two systems. Phasing makes sense when the site is large enough that an all at once move is genuinely too risky to verify confidently, or complex enough that different sections need different handling and timelines. The same scale that makes crawl budget a real concern is roughly the scale at which phasing pays off. If your site is modest, take the simpler path; if it is a large catalog or a sprawling publisher with many sections, phasing is the safer way to move it.
Split the site into self-contained sections
The foundation of phasing is the division into sections, and the sections should be self contained, meaning each is a coherent chunk you can migrate and redirect as a unit. Natural boundaries work best: by content type, such as the blog as one phase, the product catalog as another, the documentation as a third, or by directory and site section. The aim is that each phase has a clear set of URLs that move together, with as few cross dependencies to unmigrated sections as possible. A content audit helps here, since it already maps your URLs into groups and decides what to keep, as covered in a content audit before a migration. Clean section boundaries are what make each phase verifiable on its own and keep the overlap manageable.
Migrate and redirect one phase at a time
Within each phase, you run a complete mini migration of that section: move its content, images, and metadata to the new platform, and set a 301 from every old URL in the section to its new address, exactly as the site move guide requires. The discipline that matters is finishing a phase before starting the next: migrate the section, redirect its URLs, verify that its rankings and traffic hold, and only then move on. Prioritize phases by value, since traffic concentrates on a minority of pages, as the Ahrefs study shows, so you might migrate a high value, well understood section first to prove the process, or last to reduce its exposure, depending on your risk preference. Either way, one phase fully done beats several half done.
Manage running two systems at once
The defining challenge of phasing is the overlap period, when the old platform still serves the sections not yet moved and the new platform serves the ones already moved, all under one domain. This demands care on three fronts. First, avoid duplicate content: a section should be live on one platform at a time, with the old version redirected once migrated, never left accessible alongside the new one. Second, keep redirects consistent across the boundary, so links between a migrated and an unmigrated section still resolve correctly. Third, manage the domain routing so one domain can serve both systems cleanly during the transition. Web Almanac 2024 (HTTP Archive) is a reminder of how many URLs a large site has, so tracking which belong to which system at each phase is essential, not optional.
Verify each phase before the next
Phasing only delivers its safety benefit if you actually verify between phases. After completing a phase, confirm that the migrated section answers all its URLs on the new platform, that its redirects resolve in one hop, that its content and metadata came across, and that its rankings and traffic are stable, before you begin the next phase. This checkpoint is the entire point: it catches a problem while it is confined to one section, when fixing it is cheap, rather than letting issues accumulate across phases. If a phase shows trouble, you pause and resolve it before adding more change. The cadence is deliberate, migrate, verify, then proceed, which is what keeps a large migration controlled rather than turning it into a slow motion version of an all at once risk.
Steps to migrate a large site in phases
- Confirm the site is large enough to justify phasing over one move.
- Split into self contained sections along content type or directory.
- Prioritize the phases by value and dependency.
- Migrate one section with content, metadata, and full 301s.
- Verify that phase: URLs, redirects, content, and stable traffic.
- Manage the overlap: no duplicate content, consistent redirects, one domain across two systems.
Worked example: phasing a large publisher
Imagine a publisher with a hundred thousand URLs across a blog, a large article archive, and a resource library, moving to a new platform. An all at once move would be too risky to verify, so they phase it. A content audit groups the URLs into sections. They migrate the blog first as a contained phase, redirecting every old blog URL and confirming traffic holds, while the archive and library keep running on the old platform. During the overlap they make sure each blog post is live on only one system and that links from the still old archive into the new blog resolve through redirects. Once the blog phase is verified, they migrate the archive, then the library, repeating the migrate, redirect, verify cadence. Months later the whole site is on the new platform, with no single moment of large scale risk, because each section was contained and proven, the disciplined version of migrating without losing SEO at scale.
Limitation: phasing trades simplicity for the overlap
It is honest to name the trade. Phasing reduces the risk of any single failure being catastrophic, but it does so by extending the migration over time and running two systems in parallel, which is more complex to manage and longer to complete than a single cutover. That overlap introduces its own risks, duplicate content, inconsistent redirects across the boundary, domain routing complexity, which you accept in exchange for containment. So phasing is not universally better; it is the right tool for sites too large to move safely at once, and the wrong tool for sites small enough to move cleanly in one go, where it just adds overhead. Choose based on scale and complexity, and remember the general trade offs in the risks of migrating to a new CMS.
Common mistakes
- Phasing a small site that would be simpler to move all at once.
- Drawing phases that are not self contained, so sections depend on each other.
- Leaving a section live on both platforms during the overlap, creating duplicates.
- Starting the next phase before verifying the previous one held.
- Letting redirects across the migrated and unmigrated boundary fall out of sync.
Key points
You migrate a large website in phases by splitting it into self contained sections, moving one at a time with full 301 redirects, and verifying each before starting the next, so any problem stays contained to the section in flight. Draw phases along natural boundaries like content type or directory, prioritize by value, and keep the cadence of migrate, verify, then proceed. The cost is the overlap: running two systems under one domain, where you must avoid duplicate content, keep redirects consistent across the boundary, and manage domain routing. Phasing is the right approach for very large or complex sites; small sites should move in one well tested go, since phasing only adds overhead. Plan the sections from a complete URL list and a content audit so nothing is missed. WPBuildAI scans your site and returns the full URL list grouped so you can see the sections, plan the phases, and track which URLs each phase must redirect. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.