Data Migration Risk Assessment: A Checklist for Engineering Teams

A data migration plan needs evidence about source quality, target compatibility, runtime, and recovery. Work through these checks before choosing a cutover date so findings can change the architecture or schedule.

Section 1: Data Quality Assessment

Profile the source data before writing transformation rules. Schema definitions alone may not reveal duplicate records, inconsistent values, or missing relationships.

• 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

Document and rehearse each cutover step, including the checks that determine whether to continue or roll back.

• 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.

---

Discuss a data migration assessment with LinkIT.