Side by Side, Not Big Bang: Migrating Off the Spreadsheet Without Stopping Operations
Every operations manager we talk to has the same fear about replacing a spreadsheet: the morning after cutover, something is wrong, and the old file is already out of date. Classes still have to run, drivers still have to be dispatched, salaries still have to go out. You cannot pause the business to find out whether the new system works.
The fix is not more testing before cutover. It is removing cutover as a single moment. We run the new system alongside the old one for a defined period, and the team keeps using both until the comparison stops producing surprises.
Why the big-bang switch fails
A spreadsheet carries two things: the data, and a set of unwritten rules about what the data means. Which column is authoritative when two disagree. Which rows are really cancelled but were never deleted. Which instructor is "available" only because nobody updated the sheet. A data migration moves the first thing. It does not move the second.
When you switch in one step, those unwritten rules surface as errors in the new system, all at once, on a live day. The team reads that as "the new system is wrong," even when the system is simply enforcing a rule the spreadsheet silently ignored.
What running side by side actually means
For a period you agree on up front, the team records the same events in both places. A new batch is opened in the spreadsheet and in the system. A certificate is issued in both. At the end of each week, we sit down and compare: which records differ, and why.
Almost every difference falls into one of three buckets. The spreadsheet was wrong and nobody knew. The system is enforcing a rule the team wants relaxed, which is a configuration change. Or the team entered it differently in each place, which is a training gap. Each bucket has a clear owner and a clear fix, and none of them is an emergency.
The double-entry cost is real, and worth it
Teams push back on double entry, and they are right that it costs time. That is why the period is short and bounded, and why we start with one process, not everything. Pick the workflow where a mistake hurts most, such as certificate issuance or dispatch validation, and run only that in parallel first. Once the weekly comparison comes back clean twice in a row, the old sheet for that workflow is frozen, and the next workflow starts.
How you know it is time to switch off
Not when the vendor says so, and not on a date set at the start of the project. The signal is behavioural: the team stops opening the spreadsheet to double check. When the coordinator answers a question from the system without reaching for the old file, the migration is done. Everything after that is cleanup.
This is how the implementation phase in our approach is structured. Legacy data is migrated, the team is trained, and systems run side by side until the team is confident, not until a calendar says so.
