Data Migration Risk Assessment: A Checklist for Engineering Teams

Data migration is where legacy modernization projects face their most consequential risks. Application code can be redeployed if something goes wrong. Data loss or corruption after a cutover may not be recoverable. Yet data migration risk assessment is frequently rushed — treated as a final step rather than a foundational input to the migration plan.

This checklist is designed to be worked through before any data migration begins, as an input to your migration architecture and timeline decisions.

Section 1: Data Quality Assessment

Poor data quality in the source system is the most common cause of failed migrations. These issues exist in most legacy databases and need to be discovered before, not during, the migration.

• Run row count and checksum queries across all tables to establish a baseline
• Profile each column: check for nulls in non-nullable columns, values outside expected ranges, and data type mismatches
• Identify duplicate records — rows that should be unique based on business rules but are not
• Find orphaned foreign key references: rows in child tables with no matching parent record
• Check for implicit encoding in specific column values (status fields where specific strings have business meaning not captured in the schema)
• Audit date and timestamp columns for format inconsistencies, timezone issues, and impossible values (future dates in historical fields, dates before the system existed)
• Document every data quality issue found, categorized by: blocks migration, requires transformation logic, can be cleaned before migration, acceptable to carry forward

Section 2: Schema Compatibility Assessment

If you are migrating to a different database engine or a significantly restructured schema, schema compatibility issues will cause silent failures if not caught in advance.

• Map every source column to its target equivalent and verify data type compatibility
• Identify columns where type conversion is lossy (a FLOAT to DECIMAL conversion, a VARCHAR of longer length to shorter)
• Check character set and collation compatibility between source and target
• Verify that constraints in the target (NOT NULL, UNIQUE, foreign key) can be satisfied by the source data
• Identify columns that exist in the source but have no mapping in the target — are they being dropped intentionally?
• Identify columns that exist in the target but have no source equivalent — what is the default or derivation logic?
• If the target schema normalizes or denormalizes relative to the source, document the transformation rules explicitly

Section 3: Volume and Performance Assessment

Migration timelines calculated on small datasets are not reliable predictors of production migration behavior.

• Count total rows across all tables in scope
• Measure total data volume in gigabytes
• Identify the five largest tables and assess their specific migration approach
• Run the migration script on a production-scale clone and measure actual runtime
• Measure replication lag under production write load if using CDC
• Confirm that the target system can handle the ingestion rate required by the migration timeline
• Assess network bandwidth between source and target environments
• Confirm the migration can complete within the planned cutover window at measured throughput

## Section 4: Cutover Planning

The cutover is the highest-risk moment in the migration. Every step should be documented and tested before the production cutover date.

• Define the cutover window: start time, maximum duration, end criteria
• Document the step-by-step cutover runbook with owner for each step
• Identify the point of no return — after which rolling back becomes significantly more expensive
• Define the rollback trigger: what conditions cause an automatic decision to roll back
• Confirm the rollback procedure is documented and can be executed within the cutover window
• Conduct a dry run of the cutover in a staging environment at production scale
• Identify all systems that consume data from the source and confirm their cutover sequence
• Confirm monitoring and alerting are in place to detect anomalies during the cutover window

Section 5: Rollback and Recovery Assessment

A migration without a tested rollback plan is an unacceptable risk.

• Is the source system being kept live for a period after cutover? For how long?
• If something is found wrong after cutover, what data may need to be reconciled?
• Is there a CDC or replication mechanism that would allow writes made to the target to be reflected back to the source (reverse replication) during the rollback window?
• Is the rollback procedure documented at the step level, with estimated time for each step?
• Has the rollback procedure been tested in a staging environment?
• What is the maximum tolerable data loss if rollback is triggered after writes have been made to the target?

Section 6: Validation and Verification

Migration success cannot be declared based on process completion alone. The data in the target needs to be verified.

• Row count comparison between source and target for all tables in scope
• Checksum comparison for a statistically significant sample of records
• Application-level smoke tests against the target confirming business logic produces correct output
• Performance testing against the target confirming latency is within acceptable bounds
• Monitoring in place for at least 24–48 hours post-cutover to catch delayed anomalies
• A defined escalation path if a validation failure is detected post-cutover

Using This Checklist

Work through each section before your migration architecture is finalized. Issues found in Sections 1 and 2 may change your migration strategy. Issues found in Sections 3 through 6 will change your timeline and resource requirements.

Treat any item marked as unknown as a risk that needs to be resolved before the cutover date is set.

---

If you want an experienced team to run this assessment against your specific system or execute the migration with proper risk controls in place, contact Clixo.