An Excel file that is slow or keeps crashing is usually carrying more than a spreadsheet should: whole-column formulas, links to other workbooks, or tens of thousands of rows. Tidy the formulas first. If it is still slow, the data belongs in a list or table, and that is also the moment the workbook has become the business.
A spreadsheet has become the business when it has one owner, formulas nobody else can read, a copy for every month, and a file somewhere called final v3. The risk is a broken link on the day it matters and no audit trail behind the number. Move it out in one order: the data first, then the logic, then the reports.
No one decides to run a business on a workbook. It starts as a tally, someone adds a column, someone else adds a tab, and four years later the monthly invoice run depends on it. The question worth asking is whether the business would stop if the file did.
Why a big Excel file gets slow or crashes
A worksheet holds at most 1,048,576 rows and 16,384 columns. A sheet anywhere near that is a database kept in the wrong place. Short of the limit, Microsoft's own guidance for a workbook that is using too much memory is to look at the formulas first: reference only the cells you actually use rather than whole columns, and limit formulas that calculate across other workbooks, which matters most when the file is opened over a network. (Microsoft Learn, Excel specifications and the memory clean-up guidance, read 3 October 2026.)
That tidy-up buys time and it is free, so do it. The test is whether you have to keep doing it. If every month brings another fix to keep the file opening, the data has outgrown the workbook. Move the data into a SharePoint list or a Dataverse table, keep Excel as the reporting view on top, and the crashing stops being a monthly event. A list view still needs indexed columns past 5,000 items, which is covered below. If the real trouble is several people in the file at once, that is the other half: several people in one Excel workbook, and what to use instead.
Five signs it already happened
- One owner. There is a person who "does the spreadsheet", and when they are on leave the thing they do waits for them.
- Formulas nobody can explain. A nested lookup somebody wrote in 2022 that gets copied down each month because it works. Ask what it does and the answer is a shrug.
- A copy for each month. March, April, May, each its own file, each a fork of the last. Corrections applied to one and not the others.
- A file called final. Then final v2, then final v3, then the one with someone's initials on the end. Version control by filename.
- A number from it quoted in a meeting. Someone says margin was 22 per cent last month and everyone writes it down. That number came out of the workbook, and no one in the room can trace it back to a source.
Any two of those and the workbook is running part of the business. All five and it is the system of record, whatever the accounting software thinks it is.
What it costs when it breaks
Spreadsheets rarely fail loudly, and that is the problem. A file that will not open is a bad morning. A file that opens and shows a wrong number is a bad quarter.
Broken links, on the day it matters. A workbook that pulls from another workbook is fine until someone renames a folder, works on a copy in their downloads, or leaves. Then the total is wrong rather than missing, and wrong is much harder to notice than missing.
No audit trail. When a figure gets questioned, there is no record of who changed what and when. Version history in OneDrive helps and it is better than nothing, but it tells you the file changed rather than that a rate in row 340 changed from 85 to 8.5.
Sorting, the classic. One column sorted without its neighbours and every row is now attached to the wrong job. No error, no warning, no way back except a version from before it happened, if anyone spots it in time.
Concurrency. Two people in the same file, one on a cached copy, one online. Excel resolves that better than it used to and it still resolves it silently, which is a different thing from resolving it correctly.
Where the data should land
For most Canterbury businesses under 20 staff, the answer is a SharePoint list, because it is already inside the Microsoft 365 licence being paid for. It gives sortable views, choice fields, people pickers and proper per-item history, and Power Automate can watch it without anyone writing code.
It has real ceilings and they are worth knowing before you commit. The list view threshold is 5,000 items per query without an indexed filter, and effectively no ceiling with one. You get 20 indexed columns per list and 12 lookup-type columns per view, with Person and Managed Metadata columns counting toward that 12. Power Apps caps a non-delegable query at 500 records by default, 2,000 at a push, and it does not throw an error when it does, it just shows you part of the list. All of those are worked through in SharePoint list limits, and the ones that actually bite.
The line where a list stops being enough is narrower than most people think: a row that only its owner may see, or genuinely relational tables linking several kinds of record. Hit either and Dataverse earns its licence fee, which is the whole argument in SharePoint or Dataverse, ask this one question first.
The order to move things out
Three steps, and the order is the part people get wrong.
1. The data. One list or table, one row per thing, a date column instead of a file per month. Nothing else changes yet. The workbook can keep running off it for a while, and it should, because that is how you find out what the data was missing.
2. The logic. Move the formulas one at a time, and write down in plain English what each was meant to do before you rebuild it. About a third of them turn out to be patches for a data problem you fixed in step one, and those get deleted rather than rebuilt.
3. The reports. Last, always. A report built on data that has not settled has to be rebuilt anyway. Whether the report belongs in a dashboard at all is a separate call, and Power BI against Excel for job profitability covers when it does.
Migrations stall when someone starts with the reports, because the reports are the visible part and the data is the work.
A worked example, the cost of the upkeep
The cost of a spreadsheet shows up as standing weekly time keeping it honest: copying last month's version, re-pointing the links, fixing the pivot, chasing the two rows that do not tie back to Xero.
Say that is four hours a week across whoever touches it, and the hour costs $45 in wages and on-costs, the default in the ROI calculator. Say the replacement is a $4,000 build, the floor of the single-automation band on the services page, and 70 per cent of the upkeep disappears because someone still handles exceptions.
- Annual hours: 4 × 46 working weeks = 184 hours
- What the upkeep costs: 184 × $45 = $8,280 a year
- Annual saving: $8,280 × 0.7 = $5,796 a year
- Payback: $4,000 ÷ ($5,796 ÷ 12) = 8.3 months
- Three-year net: ($5,796 × 3) − $4,000 = $13,388
Eight months, which is inside a year and outside the quarter. By the standard in the 90-day payback test, that is a build worth doing if the process is stable, rather than one to start on Monday. And the arithmetic above counts none of the risk, which is usually the actual reason people move.
When the spreadsheet is fine
Most spreadsheets should stay spreadsheets, and I say that as someone who gets paid to replace them.
A workbook one person uses for modelling, where the answer matters and the file does not, is exactly the right tool. So is anything you rebuild from scratch each time you use it: a quote comparison, a what-if on a job, a one-off reconciliation. Excel is very good at thinking, and no list or table replaces that.
It is also fine when the process is still moving. If how you do this changes every couple of months, a spreadsheet absorbs the change for free and a build charges you for it every time. Let it settle first, then move it.
And if the data is small and stable, leave it alone. A 200-row supplier list that changes twice a year has no problem in it worth paying to solve.
Work out which one yours is
Book a free 30-minute call, tell me what the workbook does and who else can open it, and I will put it in one of three piles: leave it, tidy it, or move it. Two of those three cost you nothing.
Questions about outgrowing a spreadsheet
How do I know when a spreadsheet has become a system of record?
Five signs. One person owns it and everyone waits for them. It contains formulas nobody else can explain. There is a copy for each month rather than one file with a date column. Somewhere there is a version called final, or final v2. And a number from it has been quoted in a meeting as fact. Any two of those and the workbook is running part of the business.
Why is my Excel file so slow and crashing?
Usually the file is carrying too much: formulas that reference whole columns, formulas that calculate across other workbooks, or very large amounts of data. Reference only the cells in use and cut the cross-workbook links first. A worksheet tops out at 1,048,576 rows, so a sheet near that belongs in a database. If you keep tuning the file to keep it opening, move the data to a SharePoint list or Dataverse and keep Excel as the reporting view.
What is the risk of running a business on a spreadsheet?
The failures are quiet ones. A link to another workbook breaks and the total is wrong rather than missing. A row gets sorted without its neighbours and nothing warns anyone. There is no usable audit trail, so when a figure is questioned there is no record of who changed what. And there is one person who understands it, which makes their annual leave a business risk.
Should I move a spreadsheet into SharePoint or Dataverse?
A SharePoint list handles most of them, and it is included in the Microsoft 365 licence you already pay for. It holds up until you need row-level permissions so a person sees only their own records, or real relational tables linking several kinds of record together. Either of those is where Dataverse starts paying for its licence fee. Row count is rarely the trigger.
What should I move out of the spreadsheet first?
The data, before anything else. Get one list or table with one row per thing and a date column, replacing the monthly copies. Only then move the logic, one formula at a time, writing down what each one was meant to do. Reports go last, because a report built on data that has not settled has to be rebuilt anyway. Doing it in the other order is how migrations stall.