How to move from Excel to a system without stopping the business

Almost no company decides to run on Excel. It starts with a spreadsheet to solve one specific thing, the spreadsheet grows, someone adds macros, and one day the whole business depends on a file. It works, but it gets harder and harder to share, audit and maintain.

This is what we do when we migrate one of those systems, and what we have learned doing it.

1. Understand what the spreadsheet calculates, not which screens it has

The first impulse is to copy the sheets as they are into a web application. That is a mistake: many sheets exist because of Excel's limits, not the business's. What needs to be rescued is the rules: how a balance is calculated, what counts as a cost of the season, when a document belongs to one period and when to another.

Many of those rules are not written down anywhere. They live in a long formula, in a macro, or in the head of whoever built the file. Bringing them to light is half the work.

2. Collect real examples before writing code

We ask for real files, with real data, and results the company has already accepted as correct: a closed balance sheet, a report that was submitted. Those results are the test the new system is measured against.

3. Migrate module by module

Switching everything overnight is the most expensive way to get it wrong. We prefer to pick a module that can be used on its own, move it, validate it and only then go on to the next one. In the meantime the company keeps working on the spreadsheet for everything that has not been migrated yet.

4. Validate against the old system

Each module is compared with the spreadsheet's numbers. When they do not match there are two possibilities: the new system has a bug, or the spreadsheet was doing something nobody knew about. The second shows up more often than you would expect, and it forces a decision about how things should work from now on.

5. Import the data, do not re-enter it

History is imported by a process that reads the files, cleans up the data and loads it. Nobody should have to retype years of information. The same process lets you repeat the load as many times as needed while testing.

6. Decide when the spreadsheet stops being used

If the spreadsheet and the system coexist with no cut-off date, people go back to what they know. For each module, agree on the day from which the system is the source of truth.

What takes the longest

It is not the programming. It is getting the examples, having someone from the business with time to validate the numbers, and deciding what to do with the rules nobody had written down. If you are about to start a migration, setting that time aside on your side is what shortens the timeline the most.

This is the path we are following at AgroApex, a farm accounting system with twenty years on Excel and Access. If you have something similar, this page explains how we work on it.