Migration6 min
From Excel to a business system: keeping your history intact
Migration is the phase that puts projects behind schedule, almost always because it is tackled last. Here is why it should come first, and how.
Every company moving to a business system has years of spreadsheets behind it that worked. They are not a problem to be deleted: they are the most faithful documentation of how the work actually gets done, which is why they should be read before anything is designed.
Clean first, import second
A customer list grown over ten years holds duplicates, fields used for something other than their label, and notes that hide business rules. Importing it as-is means moving the mess into a new system and then blaming the new system.
The sequence that works
- Extract and profile: how many records, how many duplicates, how many empty fields, which values fall outside their domain.
- Cleaning rules agreed with the people who use the data, not decided by the supplier.
- A trial import on a separate environment, with a control count on every entity.
- Acceptance: a user looks up ten records they know by heart and confirms they are right.
- The final import close to go-live, in an agreed window of downtime.
What not to migrate
Not all history belongs in the operational system. Often the right call is to bring the last two or three financial years live and archive the rest read-only: the system stays fast and the history stays available. That is a business decision, not a technical one, and it should be made together.
The acceptance criterion
A migration is done when the people who work with the data say it is right, not when the script finishes without errors. Which is why acceptance is run by the departments, with real cases, and written up.