The short answer

  • Agree field ownership and rejected-record handling before import.
  • Use repeatable transformations with stable source references.
  • Approve cutover using reconciliation and business cases.

Define the record and its owner

Inventory the business objects being moved, the source of truth for each field and the relationships that must survive. Identify records that are archived, duplicated or outside the migration scope. Agree how missing values and conflicting identities will be handled before transformation code makes those decisions implicitly.

Make transformation repeatable

Version the mapping rules and retain source identifiers. Run the same sanitized sample through the transformation more than once and verify that it does not create duplicate business records. Separate rejected records into an inspectable queue with a reason. Do not silently drop an invalid row merely to make the import complete.

Reconcile meaning, not only counts

Compare totals, relationships and representative business cases against the source. Equal row counts can conceal wrong ownership, swapped fields or lost transaction history. Ask the people who use the records to verify a normal case and a difficult exception. Keep the evidence attached to the migration run so a cutover decision is reviewable. Include archived records and corrections in the sample, since a migration that preserves only current happy-path transactions can erase the history needed for later support.

Plan the write boundary during cutover

Decide when the source stops accepting changes, whether a final incremental pass is needed and how the destination will be checked before users proceed. Define who can approve cutover and what triggers rollback. If old and new systems coexist, establish one write owner per field and an explicit reconciliation path.

Apply this to your project.

Bring the current workflow and the part you are unsure about. We can help define the next useful engineering decision.

Explore the relevant service