Moving your data: What needs to be checked?
When replacing software, the first question is often whether every record has been moved. Matching row counts, however, does not prove balances are correct, attachments open or orders still belong to the right customers. Data migration needs business ownership as well as technical import and export work.
1. Agree what to move and how to access history
List the data in use: customers, open orders, stock, receivables and any attachments. For each group, identify an owner, the period needed and the trusted source. Historical information that is not needed for processing in the new system may be retained for reference under an agreed arrangement rather than automatically migrated.
The data you need to move also depends on which parts of the existing system will remain. If you have not yet chosen between improving it and replacing it, Upgrade or Rebuild? Choosing the right path for your system helps you weigh that decision before finalizing the migration scope.
Retention and deletion should follow the organization’s confirmed obligations and usage permissions. Resolve uncertainty with the responsible internal owner before setting scope. An export file does not itself prove that all data is included or may be shared with every project participant.
The result is an owner-approved scope, including what will not move and how it will remain accessible.
2. Map the old data to the new structure
The old and new systems may use different codes, statuses or calculations. In a hypothetical case, an old status of “in progress” must map to either “awaiting confirmation” or “assigned.” Business owners must agree the mapping, which records need manual review and what cannot be inferred from the existing data.
A field-mapping record should show source, destination, transformation and exception handling. In a hypothetical migration, customer IDs change, but orders and outstanding balances must still reference the correct customer. Merging matching names without confirming that they belong to the same legal entity can produce a successful import with incorrectly assigned balances.
3. Resolve missing, incorrect and ambiguous values
Track duplicate customers, missing product codes and inconsistent dates with an owner for each correction. Preserve the source and transformation rules so later differences can be explained. Do not quietly alter values you do not understand simply to make an import succeed.
Preserve the meaning of values passing through intermediate files. Leading zeros in phone numbers, postcodes or product IDs, date interpretation and monetary rounding can change without an import error. Test vulnerable values and define when a record must be returned for correction rather than silently populated with a default.
Not every record needs the same treatment. Separate rule-based conversions, cases requiring business confirmation and records that must wait. An exception list with owners is more useful than forcing every row through an import.
4. Rehearse and verify business meaning
Rehearse with representative records, including open orders, cancellations and incomplete information. Reconcile counts as well as amounts, quantities, relationships and accessible attachments. Where transformation rules apply, confirm that the result still has the intended business meaning.
Matching the company’s total receivables does not prove that each balance belongs to the right customer. Reconcile totals, customer or branch groups, then higher-risk records such as open or adjusted transactions. Agree whether complete checking or sampling is appropriate for the impact; a small sample cannot establish that every record is correct.
Classify discrepancies as migration errors, accepted differences or source-data issues. Business owners confirm meaning while the technical team records fixes and reruns. Automated comparisons can help, but they cannot decide whether a balance or status is appropriate for the business.
For each rehearsal, record the source snapshot and rule version. After changing a rule, identify what must be rerun and how duplicates will be prevented. Track discrepancy ownership, recheck results and approval of any remaining differences. This provides evidence for the migration decision beyond an imported-row count.
Before signing off the migration, have the people who use the system try continuing their work, such as processing an open order or checking a customer’s balance. Software acceptance: What should your business test? explains how to prepare scenarios, expected results and issue reports for that check.
5. Finalize updates and old-system access
If the source continues receiving orders after an export, where do those later updates go? Agree the cutoff, incremental data, update permissions and final reconciliation before switching. A single transfer or staged synchronization depends on the systems and acceptable interruption; neither suits every business.
After migration, retain agreed historical access while preventing accidental entry into a retired source. Write access, read access and system retirement are separate decisions. Remove the old source only after responsible owners confirm reconciliation, retention and required retrieval arrangements.
Once data updates and historical access are agreed, plan how staff will move to the new system: when they start, who supports them and when the switch should be paused if problems arise. What to prepare before your new system goes live covers how to coordinate that work before, during and after the cutover.
For a planning discussion with Fenix, prepare sample data with sensitive information removed, business rules and reports used for reconciliation. These clarify the work needed before setting the migration date.
