Verify content survived a website migration

Define the content contract before import

List the content types and fields that carry meaning: title, body, summary, author, dates, attachments, image context, language, relationships and publication status. Decide which fields should transfer unchanged, transform or be intentionally retired. Record the reason and responsible approver for each transformation. A field that appears empty in a sample may still matter elsewhere, so inspect its actual use before dropping it. Preserve a readable source snapshot or export under the appropriate retention rules. Without a stable comparison baseline, a dispute about missing information becomes difficult to resolve.

Map records and transformations explicitly

Drupal's migration documentation separates source, transformation and destination stages and describes mapping source identifiers to destination identifiers. The general lesson is to make the correspondence inspectable, while implementation differs by platform. Ask for a mapping that lets an editor trace a source record to its destination and understand any conversion. Check relationships such as an article's author, translated counterpart or attached guide rather than only the main text field. A successful row import can still point to the wrong related object. Record expected omissions separately from unexpected failures.

Compare representative and consequential cases

Select examples from every meaningful content type, including unusual formatting, older records, multiple attachments and consequential public instructions. Combine broad automated checks with manual comparisons of meaning and rendered output. Counts can reveal missing records, but matching counts cannot prove correct content. Look for lost inline emphasis, broken references, altered dates, missing image descriptions and private drafts accidentally published. Expand the investigation when a shared transformation fails instead of repairing only the sampled page. Keep the sample design explicit so stakeholders understand what the review can and cannot establish.

Accept the collection with known exceptions

Track each mismatch to a transformation rule, source issue or rendering problem and assign an owner. Agree which failures block launch and which can be accepted temporarily with an authorized mitigation. Reconcile edits made during the migration window so a late source correction is not overwritten by an older import. Retest repaired mappings against affected records and the original sample. Keep final counts, reviewed examples, unresolved exceptions and acceptance authority together. Retiring the old system is a separate decision involving retention, recovery and operational dependencies; a passed editorial sample alone does not authorize it.

Make the reasoning concrete.

A hypothetical association moves an archive of practical guides into a CMS with separate media and author records.

The team repairs the relationship mapping, reruns the affected checks and records the accepted collection and remaining exceptions.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Contract

   Which fields and relationships must survive or intentionally change?

2. Traceability

   How does each source record map to the destination?

3. Coverage

   Which types, edge cases and consequential records will be compared?

4. Window

   How are late source edits reconciled?

5. Acceptance

   Who accepts which evidence and unresolved exceptions?

Watch for the wrong conclusion.

• Treating matching record counts as proof of integrity.
• Checking body text while ignoring relationships and publication state.
• Fixing one sample instead of a faulty transformation rule.
• Retiring the source system solely because the import completed.

Sources & scope

The framework, examples and suggested checks are original editorial synthesis. Hypothetical examples are not measured results. Source checking is not an independent audit or a guarantee of business outcomes. No named human reviewer is claimed.

• Drupal documentation: Migrate API overview →Primary publisher guidance · Supports: Supports migration as source, transformation and destination stages, with source-to-destination mapping. Drupal implementation details are not universal; the acceptance checklist is original editorial synthesis.