A spreadsheet becomes load-bearing slowly. Nobody decides to run a business on a worksheet. It starts as a list, then a column is added for a date, then a column for a step, then a column for who signed it off. A year later the file is the record for workers, steps and dates, and the business stops when the file is wrong.
That is the situation we found at a workforce operations company. Contingent worker onboarding was tracked in an Excel worksheet. The worksheet held the roster, the checklist for each worker, and the offboarding record. It worked, in the sense that the work got done. It also failed in the ways a worksheet always fails when it becomes a system: two people edited different copies, a row was sorted and the dates no longer lined up with the names, and nobody could say, with certainty, which workers had finished which steps.
The first decision was not which framework to use. It was what the worksheet actually was. A worksheet is three things at once: a list of people, a checklist per person, and a history of what happened. A web application that replaces it has to be those three things too, with the parts separated so a change to one does not corrupt the others.
So the replacement was built as a web application with a worker roster, a 19-step checklist per worker, and an offboarding archive. The roster is the list of people. The checklist is the record of steps, each one marked complete with a date and a name attached to it. The archive is what happened to workers who left, kept apart from the people still working, so the current list stays current.
The migration itself was the part that mattered most, and it was deliberately unglamorous. Every row in the worksheet was read, checked against the roster, and moved into the new application with its history intact. A step that was marked complete in the worksheet stayed complete, with the date it was marked. A step that was blank stayed blank. Nothing was tidied up in the move, because tidying up in the move is how history gets rewritten by accident.
We ran the two side by side until the new application was the one staff reached for first. That is the test that counts. A replacement that staff have to be told to use is not a replacement yet. A replacement that staff choose, because it answers the question faster — who is this worker, which steps are done, what is left — is the one that stays.
What changed, in practice, was not the work. Workers still went through the same 19 steps. What changed was where the truth lived. In the worksheet, the truth lived in a file that anyone could overwrite. In the web application, the truth lives in a record with a history: who did what, when, and in what order. A checklist step cannot be completed by sorting a column. A worker cannot be lost because a row was deleted.
There is a lesson in this that applies well beyond one worksheet. The systems that need replacing are rarely the ones that are broken. They are the ones that work just well enough, for just long enough, that the business grows around them. Replacing them is not a matter of finding a newer tool. It is a matter of naming what the old tool actually does, building that — and only that — and moving the history across without rewriting it.
If you have a spreadsheet that the business would stop for, that is the place to start. Not with a new platform, and not with a migration plan that takes a quarter. With a list of what the file actually holds, and a decision about where that truth should live instead.