Stork Delivery
Moving data without losing its meaning
A migration needs rules for identity, relationships, exceptions, and reconciliation before the final import runs.
The problem: copied rows can lose the relationships that make them useful
A migration can copy every row and still produce a system the business cannot trust. Customer records may be duplicated. Historical dates may change meaning. An order may arrive without the relationship that connects it to its invoice.
Moving the data is one part of the job. Preserving its meaning is the larger requirement.
A practical approach
Inspect representative records
Start with ordinary examples and deliberately awkward ones. Include old records, incomplete records, duplicates, corrections, and the largest or most complicated accounts.
Do not assume that a field's name tells you how it has been used. A “closed date” may have been repurposed during a process change years earlier.
Ask the people who rely on the data to explain those cases. Record the decisions before transformation code turns an assumption into a permanent rule.
Keep a mapping you can inspect
Document how identifiers, statuses, dates, and relationships map into the destination. Preserve a way to trace a migrated record back to its source.
Decide how unsupported values will be handled. Silently replacing them with a default can make the import look successful while erasing important distinctions.
Separate records that need review rather than dropping them without explanation. Give that review an owner and a clear resolution process.
Reconcile more than row counts
Compare counts, key totals, and relationships that the business expects to hold. A matching number of orders does not prove that each order belongs to the right customer.
Use samples to inspect complete workflows in the destination. Can staff find a historical order, see its related documents, and understand its current state?
Agree on tolerances and known exceptions before the final run. Otherwise, the team may argue about whether a difference matters while the business is waiting to resume work.
Plan the cutover window
Decide what happens to changes made during migration. The answer may involve a write pause, an incremental transfer, or a carefully managed transition period.
Define rollback conditions and the point beyond which new activity makes rollback more complicated. A copy of the old database is not a complete return plan once the new system has accepted live changes.
A successful data migration leaves people able to explain where a record came from, what changed, and how the result was checked. That is the evidence worth keeping after the import finishes.
The result: migrated records that remain explainable
Run a rehearsal with representative records and have business users trace an order, its customer, its invoice, and its attachments in the destination. Keep mapping decisions and reconciliation results alongside unresolved exceptions. Approve the final move only against agreed acceptance criteria and a plan for changes during cutover. Begin with the oldest and most awkward records, where assumptions are easiest to expose.