The moment an organisation asks for a platform, they think they are asking for software. They are asking for a change in how they know things. That confusion — treating the migration as a technical task — is why so many of these projects underdeliver.

Step one: name the invisible workflows

Every spreadsheet has three workflows around it that nobody documented. Someone updates a colour on Sunday morning. Someone else copies a range and pastes into another sheet. A third person exports it, prints it, and takes it to a meeting. Those three workflows are the organisation. The spreadsheet is just the medium.

A migration that captures the spreadsheet and skips the three workflows will land a platform that gets used for two weeks and then abandoned.

Step two: earn the right to change one thing

The first release should do less than the spreadsheet, on purpose. It should do the single thing the spreadsheet does worst, and it should do it obviously better. Every subsequent release then earns permission to replace another workflow.

This is the opposite of the vendor pitch that promises to replace everything at once. That pitch loses, every time, to a well-established Excel file.

Step three: keep a bridge

For at least the first quarter, the platform should be able to export back into the shape of the original spreadsheet. Not because it is the right long-term output — it is not — but because the organisation still needs to be able to fall back on the workflow it has always run on while the new one earns their trust.