Website information architecture: How can the relationship between old and new pages be explained during content migration?

When a website goes through content migration, one of the first practical problems is keeping track of where each old page ended up. A straightforward way to handle this is to build a mapping document before the migration starts. For every old page, you record what happened to it: did it move to a new address, get merged into a larger page, get split into several pages, or get removed entirely. This document becomes the single reference that everyone on the team can check, and it prevents the situation where someone assumes a page still exists when it has actually been folded into something else.

The next question is how to communicate those relationships to the people who need them. Developers typically need a clean list of old URLs paired with their new destinations so they can set up redirects. Content editors need to understand which pieces of their work survived the migration and where they now live. These are different views of the same underlying data, so rather than maintaining separate documents that drift apart, it often works better to keep one source of truth and let each role filter or focus on the columns relevant to them.

For pages that were merged or split, the relationship is harder to express as a simple one-to-one redirect. In these cases, the mapping document should note the logic behind the decision. For example, if three old product pages became one comparison page, writing that down helps future editors understand why the old pages no longer exist and where to make updates going forward. Without that note, someone six months later may try to recreate a page that was intentionally consolidated.

Finally, it helps to distinguish between pages that are permanently gone and pages that are temporarily unavailable. If content is removed because it is outdated or no longer relevant, a clear note in the mapping prevents accidental restoration. If content is simply waiting for a rewrite, marking it as planned rather than deleted keeps the team from treating it as finished work. Keeping these status categories consistent across the document makes it easier to audit the migration afterward and spot anything that fell through the cracks.