The rebuild preserved the pages. Did it preserve the relationships?

A page-count report says the migration completed. The catalogue opens. The document library loads. Yet a product variant points to the wrong specification, a category no longer includes its items, or a document has lost the model range it applies to. The pages survived; the relationships may not have.

This gap appears when acceptance checks count records or URLs but do not test what those records mean together. A site is not only a set of pages. It is a model of entities, identifiers, relationships, publishing rules and routes through which people use them.

Inventory the relationships that matter

Choose important journeys and list the entities involved. A product might connect to variants, technical documents, categories, compatible equipment and an enquiry route. A course might connect to a provider, location, requirements and an application action. The map should reflect the actual service, not just the fields the old CMS happened to expose.

For each relationship, identify its source representation, destination field, transformation rule and owner. If a relationship is embedded in page text, a plugin table or a spreadsheet, record that explicitly. It may need a deliberate migration rule before the build starts.

Test samples for meaning, not just insertion

Select representative records: a straightforward item, a variant, an exception, a retired record and one with a document or special publishing rule. For each, compare source and destination identifiers, relationships, visible output and expected user action. Include edge cases that stress the model rather than a large sample of nearly identical pages.

An inserted row count can establish that data arrived. It does not establish that a document is still linked to the correct revision or that the page exposes the relationship in a useful way. Keep evidence of the source, expected relationship, migrated value and rendered result so a reviewer can see why the check passed.

Make exceptions visible

Some source records will be incomplete or contradictory. Do not silently guess. Route each exception to a decision owner, record the chosen treatment and identify whether the repair belongs before migration, in transformation, or after publication. This lets the programme distinguish an accepted source limitation from a migration defect.

The acceptance record should also show what remains outside the sample. Sampling can provide useful evidence, but it is not exhaustive verification. Agree who owns residual risk, what monitoring follows launch and how users report a broken relationship that the selected checks did not cover.

Treat redirect checks as one layer

Redirects protect routes from old URLs to new destinations. They do not prove that a page retains its taxonomy, internal links, document associations or next action. Keep URL mapping in the migration plan, then run relationship checks beside it. A good launch decision considers both access and meaning.