ERP / OPERATIONS
Moving from spreadsheets to an ERP: a data migration checklist
A spreadsheet can hide decisions that an ERP needs to make explicit: which customer record is authoritative, what “available stock” means, and who can change a confirmed order. Before importing files, agree on those rules. Otherwise, a successful upload can still produce an unreliable system.
Start with one business workflow
Choose a complete workflow, such as quote → order → stock allocation → delivery. List the people and records involved at each step. This gives the migration a useful boundary: data should support a real task, not merely fill every field in the new system.
Decide separately what must remain operational and what can be kept in a searchable archive. Bringing every historic row into the first release adds work and can preserve old inconsistencies. Agree on retention needs with the people responsible for those records.
Choose an owner and a source for each dataset
Create a register of customer, product, supplier, stock and open-order data. For each dataset, name one business owner who can resolve conflicting values. The latest file is not automatically the most accurate file.
For teams working across the United States and Argentina, document currency and date conventions explicitly. Keep a currency code with each amount. A value such as 1,250 or a date such as 04/10 is ambiguous without a format rule. Preserve business identifiers as text when leading zeros matter.
- Record the source system, export date, owner and expected row count.
- Identify stable customer and product IDs; do not match records by display name alone.
- Define units, time zones, required fields and rules for inactive records.
Write the mapping before the import
A useful mapping has five columns: source field, target field, transformation, validation rule and decision owner. Resolve missing or conflicting values explicitly; do not silently turn an unknown quantity into zero.
Hypothetical example: a stock sheet contains 120 units on hand and 15 reserved. If the new ERP stores both values, map them separately and verify that available stock becomes 105 under your agreed rule. Importing 120 directly as available stock would overstate what the business can sell.
Rehearse with representative records
Use a test environment and a small set that includes normal and awkward cases: duplicate customers, cancelled orders, accented names, empty optional fields and multi-currency transactions. Use synthetic or appropriately protected data, and restrict access to exports.
Then run a full rehearsal. Compare record counts, totals by currency, stock by location and open-order balances. Spot-check relationships: an order should still point to the right customer and its correct line items. Counting rows alone will not reveal those mistakes.
Define the switch and the way back
Name who can authorize the cutover. Decide when edits stop in the old system, how late changes are captured, and what evidence must be signed off before staff begin using the ERP. Keep a recoverable backup and test that it can be restored.
Rollback needs more than “restore the old file.” If users have entered new orders after the switch, decide how those changes will be reconciled before returning to the old system. Set a review window and assign an owner to investigate discrepancies rather than letting two systems drift apart.
TAKE IT WITH YOU
Your project checklist
- Name the workflow and the datasets required for it.
- Assign a business owner and authoritative source to each dataset.
- Approve field mappings, currencies, dates and duplicate rules.
- Rehearse edge cases and reconcile counts, totals and relationships.
- Record cutover approval, late-change handling and rollback steps.
- Assign post-launch checks and archive access responsibilities.
Use this checklist as a starting point. Adapt it to your systems and responsibilities; it is not a completed implementation plan.