Content migration — the work nobody quotes

Content migration — moving every existing page, image, downloadable file and piece of metadata to a new platform — is frequently treated as an afterthought to the visible design work of a rebuild, when for a site with years of accumulated content it can represent a comparable, sometimes larger, share of the actual project effort.

Why content migration gets underquoted so often

A redesign brief is usually scoped around what is visible and countable — the number of new page templates, the number of core service pages, the visual design process. Content migration is the opposite: it is a long tail of individually small tasks — checking that page forty-seven’s images moved across correctly, that its internal links still point somewhere real, that its metadata survived the transfer — that is hard to estimate precisely in advance and easy to underestimate as “just moving what’s already there”, particularly when the old and new content management systems structure the same content in genuinely different ways underneath.

What a realistic migration scope actually includes

Every page of body content, checked for formatting integrity after any automated import — headings, lists, embedded links and any custom formatting frequently need manual correction rather than transferring perfectly.

Every image and downloadable file, not just linked but re-uploaded or correctly redirected at its original file path if external sites or search engines have indexed the direct file URL.

Metadata — title tags, meta descriptions, and any structured data attached to each page, which an automated import very often does not carry across at all, silently leaving new pages with generic or missing metadata until manually restored.

Internal links between pages, which need to be checked against the new URL structure — a link from one migrated page to another that still points at the old URL structure is a broken internal link on day one of the new site.

Forms and their underlying configuration, including where submissions are sent and any validation logic, which rarely migrates automatically at all and typically needs to be rebuilt directly on the new platform.

Content Google has indexed that no longer appears in the current sitemap

A site accumulated over years frequently has pages Google has indexed that are no longer linked from current navigation and do not appear in the current XML sitemap — an old promotion page, a discontinued service, a blog post the current content management workflow has forgotten about. These pages still carry indexed status and, in some cases, real ongoing organic traffic, and a migration plan built only from the current sitemap or the current navigation menu will miss them entirely. The reliable way to catch them is a full crawl of the live site combined with an export of every URL Search Console reports as indexed, cross-referenced against each other — the sitemap alone is not a complete inventory of what actually needs a decision made about it.

User-generated content and third-party embeds

Blog comments, customer reviews stored directly in the old platform, and embedded content from third-party services (a booking widget, a chat history, an old payment provider’s iframe) frequently do not migrate through a standard content export at all, because these tools are often not built to be portable in the first place. Each of these needs its own specific decision — recreate it on the new platform, archive it separately, or accept its loss — made deliberately rather than discovered as a gap after the new site is already live and someone asks where the reviews went.

A realistic way to scope the content migration, rather than guess

Migration task	Why it takes real time
Body content per page	Formatting and structure frequently need manual correction after import
Images and files	Re-uploading and confirming file paths, particularly where external links point directly at a file
Metadata per page	Commonly lost entirely in an automated import
Internal links	Need checking against the new URL structure, not assumed to transfer
Forms	Usually need rebuilding directly on the new platform, not migrating
Structured data	Platform-specific; rarely carries over automatically at all

Verifying migrated content against the original, not just checking it renders

Confirming a migrated page “looks fine” on the new platform is a weaker check than confirming it says the same thing the original did — a formatting fix applied during migration can silently drop a paragraph, a caveat, or a legally significant qualifier (a disclaimer, a scope limitation, a price condition) without the page looking visibly broken. For content where the specific wording carries real weight — pricing conditions, compliance statements, service inclusions and exclusions — a direct text comparison between the old and new version of each page, not just a visual glance, is worth the extra time it takes.

Why this connects directly to the ranking risk

Content migration and URL redirection are two separate jobs that are easy to conflate. A correct redirect map, covered on redesigning without losing rankings, sends a visitor or a search engine to the right new URL — but if the content that arrives at that URL has lost its original structure, formatting or internal links during migration, the redirect having worked correctly does not fix a page that is now a worse version of what used to rank there.

What to do next

Ask specifically, before signing a rebuild quote, whether content migration is included as a line item with its own estimated scope, or bundled vaguely into “site build” — the latter is where this work most often gets underestimated. A written migration checklist, rather than a vague assurance that everything will move across, is what actually streamlines the process and gives both sides a shared definition of what a successful migration looks like before work starts. For what this typically adds to a project’s overall cost, what drives the cost of a website sets out where migration work sits alongside design and development.