How do we move business data without losing records or interrupting work?
Plan a business-data migration with field mapping, trial transfers, reconciliation, cutover decisions and fallback arrangements.
A data migration needs more than a successful import.
The receiving application must interpret the information correctly, preserve the relationships the business needs and support the work people perform after the move.
Start by defining what must be preserved, what interruption is acceptable and what evidence is required before the migration can be accepted. Zero disruption should not be assumed before the systems and transfer method have been assessed.
Decide what is moving
Create an inventory of the information in scope.
Include active records, historical records, attachments, relationships and any identifiers used by other applications. Decide which information will move, remain available in an archive or be excluded under an approved decision.
Keep an unchanged source extract for comparison during testing, with access and retention appropriate to its contents.
Write down the mapping rules
Fields with similar names may carry different meanings.
For each destination field, record its source, expected format and any conversion. Define how blanks, invalid values and conflicting records will be handled.
Relationships need their own mapping. A project, customer or equipment record may be referenced by several other records. Retaining each row without preserving those connections may still leave the destination unsuitable for use.
Practise with representative data
Run a trial migration in a suitable test environment.
Include ordinary records and the awkward cases: missing values, unusual characters, duplicates, older formats and records with several attachments or related items.
Reconcile the results using several checks:
- Counts, including rejected and excluded records.
- Required values and identifiers.
- Relationships between records.
- Attachments and supporting information.
- Business workflows performed by representative users.
A matching row count is one check. It does not establish that the values, relationships or application behaviour are correct.
Plan what happens while people keep working
If the source continues changing during the move, decide how those changes will reach the destination.
The plan may require a controlled editing pause or a supported method of transferring later changes. The appropriate approach depends on the applications and the business’s tolerance for interruption.
Microsoft’s Dynamics 365 cutover guidance provides a relevant planning example: it calls for an ordered plan, assigned responsibilities, rehearsal in a test environment and verification before the transition is accepted. Microsoft’s cutover guidance.
Preserve relationships that matter to operations
Sangfroid’s documented Project X structure connects projects to checkpoints and service steps. Its equipment views also distinguish items, boxes and kits.
These are real application relationships that illustrate why migration validation must go beyond independent rows. The published case study does not describe a migration of those records or claim a migration outcome. See the documented Project X structure.
Define fallback before the switch
Name the person who can authorise the transition and the person who can stop it.
Agree the conditions that would trigger a fallback, the records needed to support recovery and how new information entered after the switch would be handled. Returning to an older database alone may leave those later changes outside the restored system.
Keep unresolved differences visible. Accept the migration only after the agreed data checks and business workflows have been reviewed.