How Long Does a Website Migration Take?

How long does a website migration take? For a typical marketing site where the migration is part of a rebuild, plan on roughly 8–12 weeks; larger migrations with many templates, heavy integrations or unready content take longer, because the individual phases alone can run from a few weeks to a few months each. The honest answer depends less on page count than on how many layouts you have, how ready your content is, and how carefully the old URLs have to be preserved.

This guide is for marketing leads, business owners and in-house teams who have been told their site needs to move: to a new CMS, a new platform, a new domain or a new design, often all at once. It breaks a migration into its phases, gives the duration range for each, explains what speeds each phase up or slows it down, and shows a worked illustrative schedule. It also covers the warning signs that a promised timeline is unrealistic.

One thing needs saying plainly at the start: no one can guarantee launch dates for a migration. A careful supplier can give you a realistic range, show you what the range depends on, and tell you quickly when something moves. Anyone who promises a fixed date before seeing your content, templates and integrations is guessing.

What "website migration" actually covers

The word "migration" gets used for several different jobs, and they take very different amounts of time. Being clear about which one you are doing is the first step toward an accurate schedule.

• Platform migration: moving the same content from one CMS to another, for example from a legacy system to WordPress or a headless CMS. The design may stay the same or change.
• Domain migration: moving the site to a new domain, which puts the whole URL structure through redirects at once.
• Structural migration: reorganizing navigation and URLs, merging or retiring sections, often as part of a content cleanup.
• Redesign with migration: a new design and new templates, with existing content moved into them. This is the most common case and the one this article mostly addresses.

Most real projects combine two or more. A redesign on a new CMS, with some URLs changing, is a platform, structural and design project all at once. The more of these you bundle, the more phases carry real work, and the more the schedule depends on decisions that only you can make. If you are still deciding between a platform switch and a light refresh, our guide to choosing between Wix and WordPress covers one of the most common platform questions.

It helps to remember what makes migration its own discipline. Moving a thousand existing pages, preserving their URLs and their formatting, is its own project with its own risks. The risk is not that pages fail to appear on the new site. It is that they appear at new addresses without redirects, lose formatting, lose metadata, or drop out of search results, and nobody notices for weeks.

The phases of a migration and how long each one takes

A migration follows the same broad phases as any website project, with extra work in the content and launch phases. The ranges below are the ones we plan with. They are ranges, not promises, and the reasons a project lands at one end or the other are covered in the sections that follow.

If every phase ran strictly one after another, those ranges would add up to 11 weeks at the short end (1 + 2 + 3 + 4 + 1) and 27 weeks at the long end (2 + 4 + 6 + 12 + 3). In practice, phases overlap: design can begin on the main templates while the content team is still deciding what to do with the long tail of old pages, and build can start on approved templates while the last ones are still in design. That overlap is how a standard marketing site with a migration fits into the 8–12 weeks turnaround we publish for that scope. It is also why the overlaps need managing; a design change late in the build ripples backward.

For comparison with a new build that does not carry a migration, see our article on how long it takes to build a website. The main difference is that a migration adds inventory, mapping and redirect work, and it removes the option of simply leaving old content behind without consequences.

What drives how long a website migration takes

Page count is the number everyone asks about first, and it is rarely the number that matters most. Six factors do most of the work in setting the schedule.

Templates, not pages

Every unique layout has to be designed, built, tested on different screen sizes, and then filled with migrated content that may not fit it neatly. Pages that share a template are, for the most part, handled in bulk once the template is done. That is why the build phase range runs from 4 to 12 weeks "depending on template count." Before asking anyone for a timeline, count the genuinely different layouts on your current site and in the new design. Our guide to scoping a website project walks through how to do that count.

Content readiness

This is the factor most within your control and the one most likely to decide your launch date. Content is "ready" when someone has decided which pages move, which merge and which retire; when the pages that move have been reviewed; and when any rewritten copy has been approved. A site with copy and images ready moves at roughly twice the speed of one where content is written during the build. If the content decisions are still open when the build finishes, the developers wait, and the schedule stretches accordingly.

Integrations

Each integration depends on a third party: their API documentation, their test environment, their support response, and sometimes their contract terms. An integration that looked like a day of work can take much longer if the vendor's sandbox is unavailable or the credentials sit with someone who has left the company. Identify every integration in discovery and find out who owns each account.

The accessibility target

Setting a clear target such as WCAG 2.1 AA at the beginning adds modestly to design and build. Discovering after launch that the migrated templates fail basic checks, and retrofitting them, costs several times more. For a migration, this also means checking old content: images without alternative text and documents that are not accessible will move across with the same problems unless someone fixes them on the way.

Migration volume and method

A few dozen pages can be moved by hand. Hundreds or thousands need a scripted import, which has to be written, tested on a sample, fixed and rerun. Old content often carries inline formatting, embedded widgets, shortcodes from retired plugins and broken internal links, and each of those needs a rule. Scripted imports are faster at volume but need a cleanup pass that people tend to underestimate.

Who maintains it afterward

A site your team can edit safely, with structured fields, sensible content types and guardrails, takes more thought during content modeling and build than one only a developer can change. It is almost always the cheaper of the two over three years, and it is worth the extra weeks. It also affects what happens after launch, which is covered in our article on what a website maintenance plan includes.

How the type of migration changes the schedule

The five phases apply to every migration, but the weight shifts depending on what kind of move you are making. Knowing where the effort concentrates for your type of project tells you which phase to watch most closely.

Platform moves with the same design

When the design stays largely the same and only the CMS changes, design work shrinks toward the short end of its range, since the job is mostly recreating existing layouts faithfully. The weight moves to build and content modeling: deciding how old content types map to new ones, writing the import, and checking that formatting survives. The trap is assuming "same design" means "no decisions." Old templates often contain one-off variations that were never documented, and each one has to be either rebuilt or consolidated.

Domain changes

A domain change can be technically simple if nothing else moves, but it concentrates risk into launch. Every URL on the site changes at once, so the redirect map covers everything, and both the old and new domains need to stay under your control afterward so the redirects keep working. Testing and launch deserves the full top of its range, and post-launch monitoring matters more than in almost any other type of migration. Because the risk is concentrated, it is usually wise not to combine a domain change with a large restructure unless there is a strong reason to do both at once.

Restructures and content consolidation

When the goal is to reorganize the site, merging overlapping pages and retiring outdated sections, the content and structure phase carries the heaviest load. Merging two pages into one is editorial work, not just technical work: someone has to decide which version is right, combine the useful parts and get it approved. Expect this phase to run toward the long end of its range, and expect the redirect map to be more complex, since many old URLs will point to a smaller set of new ones.

Redesigns with migration

The most common case uses every phase fully. New templates mean real design time, new layouts mean the import has to transform content rather than simply copy it, and new navigation usually means URL changes. This is the shape our marketing-site scope is built around. It is also where scope creep most often appears, because a redesign invites new ideas, and every new template added after design approval lengthens the build.

Small sites and microsites

At the other end, a landing page or small microsite being moved or rebuilt is a much shorter job; our published turnaround for that scope is 3–5 weeks. Even at that size, the old URLs still need redirects and the forms still need testing. If you are not sure whether you need a full site or something smaller, our comparison of landing pages and full websites can help you decide before you plan a migration you may not need.

What speeds each phase up, and what slows it down

Every phase has its own accelerators and its own common delays. Knowing them lets you do the preparation that actually shortens a schedule, rather than simply asking for a shorter one.

Discovery (1–2 weeks)

Speeds it up: a complete crawl of the current site, access to analytics and search console data, a list of integrations with owners, and one person who can make scope decisions. Slows it down: missing access to hosting, DNS or the old CMS; stakeholders who disagree about goals; and discovering part-way through that a second site or subdomain is also meant to be migrated.

Content and structure (2–4 weeks)

Speeds it up: a content inventory with a clear decision for every URL (keep, merge, rewrite, retire), a named content owner for each section, and agreement that low-value pages will be retired rather than moved. Slows it down: committee review of every page, rewriting copy that was supposed to be moved as is, and delaying hard decisions about old sections until after design. This is the one that slips, so it deserves the most attention in your planning.

Design (3–6 weeks)

Speeds it up: an existing brand system, a short list of approvers, and designing the highest-volume templates first so build can start on them. Slows it down: reopening brand questions during website design, adding new stakeholders for review late in the phase, and designing for idealized content rather than the real migrated pages, which then do not fit.

Build (4–12 weeks)

Speeds it up: approved designs, a fixed template list, integration credentials in hand, and an import script tested on a representative sample early. Slows it down: template additions after build starts, integration partners who are slow to respond, and import edge cases found late. Technical choices matter here too; guidance on rendering strategies for websites explains decisions that affect both build time and performance.

Testing and launch (1–3 weeks, plus the redirect map)

Speeds it up: a redirect map that was built during the content phase rather than at the end, a staging environment that mirrors production, and a launch checklist agreed in advance. Slows it down: redirect mapping left until launch week, DNS or hosting access held by a third party, and launching into a busy trading period with no freeze on content changes.

Milestones and approvals that keep a migration moving

A migration schedule is only as reliable as its approvals. Each phase ends with a decision, and if that decision takes two weeks instead of two days, the schedule moves by the difference. Agree who approves each milestone before the project starts, and how long they have to do it.

Two of these tend to cause the most trouble. The content inventory sign-off requires people from different departments to agree about pages they each feel they own. The import sample review is where content owners first see their pages in the new templates and realize some need rework. Schedule both with enough room, and make sure the people approving them know the dates in advance.

A worked illustrative schedule

The following schedule is illustrative. It is not a client project; it shows how the phase ranges combine for one plausible migration, with overlaps, so you can see where the weeks go.

Imagine a company moving a site of about 400 pages from an aging CMS to a new one, with a redesign. The new design has seven unique templates. There are two integrations: a CRM for form submissions and an events feed. Most content will be moved as is, but around a quarter of the old pages will be retired or merged. The content owners have agreed to a two-day turnaround on approvals.

Added end to end, those durations come to 22 weeks (2 + 4 + 5 + 9 + 2). Because design overlaps the last two weeks of content and structure (weeks 5 and 6), and build overlaps the last two weeks of design (weeks 8 and 9), the calendar length is 18 weeks. That is longer than the 8–12 weeks turnaround for a standard marketing site because this example has more templates, a scripted import of several hundred pages and a quarter of the content being restructured.

Where this schedule could stretch

• If content decisions on the retired and merged pages ran past week 6, design of the templates that hold them would wait, and build would follow.
• If the CRM vendor's test environment were unavailable for a week during build, that integration would finish late, and testing would start late.
• If the import sample in week 10 or so revealed widespread formatting problems in old content, the cleanup could add a week or more to build.

Where it could shrink

• If the content inventory were already done before discovery, content and structure could come in at the short end of its range.
• If two of the seven templates were merged during design, build would have fewer layouts to develop and test.
• If the old site's content were clean and consistently structured, the import would need less cleanup.

Notice that none of the ways to shrink the schedule involve asking the team to work faster. They all involve reducing uncertainty or scope before the work that depends on it starts.

Warning signs that a promised timeline is unrealistic

When you are comparing suppliers, the shortest timeline is not necessarily the best one. A timeline that ignores the real work tends to produce a late launch anyway, just with less warning. Our comparison of freelancers and agencies covers how different kinds of suppliers plan, but the warning signs below apply to any of them.

A realistic proposal will usually do the opposite: give ranges, name the assumptions behind them, identify which phase is most likely to slip, and state what it needs from you and by when. It may look less confident on paper. In practice it is the one more likely to land on time.

How budget and timeline relate

Time and cost are driven by the same factors: templates, content readiness, integrations, accessibility, migration volume and maintainability. That means a scope that takes longer usually costs more, and a request to go faster usually means either reducing scope or adding people, which has limits.

For reference, our published starting rates are: a landing page or microsite from $4,800 per project, with a turnaround of 3–5 weeks; a marketing site from $18,000 per project, the usual shape of which includes a set of templates, real content, real integrations and a migration, with a turnaround of 8–12 weeks; and retained engineering from $145 per hour, for a developer on your stack for an agreed share of each month, with a start within 2 weeks. These are starting prices, not guaranteed totals, and a real quote depends on your scope.

Typical US market ranges give further context. A small marketing site of five to fifteen pages with a handful of templates usually falls between $6,000 – $20,000. A business site with systems, including custom templates, real integrations, structured content, a migration and a proper testing pass, usually falls between $20,000 – $75,000. A large or complex build, such as multi-language sites, complex integrations or design systems, is typically $75,000+. Our guide to what a website costs explains those ranges in more depth.

If the budget and timeline you need do not fit the scope you want, a phased launch is often the answer: move the most important sections first, retire or redirect the rest, and migrate the long tail afterward. Our guide to phased website launches explains how to do that without leaving visitors on two half-sites.

Staying on schedule once the migration starts

Most migration delays come from the client side of the project, not because clients are careless, but because migrations need decisions from people who have other jobs. The checklist below is the preparation that makes the most difference. Much of it overlaps with our website redesign checklist, which is worth reading before you start.

The last item matters more than it seems. A migration is not finished at launch. Search engines need time to recrawl the site and process redirects, and old links from other sites keep arriving for a long time. Someone should watch error reports and search performance closely for the first weeks and fix missing redirects as they appear. Structured data, such as schema markup on key templates, often needs checking at this stage too.

Planning your own migration timeline

To turn all of this into a schedule for your site, work through it in order. Count your unique templates, old and new. Inventory your content and decide how much of it is ready. List every integration and who owns it. Set your accessibility target. Estimate how many pages need a scripted import versus manual handling. Decide who will maintain the site afterward. Then place each phase within its range: discovery 1–2 weeks, content and structure 2–4 weeks, design 3–6 weeks, build 4–12 weeks depending on template count, testing and launch 1–3 weeks plus the redirect map, and look for where the phases can safely overlap.

For a deeper look at the planning side, including how to sequence content, redirects and search checks, read website migration planning: what actually works. And if you want a supplier to do this with you, a good one will start by asking the questions in this article rather than by naming a date.