The Deadline Decides What Moves
Migration usually sits inside a procurement timeline which shapes every decision made about the content. A platform has already been selected and a deadline already exists, so the content stops being a decision the organization makes and becomes a task it has to finish. Moving what already exists is the fastest way to hit the date. The platform that results is populated with the same unstructured pages, duplicated assets, and unowned content that made the previous environment difficult to maintain, which leaves the organization with a newer system and the original problem still intact.
Your Bill Arrives After The Migration
The cost of moving content without assessing it is not typically paid during the migration itself, rather the cost shows up much later, when the team that has to operate the new system discovers that the work it was meant to simplify is still fragmented. Duplicate content still has to be updated in several places. Pages with no clear owner still go stale. Any later initiative that depends on a clean content environment, including search, personalization, and AI retrieval, now operates against the same disorder, carried forward at the full cost of the migration.
The retrieval point deserves attention. A retrieval system, whether it powers internal search or an AI assistant, returns what is present in the environment, and it cannot distinguish current content from deprecated content. When unreviewed legacy material moves into the new platform unchanged, it becomes retrievable with the same authority as accurate content, and the error surfaces at the speed of the tool querying it rather than the speed of a person finding it.
Four Content Types Under One Label
The term "Legacy content" can refer to multiple varieties of material. Within any environment, some content is current and well structured, some is accurate but trapped in unstructured page layouts, some is duplicated across channels, and some is simply obsolete. These differences are typically not observable from page volume or the age of the platform alone. Often these content varieties are only made visible when content is assessed against the conditions that determine whether it will function in the new system: whether it is current, whether it is structured, whether it has clear ownership, and whether it can be reliably retrieved.
The deeper issue is that these conditions are more fundamentally governance conditions than they are content conditions. A page is unstructured because no content model required structure. It is duplicated because no owner was accountable for a single source. It is obsolete because no review workflow ever retired it. Treating these as problems to clean up mid-migration misreads them. They are the visible output of an operating model, and moving the content without addressing that model reproduces the output in a new location.
Retain, Restructure, Consolidate, Retire
Before a single asset moves, legacy content should be assessed and assigned a disposition. This is the work that reframes a migration from a simple transfer to a durable system. The assessment runs at the content type level rather than the page level, because accountability and structure are properties of types, not individual pages, and a decision made once for a type applies to every instance of it.
Each content type resolves to one of four dispositions. Retain covers content that is current, structured, and owned, and can move as it is. Restructure covers content that is accurate and valuable but trapped in a format the new model cannot use, and requires modeling before it moves. Consolidate covers content duplicated across pages or channels, where the migration is the moment to establish a single governed source. Retire covers content that no longer serves a purpose, where the most disciplined decision is often to leave it behind.
The value of the framework is not the four categories. It is that the assessment forces ownership and structure to be decided before the platform inherits them. A disposition cannot be assigned to a content type that has no owner, so the audit surfaces ownership gaps while there is still time to resolve them. The same findings define the content model the new platform requires, which means the migration stops being a cleanup exercise and becomes the first step in operating the new environment correctly.
Reordering The Migration Timeline
The assessment belongs in the planning phase, before the build, not in the period when content is being moved under deadline pressure. The sequencing is deliberate. Decisions about what to keep, restructure, consolidate, and retire shape the content model, and the content model shapes the platform configuration. When the order is reversed, the platform is configured first and the content is forced to fit it, which is how environments accumulate the structural debt the next migration will have to confront.
Assessing legacy content often reveals that a meaningful portion of it should not move at all, and that some of what remains needs work the original timeline did not account for. That finding can be uncomfortable, but it is far more useful before the migration than after. The teams that get the most from a new platform are the ones that resolved these questions during planning, when the cost of changing direction is still low.
A Moment To Examine What You Have
A migration is the rare moment when an organization has permission to examine its entire content environment at once. Treated only as a transfer, it preserves the conditions that made the old system difficult to operate, because nothing about those conditions was ever decided differently. Treated as a decision point, it becomes the place where the structure, ownership, and governance of the next environment are actually established. That work begins with an honest assessment of what you have, what it is worth, and what it would take to make it ready, and only then with the platform.