How to Replace Business Spreadsheets With a Custom System

The spreadsheet-to-system migration has a well-known failure mode: the new system is objectively better, and six months later half the team is still using the sheet. Avoiding that is mostly about what you do before any software is built.

Not the tidy version. The real one, with the colour coding that means something, the column that's been repurposed twice, and the tab everyone forgot about.

Every one of those oddities is a business rule that was never written down. The colour coding is a status field. The repurposed column is an exception the process didn't anticipate. Miss them and the new system will be rejected for 'not doing what I need', without anyone being able to say precisely what.

Some of what the spreadsheet does is genuinely how the business works. Some of it is a workaround for the spreadsheet being a spreadsheet. Separating those is the most valuable hour of the project.

Be conservative. The instinct to redesign the whole process while you're at it is how a four-week build becomes a four-month one.

Parallel running. For a couple of weeks, both systems are updated. It's tedious and everyone resents it, and it catches the gaps that testing never does.

Then make the spreadsheet read-only rather than deleting it. It stays as an archive, nobody loses anything, and the temptation to slip back into it disappears.