The spreadsheet is documentation

A spreadsheet that runs a core process is the most accurate specification of that process in existence. Its columns, conditional formatting and manual overrides record decisions nobody wrote down. Treating it as a mess to be replaced discards that record.

Read it before designing anything. The exceptions handled by hand are usually the parts of the process that matter most and are least represented in any off-the-shelf product.

Why replacements fail

Failed migrations tend to share one cause: the new system covers the standard path and not the exceptions, so the team runs both in parallel.

Parallel running is not a transition state. It is the permanent outcome, and it costs more than the original process.

A workable sequence

Order matters more than speed here, because each step depends on the one before it.

  1. Map the process with the people who run it, including undocumented checks and manual overrides.
  2. Agree the data model, roles and permissions before any interface work.
  3. Replace the single highest-cost step and put it into real daily use.
  4. Encode the exception paths next, not last.
  5. Retire the spreadsheet explicitly, with a stated date and an owner.

Transition sequence

Process mapping       ->  undocumented checks surfaced
Data model + roles    ->  permissions decided before UI
Highest-cost step     ->  in real daily use
Exception paths       ->  encoded, not deferred
Spreadsheet retired   ->  stated date, named owner

Build only what is genuinely yours

Custom software is justified when the process is a differentiator, or when no product fits without workarounds heavy enough to reintroduce the original problem. Otherwise a configured off-the-shelf tool is the better answer, and saying so early is part of the job.

Where a build is right, conventional and well-documented technology choices matter. The measure of a successful platform is that a team other than the one that built it can run and extend it.