How Much Does a Website Content Migration Cost?

The short answer: website content migration cost is usually carried inside a rebuild rather than priced on its own. In the US market, a business site that includes custom templates, integrations and a migration typically runs $20,000 – $75,000, and our marketing site projects, which include a migration, start from $18,000 per project. Very large, multi-language or system-heavy migrations sit in the $75,000+ band.

That answer hides a lot of variation, and the variation is the useful part. Moving forty pages from one CMS to another with the same URLs is a different job from moving a thousand pages, their images, their embedded forms and years of inconsistent formatting into a new structured content model while keeping every URL that earns search traffic. Both are called "content migration," and both can appear as one line on a quote. The difference between them is what this guide is about.

It is written for marketing leads, founders, operations managers and in-house web teams who have a migration coming and need to budget for it, compare quotes, or explain the number to someone else. We cover the pricing models suppliers use, the published ranges and what they include, the factors that move a migration up or down, an illustrative budget built from real published rates, how to get a quote you can rely on, the red flags in cheap quotes, and how to budget for the months after launch.

What a content migration actually includes

Before comparing prices it helps to be clear about the work, because quotes often differ mainly in what they leave out. A complete content migration has six parts, and each one costs something whether or not it appears on the quote.

1. Inventory. A list of every URL on the current site, with its template, its traffic, its inbound links and a decision: keep, merge, rewrite or retire. On a small site this is a spreadsheet and an afternoon. On a large one it is a project in itself.
2. Content modeling. Deciding how content will be structured in the new system: which content types, which fields, which relationships. Moving from page-shaped content (a big rich-text body) to structured content (separate fields for summary, author, product, specifications) is where most of the design effort in a migration goes.
3. Transfer. Moving the content itself, by script, by hand or by a mix. Scripts handle volume; people handle the pages that do not fit a pattern.
4. Cleanup. Fixing what the transfer exposes: inline styles, broken embeds, images with no alternative text, headings used for decoration, links to pages that no longer exist.
5. Redirects. A map from every old URL that is changing to its new home, implemented as permanent redirects and tested. This is the part that protects search traffic and inbound links.
6. Verification. Checking that what arrived matches what left: page counts, spot checks of formatting, link checks, redirect tests and a review by someone who knows the content.

If a quote does not say which of these it covers, ask. A price that includes transfer but not cleanup or redirects is not cheaper; it moves the cost to you, usually after launch. Our guide to website migration planning goes through each stage in more depth.

Pricing models for website content migration, and what each includes

Suppliers price migrations in a handful of ways. None is inherently better; each suits a different level of certainty about the content. What matters is that you know which model you are buying and what it does and does not cover.

Fixed project pricing

A fixed price works when both sides can describe the job precisely: how many templates, how many content items of each type, which integrations, which URLs change. The supplier carries the risk of the estimate, so a fixed price includes a margin for the unknowns they can see. The better your inventory, the smaller that margin needs to be. Fixed prices also come with a change process: anything outside the agreed scope is quoted separately, which is fair, but it means an incomplete inventory at the start becomes a series of change requests later.

Migration bundled into a rebuild

Most migrations happen because a site is being redesigned or moved to a new platform, so the migration is a phase of a larger project. In that case it is sensible to look at the whole budget rather than the migration line alone, because decisions in one area move costs in another. A new content model makes the migration more expensive and the future site cheaper to maintain; keeping the old structure does the opposite. Our overview of how much a website costs covers the full budget.

Per-page pricing

Per-page pricing is attractive because it is simple to compare and easy to multiply. Its weakness is that pages are not the unit of effort. Templates are. A thousand blog posts that share one template and clean formatting can be moved by script with a modest amount of checking. Forty landing pages built individually over five years, each with its own layout and embedded tools, may take longer than the thousand posts. If a supplier quotes per page, ask what a "page" includes and what happens to pages that do not fit the pattern.

Hourly and retainer pricing

Time-based pricing suits migrations where the content is too inconsistent to estimate confidently, or where the migration will happen in waves alongside other work. It gives you control and transparency: you see where the hours go. It also puts the estimating risk on you, so it works best with a clear backlog and regular reporting. For a fuller comparison of the two approaches, see website retainer vs project pricing.

Published price ranges compared with our starting rates

The table below sets reviewed US market ranges next to our published starting rates. Our rates are starting prices, not guaranteed totals; the figure for your project depends on its scope, and a quote turns it into one number. Where we do not publish a rate for a market band, the cell says so.

Two readings of that table are worth drawing out. First, the market's own descriptions put migration inside the business-site band: "custom templates, real integrations, structured content, a migration, and a testing pass that deserves the name." If you are comparing a business site quote with a small marketing site quote, check whether the lower one includes migration at all. Second, a landing page or microsite rarely involves a meaningful migration; if you are moving only a few pages, the question may be whether you need a full site at all, and that is worth answering before anyone prices a migration.

What drives website content migration cost

Six factors account for most of the difference between one migration quote and another. They apply to whole site projects too, but each has a specific effect on the migration part of the work.

Number of unique templates

A fifty-page site with six templates is a much smaller job than a twelve-page site with eleven. Count layouts, not pages. For migration, each template on the old site needs a mapping to a template on the new one, and each mapping needs its own transfer rules and its own checks. A site with a small number of consistent templates can be migrated largely by script; a site where every important page was built by hand usually has to be migrated largely by hand.

Content readiness

A site with copy and images ready moves at roughly twice the speed of one where content is written during the build. In a migration, "ready" means the inventory is done, the keep-merge-retire decisions are made, and someone with authority has signed off on them. The content and structure phase is the one that slips, and it slips because decisions about content are harder to make than decisions about design. A migration where rewriting happens during transfer is really two projects running at once.

Integrations

A CRM, a booking system, a payment gateway, a legacy inventory feed. Each one is a separate contract with somebody else's API and somebody else's outage. In a migration, integrations matter in two ways: content that lives in another system (product data, event listings, staff directories) has to be moved or reconnected, and forms or embeds on old pages have to be rebuilt against the new platform. Each one adds build and testing time.

Accessibility target

Meeting WCAG 2.1 AA from the start adds modestly to design and build. Retrofitting it later costs several times more. Migration is the natural moment to fix accessibility debt in content: missing alternative text, headings used for styling, link text that says "read more," tables used for layout. Fixing those during transfer is much cheaper than finding them in an audit after launch, but it is work, and a quote should say whether it is included.

Migration volume and URL preservation

Moving a thousand existing pages, preserving their URLs and their formatting, is its own project with its own risks. Volume changes the method: a few dozen pages can be moved and checked by hand, while hundreds or thousands need scripts, sampling-based verification and a disciplined redirect map. Preserving URLs where possible reduces redirect work and risk; changing the URL structure is sometimes worth it, but it should be a deliberate decision with a cost attached.

Who maintains it

Building something you can edit safely costs more up front than building something only we can change. It is almost always the cheaper of the two over three years. For a migration, this is the choice between moving content as it is (large rich-text blobs that look the same but remain hard to edit) and moving it into structured fields that editors can update without breaking layouts. The second costs more during migration and less every month afterward. If you are also choosing a new CMS, settle that choice before the content model is fixed, because the content model depends on what the CMS does well.

An illustrative migration budget

This example is illustrative. The company and its choices are invented to show how a budget is assembled; the only prices used are our published starting rates. Real quotes depend on scope, and none of these figures is a guaranteed total.

A professional services firm has a site of about 300 URLs on an aging CMS: 12 service pages, 40 team profiles, around 220 blog posts, a handful of case study pages and some legacy landing pages. The old site uses nine distinct layouts. The firm wants to move to a new CMS with structured content, keep the blog URLs unchanged, consolidate service pages from 12 to 8, and connect its CRM to the contact forms. After the inventory, it decides to retire about 30 legacy landing pages and redirect them to the most relevant current pages.

Assembling the budget

• Core project: This is the usual shape of a marketing site: a set of templates, real content, real integrations and a migration. Our marketing site projects start from $18,000 per project, with a turnaround of 8–12 weeks. That is the starting point, not the final number; the nine source layouts, the CRM connection and the service page consolidation are the things a quote would price.
• Post-launch cleanup: The firm expects its older blog posts to need formatting and alternative text fixes that are not worth doing before launch. It budgets retained engineering at our starting rate of $145 per hour. At an illustrative 24 hours, that is 24 × $145 = $3,480.
• Illustrative starting budget: $18,000 + $3,480 = $21,480, as a floor for planning, before the quote refines the core project figure.

Compared with the market, that illustrative floor sits at the low end of the $20,000 – $75,000 range for a business site with systems. Where the final quote lands within or above that floor depends on the factors described earlier, above all the nine source layouts and how much of the older content needs restructuring rather than simply moving. If the firm had also wanted to restructure its blog into a new URL scheme, add a second language or connect a legacy inventory feed, the project would move up that range, and a second language on top of complex integrations could push it toward the $75,000+ band.

Where the illustrative budget could move

Each of the cost drivers maps onto a specific decision in this example. If the firm reduced its nine source layouts to a smaller number of new templates, the migration rules would be simpler and the build shorter. If its content decisions were signed off before discovery ended, the content and structure phase would be less likely to slip. If the CRM connection turned out to require custom work on the CRM side, that integration would carry its own cost and its own testing. And if the firm chose to move its 220 blog posts as-is rather than into structured fields, the migration would cost less now and the blog would stay harder to maintain. None of these choices is right or wrong in the abstract; the point is that each one has a price, and the quote should show where it went.

What the budget does not include

Internal time is the cost most often left out. Someone at the firm has to own the inventory decisions, review migrated content, approve the redirect map and answer questions quickly. The content and structure phase is the one that slips, and it usually slips because those decisions wait on busy people. Put the internal owner's time in the plan, even if it never appears on an invoice.

How long a migration takes, and why time is part of the price

Time and cost move together, because most of what you pay for is people's time. Our landing page and microsite work runs to a turnaround of 3–5 weeks; marketing site projects, which include a migration, run 8–12 weeks. A typical project moves through these phases:

• Discovery: 1–2 weeks. Inventory, goals, integrations and the decisions that shape everything else.
• Content and structure: 2–4 weeks, and this is the one that slips. Content modeling, keep-merge-retire decisions and the start of the redirect map.
• Design: 3–6 weeks.
• Build: 4–12 weeks depending on template count. The transfer scripts and templates are built here.
• Testing and launch: 1–3 weeks, plus the redirect map.

The phase ranges describe the spread across very different projects, and on a given project some phases overlap: content work usually continues while design is underway, and migration scripts are often tested against real content during the build. The practical lesson is that the content and structure phase controls the schedule. A migration where content decisions are made early can finish toward the short end of its range; one where they drift can blow through it. For a fuller treatment of schedules, see how long a website migration takes.

How to get an accurate quote for a content migration

An accurate quote depends mostly on what you give the supplier. Vague inputs produce either a high quote with a large contingency or a low quote with a long list of exclusions. The procedure below produces inputs that let a supplier price with confidence.

Red flags in cheap quotes, explained

The warning list above is short so that it can be used as a checklist. Each item deserves a sentence or two on why it matters, because some of them only show their cost months after launch.

Missing redirects

Redirects are what keep old links working: links from other sites, bookmarks, emails, printed materials and search results. A migration without a tested redirect map can lose traffic that took years to build. Redirect work is not hard, but it is detailed, and it takes time to do properly. A quote that leaves it out is cheaper because it has left out a necessary part of the job.

Undefined pages and "automated" transfer

Scripts are the right tool for moving content at volume, and any sensible supplier will use them. The question is what happens around the script. Content from older systems carries formatting quirks, embedded code and broken references that a script will carry across faithfully. Without a cleanup and verification step, those problems arrive on the new site intact, and they tend to be found by visitors.

Content moved as blobs

Moving each page's body into a single large field is the fastest way to migrate, and sometimes it is the right call for archive content that will never be edited. For content that will be maintained, it keeps the old site's problems on the new platform. The editors who were promised easier updates find themselves editing the same tangled markup in a new interface. This is where the "who maintains it" factor shows up in real costs.

No inventory, no testing, no owner

A supplier who quotes without an inventory is guessing, and guesses tend to be optimistic in the quote and expensive in the change requests. A project without a testing phase finds its problems in production. A project without a named content owner on the client side stalls in the content and structure phase, which is the one that slips. Each of these is cheap to fix before the project starts and expensive afterward.

Budgeting for the months after launch

A migration is not finished on launch day. The first weeks afterward reveal broken links that the crawl missed, redirects that need adjusting, content that editors want to restructure now that they can see it in the new system, and search performance that needs watching. Budget for that period explicitly rather than hoping it will be quiet.

The first few weeks

Plan for monitoring and fixes: checking crawl errors and 404 reports, correcting redirect targets, and fixing the handful of pages that did not migrate cleanly. On a time-based arrangement, this is where retained engineering at our starting rate of $145 per hour is often used, because the amount of work is hard to predict and usually small. Our retained engineering can start within 2 weeks, so arrange it before launch rather than after the first problem appears.

The first year

After the launch period, costs shift to maintenance: platform updates, security patches, small improvements and ongoing content work. If you migrated in phases, later sections may still be scheduled. Our guides to what a website maintenance plan includes and to phased website launches cover both. Phasing is a genuine budgeting tool: moving the most important sections first and the archive later spreads cost across budget periods and lets you learn from the first wave.

Three years out

Over a three-year view, the decision that matters most is the one about maintenance. A site built so that editors can change it safely costs more at the start and less every year after. A site that needs a developer for every edit looks cheaper on the migration quote and more expensive in every budget that follows. When comparing quotes, ask each supplier what a routine content change will cost after launch, and who will make it.

Planning the migration before you ask for money

Most of the savings in a migration come from work done before any supplier is involved. A completed inventory, a set of signed-off content decisions and a clear URL policy make quotes lower, more comparable and more reliable. They also shorten the content and structure phase, which is the part most likely to slip.

If you are migrating as part of a redesign, work through a website redesign checklist first; many of its items are also migration inputs. If structured data matters to your search presence, plan how it will be carried across or improved, because a migration is a natural time to add it; our guide to structured data for websites explains what is worth doing. And if you want to see how we run projects of this kind and how we check them, our web design and development page covers the process and the rates in one place.