Moving off spreadsheets without stopping work

Map the process people actually follow

Every organisation has a documented process and a real one. The real one includes the colour coding in column M, the WhatsApp message that unblocks approvals, and the file someone maintains privately because the shared version is wrong. Automate the documented process and you will have built something nobody uses.

Sit with the people doing the work for a day. Write down each exception they handle and how they handle it. That list is the actual specification.

Take one slice, end to end

Pick one product or one customer segment and run it completely in the new system — intake to closure — while everything else stays where it is. A complete slice reveals the integration and data problems that a partial rollout hides until late.

Half a process in a new system is not half a migration. It is two systems and a reconciliation problem.

Decide what history comes with you

Migrating every historical record is expensive and usually unnecessary. Open cases have to move. Closed ones often only need to be readable, which can mean an export kept alongside the new system rather than an import into it.

• —Open cases: migrate fully, with their documents
• —Recently closed: migrate if the model has been trained on them
• —Old and closed: archive in a readable, retrievable form
• —Agree a retention period before migrating anything at all

The two mistakes

The first is rebuilding the spreadsheet. If the new system has a screen that looks like the old sheet, the team will keep working the old way and none of the value arrives. The second is deferring go-live until every exception is configured. Exceptions are discovered by running, not by planning, and the last five per cent can take longer than the first ninety-five.