Every growing business runs on spreadsheets for longer than the owner would later say it should have. They were never a strategic choice. They started as the obvious way to track a few things and kept growing because each new need was easier to add as a column than to build properly. By the time the owner admits the business has outgrown them, there are usually somewhere between four and twenty live workbooks holding important information, none of which talk to each other, most of which contain decisions that exist nowhere else.
The move to a proper system is almost always overdue by the time it is made. Reports are assembled by hand from several files. The same figure has been typed in two places and nobody is sure which is current. Three people have three versions of the same tracker. The owner has been putting the project off because it looks large at a time when there is no slack to take it on.
What owners underestimate is that the migration is not the job they expect. Importing data into a new system is the easy part. The hard part is reconstructing the way the business actually works, which the spreadsheets have been quietly holding in formulas, tab names and colour coding. Moving the data is easy. Moving the operating model that grew up around the data is the work.
What the spreadsheets are really holding
A business that has run on spreadsheets for two or three years is holding far more than data in them. Four things have to be lifted out and placed deliberately into whatever replaces them.
The structure. A spreadsheet’s structure grew rather than being designed: columns added when new data was needed, tabs added when a new category appeared. A proper system needs an explicit structure, which means deciding what the business actually deals with (clients, jobs, leads, invoices, hires), what each one records, and how they relate. The spreadsheet had a structure. It was implicit and almost certainly inconsistent.
The rules. Spreadsheets are full of embedded rules. A margin formula assumes a pricing model. A status column with seven values assumes a workflow. A manually updated column assumes someone updates it at the right moment. These have to be lifted out, examined, often corrected, because many were never tested, and then built into the new system on purpose. As I cover in what a CRM cannot do for you, the system needs the process to exist before it can record it, and until now the spreadsheet was the process.
The decisions. Years of decisions are encoded as data. Why is this client tagged as strategic. Why is this lead at proposal stage when nothing was sent. Why does this budget differ from the contract. The migration has to reconstruct the reason, accept the data as it is, or clean it before it moves. There is no way to defer this. The new system inherits whatever the migration decides.
The dependencies. Almost every important workbook is depended on by something else: a report built from it, someone’s daily routine, a weekly meeting that reviews it. Each dependency has to be moved, replaced or formally retired. A spreadsheet retired without its dependencies being handled produces a sudden gap, and the team rebuilds it within weeks because they needed it for something the migration missed.
Together these are the real work. The data transfer is about a quarter of the project. The other three quarters are reconstructing what the spreadsheets concealed.
Why owners postpone it
Two reasons push the migration later than it should happen.
The first is that the spreadsheets are, in some sense, working. The team gets work done. Numbers get tracked. Reports get produced, however slowly. The cost of the spreadsheet model is invisible; the cost of the migration is a number on a quote. This is the same false economy that delays every piece of operational infrastructure: the visible cost of doing the work outweighs the invisible cost of not doing it, until the invisible cost arrives as a wrong invoice or a missed renewal.
The second is that the owner, usually correctly, expects the migration to mean confronting things they have been tolerating. The data is messier than it should be. The processes were never clean. There are rules in formulas the owner no longer agrees with. Doing it properly means paying that operational debt, and it only grows with time. A spreadsheet model that is tolerable at six people is painful at twelve and untenable at twenty, and the project that was six weeks at the smaller size becomes six months at the larger one.
What the migration involves
A well-run migration has five steps in order, and skipping any of them produces a failure of a predictable kind. This is also, not by coincidence, the shape of how I work.
Audit. Before any platform is chosen, the existing workbooks are mapped: what they hold, who depends on them, what rules are embedded, what the implicit structure is. This is the single most important step and the one most often skipped. It is what my £450 Review is: a week with the actual files, producing a map of what the spreadsheet runs, what to keep and what to rebuild, and a licensing check against the Microsoft 365 you already pay for. It is credited in full against a build that starts within 60 days.
Design. With the audit done, the operating model is designed deliberately: the records, their fields, how they relate, the rules that govern them, the workflows that act on them. This is where most of the value is created. It is the first written version of how the business actually operates.
Choosing the tool. Only now does the platform question make sense, and the honest answer is not always an application. Where fewer than about five people use the system, nobody edits at the same time, and the rules are mostly arithmetic, a structured Excel system does the job from £900 in two to three weeks, with no per-user licences. Where several people work in it at once, permissions matter, or the system has to chase people and talk to other tools, an application on Power Apps and Dataverse is the right build, from £3,000 and most often between £5,000 and £12,000. A business that picks the platform first and then bends its operating model to fit is making the choices in the wrong order.
Build and migrate. The system is built to the design, the data is moved across, and the team is trained. This is where most of the data cleaning happens, because dirty data does not become clean by changing file. The migration is the right moment to do it, since the data is being handled anyway. For a well-structured workbook that is a day or two of the project; for a legacy system with duplicates and free text it can be a week.
Transition. The team starts using the new system in earnest, the old spreadsheets are formally retired rather than abandoned, and everything that pointed at them is pointed at the new system. Most failed migrations fail here: the system was built, the team never fully moved, and the business ends up running both, which is worse than either alone.
In short. Audit first, design second, choose the tool third. The audit is the Review. The tool is an Excel system where the use is simple and an application where it is not. The data move is the smallest part.
What to do if your business is at this stage
If your spreadsheets have grown past what they were meant to do, the migration is unlikely to stay optional for long. The useful moves this quarter are the audit and the design, in that order, whenever the build itself happens.
The audit on its own usually produces immediate improvements, because looking carefully at the stack surfaces problems that were hiding in plain sight: the duplicate client list, the formula nobody has checked since 2023, the tracker only one person can update. The design produces the operating model in writing, which the business should have had years ago, and it becomes the specification for the build when the time is right.
The businesses that handle this well treat it as an operational design project that happens to involve software, not a software project. The system is the tool. The operating model is the work.
If your spreadsheet has become the system, tell me what it does and I will tell you whether it is worth replacing, and whether the answer is a workbook or an application. Start a conversation, or read how a build runs.