This article is currently available in English while its ES translation is prepared or reviewed.
Replacing spreadsheets is partly a software project and partly a decision about which records the business trusts. Importing every file into a new database can preserve the same duplicates, missing fields and conflicting versions in a more expensive place. Prepare the data before the final move.
Choose the source of truth
List the spreadsheets and exports that staff currently use. For each one, record its owner, purpose, update frequency and relationship to other files. Two files called the customer master may describe different groups or different moments in time.
Agree which source wins when values conflict. A finance contact may be authoritative for billing details while dispatch owns delivery instructions. Write those rules down so the migration team does not guess from whichever file was sent last.
Give records stable identities
Names alone make weak identifiers. A business may appear with a trading name in one file and a registered name in another. Employees may type a vehicle registration with different spacing or punctuation. Create a matching rule and review ambiguous cases rather than automatically merging everything that looks similar.
Preserve a link to the original source row or legacy identifier. That reference helps staff explain a migrated record and investigate mistakes after launch. If a record is deliberately excluded, keep an exclusion reason in the reconciliation report.
Map fields before importing
Create a field mapping that says where each source column goes, which fields are required and how values are converted. Pay particular attention to dates, phone numbers, currency, units and leading zeros in reference numbers.
For each field, decide what an empty value means. An unknown service date is different from a vehicle that has never been serviced. A zero balance is different from an account that has not yet been reconciled. Do not invent plausible defaults to make validation pass.
Run a representative trial
Use a test environment and include difficult records, not only a handful of clean rows. Test duplicates, archived customers, missing identifiers, unusual characters and records with long histories. Ask operational users to perform actual tasks using the imported data.
A useful trial report includes:
- Records read from each source.
- Records successfully imported.
- Records rejected, with an actionable reason.
- Duplicates merged or held for review.
- Totals and balances compared with agreed source reports.
Counts alone are insufficient. A migration can import the correct number of invoices with the wrong customer links. Check relationships and sample records alongside totals.
Plan the final changeover
Agree a time when editing in the old workflow stops, or define how changes during the transition will be captured. Keep a dated backup of the original data and document who can authorize the final import. Rehearse the steps so the final move is a repeatable process.
Define the conditions for delaying launch. Unexplained differences in a critical report should have an owner and an explicit decision. Keep the old records available according to the agreed access and retention plan so staff can investigate questions after the new system starts.
Support the first working week
Provide a clear route for users to report incorrect records. Track corrections, investigate their cause and avoid repeatedly fixing the same issue by hand. A short daily review during the first week can reveal mapping errors before they spread into downstream work.
Read the signs that spreadsheets are holding operations back and explore our system integration service.
Discuss your data migration
