Data Migration Scenarios, Testing, and Acceptance Guidelines

Background of Data Migration

When a company merges business lines, replaces old systems, or expands and needs to split databases, data migration becomes necessary. Typical scenarios include consolidating data from two systems by linking tables via specific fields, or deprecating an old system and moving all its data to a new one.

Formal Environment User Data Analysis

Before performing the actual migration, product, development, and testing teams must analyze existing online user data, categorize it, and design migration strategies for each category. For example, users may register with a phone number or without; each case requires a specific migration approach.

If the target database already contains the user, use the target’s basic information and establish a source‑target relationship.

If the target lacks the user, create the user in the target database using the source information.

Data Migration Test Analysis

The migration goal is to understand how the two systems’ data will be linked and how source data (database B) will be merged into the target (database A), possibly overwriting conflicting fields selectively.

When identical fields exist in both databases, conflict handling options include:

Row overwrite: data from B overwrites A.

Selective discard: prioritize one side and discard the other’s data.

Differences in Rules for the Same Field Between Source and Target

Beyond data compatibility, database compatibility must be considered, such as field length limits, case sensitivity (e.g., email case handling), support for special characters (e.g., nickname), and format validation (e.g., phone number, email).

Migration Plan

During the review stage, confirm the migration plan with product and development, covering:

Whether a downtime is required for the final migration.

Risk assessment of migration failure and corresponding mitigation measures.

Testing phase considerations: allowing targeted data migration tests, handling dirty data if no downtime, and evaluating recovery possibilities.

Preparation: create realistic “to‑be‑migrated” data that simulates production users.

Migration Acceptance

After a successful migration, acceptance testing must verify CRUD (Create, Read, Update, Delete) functionality from a business perspective:

Add: Adding data to the new database should reflect correctly in the user profile.

Read: Querying user information should return accurate data without errors.

Update: Modifying user data should persist and be displayed correctly.

Delete: Deleting a user should prevent further access.

Post‑Release Monitoring

Since migration can affect user data, a response strategy for potential feedback should be prepared, with clear responsibilities and monitoring of feature usage after release.

User Feedback

Promptly respond to user reports, determine whether issues stem from the migration, and guide users to continue normal usage, thereby improving satisfaction.

Monitoring Data

Key metrics to monitor after release include:

Interface call volume: watch for abnormal spikes.

Interface error rate: detect any increase in errors.

Interface alarm rate: observe any rise in alerts.

Small Case Study

The author shares personal reflections on a subset of data migration tests, emphasizing the importance of continuous summarization and learning.