Website redesign vs migration: the difference
When someone says they need a website redesign, I usually start by slowing the conversation down. A redesign and a migration are not the same project, even though they often overlap. In real projects, most clients need some form of partial migration. Usually, that means some existing page content will be worked into a new design, but the structure, templates, user experience, or platform may also change.
The simplest distinction is this: a website migration is a copy of the current site with very few changes. The main things that change are the items that must change because of the new platform, CMS, hosting setup, or technical environment. A migration is usually cheaper and faster because it removes many steps. You are not rethinking every page, rewriting all the content, redesigning the experience, or rebuilding the site strategy from scratch.
A website redesign, on the other hand, changes how the site looks, works, and often how users move through it. Most clients come to us for a redesign because they already know the current site is old, clunky, hard to use, or no longer aligned with the business. The site may still have valuable content and rankings, but the experience needs work.
What counts as a website redesign?
A redesign focuses on the user-facing experience. That can include the visual design, navigation, page layouts, messaging, conversion paths, mobile experience, accessibility, and content presentation. The goal is usually to make the site easier to use, more credible, and better at supporting business goals.
A redesign does not automatically mean every URL changes or every page gets rewritten. In fact, a good redesign often protects what is already working. If a page ranks well, brings in qualified traffic, or supports conversions, we want to understand why before changing it. The risk comes when teams treat a redesign as a chance to clean house without a plan.
Common redesign activities
- Creating new page templates and design systems
- Improving navigation and information architecture
- Updating page copy, calls to action, and conversion flows
- Refreshing brand visuals, imagery, typography, and layout
- Improving mobile usability and page speed
- Reworking service, product, or industry pages
Redesign projects can still create migration-level SEO risk if they involve URL changes, content pruning, CMS changes, or major structural changes. This is where decision-makers often underestimate the work. A site can look like “just a redesign” on the surface, but if URLs are changing or content is being removed, it needs migration planning too.
What counts as a website migration?
A migration is more technical and more controlled. The goal is to move the site from one environment to another while changing as little as possible. That might mean moving from one CMS to another, changing hosting providers, moving from an old platform to a new one, or changing domains.
Because a true migration keeps the site largely the same, it can be much faster and less expensive than a redesign. You are copying the current site, adapting what must be adapted for the new platform, and making sure search engines and users can still find the right pages after launch.
Common migration activities
- Creating a full content inventory of current pages
- Mapping old URLs to new URLs when changes are required
- Setting up 301 redirects
- Moving content, media, metadata, and structured data
- Preserving analytics and tracking setup
- Testing staging environments before launch
- Monitoring rankings, crawl errors, traffic, and conversions after launch
The big mistake is assuming migration means “copy and paste the website.” There is always detail work. Even if the site is staying mostly the same, we still need to know what exists, what matters, what is indexed, what receives traffic, and what needs to be redirected.
Most projects are actually both
In practice, very few projects are purely redesign or purely migration. Most are a blend. A client may ask for a redesign because the site feels outdated, but we still need to migrate old page content into the new design. Or a company may think it only needs a platform migration, but the new platform’s templates or ecommerce functionality force a design rethink.
This is why one of the first things I ask is what is actually changing. Are we changing the CMS? Are URLs changing? Are pages being combined or removed? Are we keeping the same navigation? Are we rewriting content? Are we changing domains? Are we moving an ecommerce catalog? Each answer changes the scope, risk, budget, and migration timeline.
If the site is simply moving platforms and the business wants to keep the same content, structure, and design as much as possible, that leans toward migration. If the business wants to improve usability, rebuild page templates, rewrite core pages, rethink navigation, or reposition the brand, that leans toward redesign. If both are true, the project needs to be planned as both.
The SEO risks that turn a redesign into a migration problem
The most common redesign mistake I see is forgetting to keep track of URLs that need to be redirected. A team may remove pages, rename slugs, rebuild navigation, or change CMS structure without creating a redirect map. That is how a visual redesign turns into an SEO problem after launch.
The second big mistake is not having a content inventory. Without a content inventory, it is easy for pages to get missed. Important landing pages, older blog posts, resource pages, location pages, or campaign pages may never make it into the new site. Sometimes nobody notices until traffic drops or leads slow down.
A proper content inventory gives us a source of truth. It shows what pages exist, which ones get traffic, which ones have backlinks, which ones rank, which ones convert, and which ones can safely be removed or consolidated. Without that inventory, decisions are based on memory and preference, which is not enough for a serious website project.
Red flags during planning
One early warning sign that a migration is being underestimated is when someone says it will be “fast and easy.” That usually means they do not yet understand the moving parts. A small site can be straightforward, but that does not mean we skip planning. A large site, ecommerce site, or site with years of content needs more discovery before anyone touches design or development.
Another red flag is a proposal that jumps straight into design mockups without asking for planning documents, analytics access, sitemap exports, CMS access, or meetings with the people who understand the website. Good migration work starts with understanding the site. Planning documents and meeting requests are not busywork. They are how we avoid missing pages, breaking URLs, losing tracking, or launching with preventable technical issues.
What deliverables should you expect?
If you are comparing proposals, the deliverables should match the type of project. A redesign proposal should include strategy, sitemap or navigation planning, wireframes or design concepts, page templates, content recommendations, development, QA, and launch support. If SEO matters, it should also include content inventory review, redirect planning for changed URLs, metadata review, and post-launch checks.
A migration proposal should be more focused on preservation and technical accuracy. You should expect a content inventory, URL mapping, redirect strategy, staging review, analytics and tracking verification, technical SEO checks, launch plan, and post-launch monitoring. If those items are missing, ask why.
For both project types, I want to see evidence that the team understands the current website before changing it. That includes reviewing existing pages, analytics, search performance, conversion paths, technical constraints, and platform requirements. The website may look simple from the outside, but the details are what determine whether launch is smooth or messy.
Edge cases that make the decision more complicated
Ecommerce migrations are a good example of where the line gets blurry. The product data can often be migrated, but the method may need to be custom depending on the old platform and the new one. Product details, variants, categories, images, customer data, order history, and integrations all need careful handling.
At the same time, ecommerce platform changes often require redesign work because systems handle product pages, category pages, carts, checkout flows, filters, and account areas differently. You may be able to migrate the data, but the user experience will likely need to be redesigned around the new platform’s structure and limitations.
Other complicated cases include international websites, domain changes, rebrands, headless CMS moves, large content libraries, and sites with thousands of indexed URLs. In these situations, the question is not simply “redesign or migration?” The better question is, “What are we changing, what are we preserving, and what needs a specific plan so we do not lose value during launch?”
