Data Migration for Custom Software: Move Records Without Losing Business Meaning

Data migration is the process of moving business information into a new system while preserving the meaning the business relies on. Copying rows is only one part of that work. Customer relationships, status definitions, historical prices, attachments and permissions can all be lost or changed even when a technical import reports success.

If you are replacing spreadsheets or a legacy application, treat migration as its own workstream. The new interface can be ready while the business remains unable to operate because the right records are missing or untrustworthy. A clear migration plan reduces that uncertainty before launch.

Inventory the sources and their owners

List the databases, spreadsheets, exports and document stores involved. Identify who understands each source and which one is authoritative when records disagree. Include unofficial files if staff depend on them for current decisions.

For each source, record the available export method, approximate size, update frequency and restrictions on access. An API, a database backup and a manually produced spreadsheet require different extraction plans. Confirm access early rather than assuming it will be available near launch.

Ask what history must remain searchable and what needs to be fully operational in the new system. Old closed jobs may be suitable for a read-only archive, while active jobs need complete structured data and attachments.

Map meaning before mapping columns

A field called “status” may mean something different in each system. Define how old values translate to the new workflow and which values require review. Do the same for customer types, product units, ownership and dates.

Stable identifiers are especially important. Names can change and email addresses can be shared. Preserve or map source identifiers so related records remain connected. A customer import that succeeds independently of its invoices can still produce a broken customer history if those relationships are not reconstructed correctly.

Document transformations in a mapping sheet with examples. For instance, explain how separate first and last names are combined, how empty dates are treated and which old branch code maps to a new location. Avoid silently filling unknown values with plausible defaults.

Separate cleanup from historical correction

Removing an accidental duplicate is different from rewriting historical information. Establish what can be corrected automatically, what needs human review and what should be preserved as originally recorded. A record with incomplete information may still be important evidence of past work.

Create an exception list instead of forcing every record through the same rule. Staff can then review ambiguous customers, invalid dates and unmatched references. Keep the original extracted data unchanged so decisions remain traceable and the import can be repeated.

Our CRM development guide describes why customer and opportunity relationships need explicit structure. Migration is often the moment when those relationships first become visible enough to correct.

Run repeatable trial migrations

Automate the transformation and import steps where practical so a trial can be repeated against a fresh environment. A sequence of manual edits performed once is difficult to reproduce at cutover. Record the version of the mapping and the source snapshot used for each trial.

Begin with a representative sample containing ordinary records and difficult exceptions. Then run a full trial to reveal issues involving volume, relationships and timing. A small sample cannot show every constraint that appears when the complete dataset is imported.

Give business users specific validation tasks. Ask them to find a known customer, trace an open order, review a historical price and open a linked document. “Please check the data” is too broad to produce dependable feedback.

Reconcile counts, totals and relationships

Compare the number of source records, imported records, rejected records and deliberately excluded records. Explain every difference. Counts alone are insufficient, so also compare relevant totals and relationships with the business team.

For a stock system, check movements and balances using agreed rules. For a customer system, check linked contacts and active opportunities. For financial information, have the appropriate finance owner confirm the reconciliation approach and results.

Inspect permissions after import. A document that was previously restricted should not become visible to every new user simply because it arrived in a shared folder. Access mapping is part of migration quality.

Decide how changes are handled before cutover

The old system may continue changing while trial migrations run. Decide whether the final move uses a brief freeze, a final incremental extraction or another controlled approach. Explain who may enter data during the transition and where.

Avoid indefinite dual entry. When staff update both systems without a clear authority, reconciliation becomes harder every day. Set a specific point at which the new system owns the live workflow, with an agreed procedure for exceptions.

If you migrate by branch or workflow, describe how records shared between migrated and unmigrated areas are handled. A phased rollout can reduce operational disruption, but only if the temporary boundaries are understood.

Prepare rollback and recovery decisions

A rollback plan should state what triggers a return to the previous system, who decides and how work performed after cutover will be preserved. Restoring an old backup without considering new transactions can lose legitimate business activity.

Keep the previous system or a usable archive available according to the agreed plan. Confirm that backups can actually be restored and that someone has the access required to do it. A file named “backup” is not evidence that recovery has been tested.

Our software handover checklist covers the operational information the receiving team should have, including recovery procedures and account ownership.

Acceptance criteria for migration

• Every source record is accounted for as imported, excluded or awaiting review.
• Important relationships and attachments remain accessible to the correct users.
• Business owners approve the agreed reconciliation checks.
• The final import can be repeated from documented inputs and rules.
• Staff know the cutover time, entry restrictions and support route.
• The team can explain how it will preserve new work if rollback becomes necessary.

Include migration effort in the project estimate alongside development and training. Bring sample exports and the people who understand them to a software modernisation discussion. A successful migration is one the business can verify, not merely one the application can load.