Answer.

Data migration testing is necessary when moving to new versions of applications where the database structure, storage objects, or data transformation logic changes.

Background of the Question

The evolution of applications requires regular updates, migration from obsolete systems, and architectural changes. Typically, data migration is considered a technical task; however, without proper control, testers frequently encounter incidents ranging from lost to incorrectly transformed data.

Problem

Key challenges include:

loss or distortion of data during migration;
incompatibility of new data/structure with the business logic of the new release;
absence of clear criteria for successful migration.

Solution

A proper manual testing process includes:

creating test scenarios covering various data types (simple, complex, boundary, non-standard);
comparing resulting data in the new and old versions based on key parameters: quantity, correctness, integrity;
validating the logic of complex entity transformations;
testing on relevant (sampled from real) data with mandatory backups.

Key features include:

Cross-checking different data variants: from simple to aggregated and historical;
Checking integrity and relationships: it is important not only to ensure accurate migration but also to maintain relationships between tables, fields, entities;
Documenting the migration process: all stages must be documented for reproducibility and possible rollback.

Tricky Questions.

Is it acceptable to use completely synthetic data for migration testing?

No. Synthetic data often do not reflect real relationships and historical cases; it is important to complement them with real anonymized samples.

Is it sufficient to compare the total number of records before and after migration to confirm correctness?

No. The number of records may match despite transformation errors or loss of data completeness. It is important to analyze the content and correctness of fields.

Should migration be tested on an empty database?

Absolutely. Such testing reveals edge scenarios for errors (e.g., empty reference tables, absence of key records).

Common Mistakes and Anti-patterns

Checking only the number of rows without data analysis
Neglecting relationships between entities and tables
Testing exclusively with new data and ignoring historical data

Real-life Example

Negative Case

During migration, only "fresh" user data was checked. Logic errors surfaced later when rarely used historical data (e.g., old orders) were needed.

Pros:

Quick validation at the testing stage

Cons:

Loss of historical data, intervention by the support team
Long detection of the error chain

Positive Case

Samples were created with real and archival (anonymized) data, and migration was tested on both, as well as on an empty and highly fragmented database.