Website migration validation

How to validate a website migration

Check that the right records arrived, that their relationships still work and that people can use the new site. Keep the failures visible until someone fixes them or accepts the exception.

A sample report with issues still open

This is an illustrative report, not a customer result. It shows why a matching article count is not enough to approve a launch.

Sample report — illustrative data
Check	Illustrative finding	Decision
Article reconciliation	120 agreed articles, 120 resolved destination records	Count check passes
Files	29 of 30 agreed images available	Recover or explicitly exclude the missing image
Authorship	Two articles have unresolved author references	Fix before acceptance
Redirects	17 direct redirects and one chain	Replace the chain and retest

The launch decision remains open until blocking issues are fixed or accepted by the person responsible. A rerun should produce a new report showing what changed.

Download the sample validation report (CSV). Use the mapping rules and URL worksheet to define the expected results for your own project.

Acceptance criteria

What website migration validation must prove

Completeness

Every in-scope record is accounted for as loaded, skipped, rejected, failed, or covered by an approved exception.

Accuracy

Required values, statuses, dates, authors, taxonomies, files, URLs, and metadata match the approved mapping rules.

Relationship integrity

Parent-child links, references, ownership, term assignments, attachments, and other dependencies resolve correctly.

Destination readiness

Representative pages render correctly and the required permissions, workflows, links, redirects, and publishing paths work.

Count matrix

Reconcile every migration stage

Source baseline

Record the agreed source totals by entity, status, language, site, and other scope boundaries before extraction.

Extracted records

Confirm what the migration process read and identify records excluded by access, filters, unsupported types, or source defects.

Transformed records

Track records changed by mapping rules, normalization, fallback values, splitting, merging, or dependency handling.

Loaded records

Verify destination-created or updated records by stable identifiers rather than assuming a successful request means a complete record.

Skipped or rejected

List intentionally excluded, duplicate, invalid, unsupported, or destination-rejected records with a reason and owner.

Failed or unresolved

Record technical failures, missing dependencies, broken assets, and unresolved mappings that require correction or approval.

Entity-level QA

What to validate by entity

Editorial content

Compare titles, body content, excerpts, custom fields, statuses, dates, slugs, language variants, and revision requirements.

Authors and taxonomies

Verify user attribution, roles, categories, tags, vocabularies, term hierarchy, and assignments.

Relationships and hierarchy

Test parent-child structures, references, related content, menu links, attachments, and cross-entity identifiers.

Media and files

Check file availability, MIME type, filename, dimensions, captions, alt text, ownership, rewritten URLs, and failed downloads.

SEO and URLs

Review metadata, canonicals, indexation rules, URL parity or redirect mapping, internal links, sitemap output, and important landing pages.

Permissions and private data

Confirm visibility, access rules, private records, sensitive fields, and excluded data remain within the approved scope.

Templates and workflows

Open representative destination pages and test rendering, previews, search, navigation, editing, publishing, and operational handoffs.

Evidence beyond totals

Use a representative sampling strategy

Simple records

Include common, predictable records to confirm the standard path works at expected volume.

Complex records

Select custom fields, nested structures, references, embeds, unusual markup, and edge-case transformations.

Old and recent content

Compare records from different publishing eras because source conventions and plugin ownership often change over time.

Draft and private records

Validate non-public statuses, scheduled dates, permissions, and content that cannot be checked through a public crawl.

Media-heavy records

Inspect galleries, documents, remote assets, large files, captions, alt text, and rewritten media references.

Deterministic random sample

Use a repeatable random sample alongside risk-based cases so later runs can reproduce the same checks.

Approval sequence

Validation gates before and after cutover

Discovery baseline

Approve scope boundaries, source totals, mappings, destination prerequisites, sample cases, and acceptance criteria.

Dry run gate

Reconcile the staging run, investigate systematic defects, retest corrections, and document accepted limitations.

Pre-cutover approval

Confirm backups, freeze or delta rules, redirect plan, owners, launch checks, rollback triggers, and open exceptions.

Final or delta reconciliation

Account for changes since the approved dry run and reconcile the final production load by entity and outcome.

Post-launch checks

Crawl priority URLs, test journeys, inspect redirects, forms, search, permissions, rendering, errors, and analytics signals.

Stabilization closure

Resolve agreed migration defects, review deferred items, record final evidence, and obtain documented acceptance.

Reviewable output

What a validation report should contain

Scope and run identity

Name the source and destination versions, environment, run IDs, timestamps, filters, and approved scope boundaries.

Reconciliation matrix

Show source, extracted, transformed, loaded, skipped, rejected, and failed totals for every in-scope entity.

Field and relationship tests

Record sample identifiers, expected results, actual results, mapping checks, and dependency outcomes.

Asset, URL, and SEO tests

Summarize file checks, link and redirect results, metadata checks, crawl findings, and priority-page review.

Exception register

Assign each unresolved issue a severity, impact, owner, decision, remediation path, and target date.

Approvals and sign-off

Record who reviewed the evidence, which exceptions were accepted, and whether the next delivery gate is approved.

Decision language

Classify exceptions consistently

Blocker

Prevents safe launch or creates unacceptable data loss, access, compliance, security, or critical workflow impact.

Major

Materially affects an important entity, relationship, asset set, URL group, workflow, or user journey and needs an agreed decision.

Minor

Has limited impact, a practical workaround, or a contained correction that does not prevent the next approved gate.

Accepted or deferred exception

Documents an approved limitation, source defect, excluded feature, custom follow-up, owner, and completion expectation.

Validation boundaries

What validation cannot guarantee

Search rankings

Validation can check technical migration signals, but it cannot guarantee unchanged rankings, traffic, indexing speed, or algorithmic outcomes.

Platform equivalence

Different platforms model content and behavior differently; approved transformations do not make every feature technically identical.

Excluded functionality

A content migration report does not prove forms, commerce, memberships, search, integrations, or custom applications unless they are explicitly in scope.

Source defects

Broken links, missing files, inconsistent data, and inaccessible records may originate in the source and should be documented rather than silently treated as migrated correctly.

Related planning

Plan validation with the migration scope

Migration checklist

Coordinate discovery, staging, cutover, launch-day checks, and post-launch ownership.

Use the checklist →

Migration methodology

Place reconciliation and acceptance evidence inside discovery, dry run, cutover, and stabilization gates.

Review methodology →

CMS migration cost

Understand how entity volume, relationships, media, SEO, cutover constraints, and validation depth affect scope.

Review cost factors →

CMS migration workflows

Review supported content and data migration deliverables, boundaries, platform paths, and destination requirements.

Review migration scope →

Security and data handling

Define least-privilege access, staging, sensitive-data handling, retention, rollback, and incident ownership.

Review security controls →

Clear answers

Website migration validation questions

What is website migration validation?

Website migration validation is the evidence-based process of reconciling records and checking fields, relationships, assets, URLs, rendering, workflows, and documented exceptions against agreed acceptance criteria.

Why are record counts alone insufficient?

Matching totals can hide incorrect values, broken relationships, missing files, wrong statuses, duplicate records, failed redirects, and unusable destination pages. Counts must be combined with entity-level and representative checks.

How much content should be sampled?

Sampling should cover each in-scope entity plus simple, complex, old, recent, draft, private, media-heavy, and relationship-heavy cases. The exact size depends on volume, risk, variation, and acceptance criteria.

Who signs off migration validation?

The proposal should identify reviewers and decision owners. Technical, editorial, SEO, security, or business owners may approve different evidence before one accountable owner accepts the delivery gate.

What is a migration exception register?

It is a controlled list of unresolved or accepted issues with severity, impact, affected records, owner, decision, remediation path, and target date.

When should redirects and SEO signals be validated?

Inventory and mapping begin before migration, staging checks happen during dry runs, and production redirects, canonicals, indexation rules, sitemaps, internal links, and priority URLs are checked after cutover.

Can validation eliminate every risk of data loss?

No responsible validation process can make an unsupported absolute guarantee. It should account for every in-scope record, expose discrepancies, document source limitations, and require decisions on unresolved exceptions.

Is validation included in Migranetix packages?

Yes. Every package includes validation evidence. The depth, sample size, number of dry runs, reconciliation detail, and support period depend on the approved package and scope.

Next step

Define migration acceptance before cutover

Get an estimate based on the type, volume, and complexity of the data you want to migrate. Select the source and target systems, enter the migration details, and receive a calculated estimate. Online payment activation is being prepared. Until automated payment processing is available, plan activation and billing may be handled through a separate onboarding process.

Optional expert assistance

Calculate my migration estimate Review methodology