The conversation usually goes something like this. A client commissions a new website. The proposal covers design, development, technical configuration, training, launch. Budget is approved, contracts are signed, the project gets underway. A few weeks in, the developer raises a question: “Where is the existing content coming from?” The client looks confused. The developer explains. The client says, “We assumed you’d handle that.” The developer says, “We can handle the migration, but the content itself needs to come from somewhere — and a lot of it will need to be rewritten or reformatted.” The client says, “How much extra is that going to cost?”
This conversation repeats itself, in some form, on a significant proportion of website projects. It happens because content migration is one of the parts of a website rebuild that nobody adequately scopes upfront — not the client, not the developer, sometimes not even the agencies who handle web projects professionally. The work is real, often substantial, and almost always more involved than anyone has budgeted for. Setting the expectation early is one of the simpler ways to avoid a difficult conversation later.
What “content migration” actually involves
The phrase “content migration” makes it sound mechanical. Move the words and pictures from the old site to the new one. In reality, the work is several things at once, each of which carries its own cost.
The most basic part is the actual transfer of content from one system to another. For a site with a few dozen pages, this can be done manually. For a site with hundreds or thousands of pages, automated migration tools become necessary, and they vary in how well they handle the various WordPress content structures — pages, posts, custom post types, custom fields, taxonomies, media. Even with good tools, migration of complex sites often requires custom scripting to map the source content correctly to the destination.
The second part is reformatting. Content that worked on the old site may not work on the new one. Layouts that were built using one page builder do not transfer cleanly to a different one. Custom HTML embedded in pages may not render correctly under a new theme. Image dimensions that were correct for the old design may need adjustment for the new one. Each piece of content has to be reviewed and, often, restructured before it works in its new home.
The third part is rewriting. A rebuild is usually an opportunity to improve the content as well as the design. Outdated information is updated. Marketing-led pages that have not been touched in three years get refreshed. The about page, which everyone has been quietly embarrassed about, finally gets the attention it needed. The team may have a content strategy for the new site that requires writing entirely new pages, or restructuring existing ones into new information architectures.
The fourth part is curation. Not all content from the old site belongs on the new one. Pages that were created for past campaigns. Blog posts that are out of date. Product pages for products no longer sold. Someone has to go through the old site and decide what to keep, what to redirect, what to retire, and what to rewrite. This is judgement work, and it cannot be automated.
The fifth part is what to do with the historical record. A blog with eight years of posts is not just current content; it is an archive. Decisions about what happens to that archive — keep everything, prune aggressively, restructure entirely — affect SEO and how much migration work is involved.
Why this is consistently underestimated
Content migration is underestimated for a few specific reasons, and naming them helps explain why the conversation keeps repeating itself.
The first is that the work happens at the intersection of two roles, and falls into the gap between them. The developer assumes someone on the client side will produce the content. The client assumes the developer will handle whatever needs handling. Neither party has fully owned the migration in scope, and neither has fully costed it.
The second is that the cost is invisible at the proposal stage. The proposal lists deliverables — design, build, configuration, launch — and assigns prices to each. “Content migration” tends to appear as a line item with a placeholder estimate, or worse, as something embedded in another line item without separate visibility. The client signs the proposal not knowing what the migration work will actually require. The developer signs it not knowing exactly what the source content looks like.
The third is that the old site is rarely as clean as everyone assumes. Inherited from previous teams, edited by various people over years, the source content is usually messier than a quick glance suggests. Inconsistent formatting. Embedded shortcodes from plugins that no longer exist. Images stored in unexpected places. The cleanup work tends to expand once the migration actually starts.
The fourth is that content production is genuinely time-consuming, regardless of who is doing it. A page that “just needs a small rewrite” is half a day’s work for a competent writer. A site with fifty pages and four hours of work per page is a substantial project on its own. The hours add up faster than the proposal anticipated.
How to scope it honestly
The fix is not to underprice the work and absorb the difference. It is to scope content migration as its own line item, with realistic assumptions, and to surface the conversation early when the client still has options about how to handle it.
The first step is an audit of the existing site. A spreadsheet listing every page, every post, every custom content type. For each item, a note on what is happening to it: kept as-is, kept with minor edits, rewritten substantially, retired entirely, replaced by something new. This audit produces the basis for an accurate migration estimate.
The second step is to be clear about who is writing what. Three scenarios are common. The client provides all new and updated content, on a timeline the developer can work to. The developer’s team writes the content, at additional cost. A specialist content writer is brought in, separately scoped, to handle the writing while the developer handles the technical migration. Each scenario has different cost implications, and choosing among them is the client’s decision once the implications are clear.
The third step is to budget realistically for the actual migration mechanics, separate from the writing. Even if all the writing is handled, someone has to enter the content into the new system, format it correctly, attach images, set metadata, configure SEO fields, and verify the result. This is often more work than the client expects. Costing it as its own activity, with its own hours and rate, prevents the work from being absorbed into other line items where it is invisible.
The fourth step is to plan for redirects. Every URL that exists on the old site and changes on the new one needs a redirect to preserve SEO and to support external links and bookmarks. Producing a clean redirect map is fiddly work, and it scales with the size of the site.
The conversation worth having upfront
The conversation that prevents the surprise is one most clients have never had with a developer. It goes something like this.
Your new site will need content. Some of it will come from the existing site, some will be rewritten, some will be entirely new. The work of moving, rewriting, and entering all this content is substantial — usually somewhere between twenty and forty per cent of the total project effort, depending on the size of the site and the amount of new content. Who is going to do that work?
The answers vary. Some clients have in-house copywriters who can produce the content on their own timeline. Some prefer to have the agency handle it. Some are happy to leave the existing content largely as it is. All of these are valid. What is not valid is leaving the question unanswered, and discovering halfway through that nobody was scoped to handle this part.
Asking the question early is professional. Sending an invoice for unscoped work three months in is not.
The short version
Content migration is one of the most consistently underscoped parts of a website rebuild. It involves transferring, reformatting, rewriting, curating, and archiving — none of which is mechanical, and most of which adds up to a substantial chunk of the project effort. Clients assume the developer is handling it; developers assume the client is producing the content; the gap between those assumptions is where projects go awkward. Scoping it honestly upfront — auditing the existing content, deciding who writes what, costing the migration mechanics separately, planning for redirects — prevents the surprise. The work is real either way. Naming it before the project starts is the difference between a client who feels well-served and one who feels caught out.
