Check the relationships as well as the rows.

A fictional order migration

Customer C-12 has order O-47 with two line items. Moving four rows is not enough if the order points to the wrong customer or its line items are detached. Preserve source identifiers or a clear source-to-destination mapping.

Write the field rules.

For each field, record its destination, expected format and permitted values. Distinguish missing, blank and zero when they mean different things. Decide how dates, timezones and decimal values should be interpreted.

Keep uncertain records visible.

List rejected rows and possible duplicates with reasons. A source record that cannot be mapped should appear in an exception report rather than disappearing from the result.

Choose meaningful checks.

Compare counts by record type, important totals and relationships. Inspect ordinary examples and known edge cases. Ask staff to find a record, view its history and complete an agreed task in the destination.

Plan changes during the move.

Decide whether the source becomes read-only, receives a final incremental transfer or follows another controlled approach. Restoring an old snapshot after users edit the new system can lose later work, so recovery limits need to be explicit.

Prepare a safe project brief.

• Source and destination names, record types and approximate volume.
• Key identifiers, relationships and attachments.
• Known quality problems and the person approving cleanup.
• Required checks and the owner accepting the result.
• Deadline, change window and recovery expectations.

Keep these notes locally. This page does not upload data. Describe the move first and agree how examples can be reviewed securely.