Let's start by defending Excel, because most articles in this genre are unfair to it. A spreadsheet is free, infinitely flexible, and understood by everyone. Every manufacturer starts there, and starting there is correct. The mistake is not using Excel; it is missing the day Excel stopped being enough - because that day never announces itself. There is no error message for "this workbook is now costing you money."
So here are the six signals we consider the real thresholds, followed by what actually changes with an MRP system, and how to switch without breaking your operation.
The six signals your spreadsheet has hit its limit
1. The count and the shelf disagree, and nobody is surprised
The first stage of spreadsheet decay is drift: the sheet says 80, the shelf says 63, and the team's reaction is a shrug. Drift happens because a spreadsheet records what someone remembered to type, not what happened. Once your team routinely walks to the shelf to verify the sheet, the sheet is no longer your inventory system - the shelf is, and the sheet is decoration.
2. You have sold the same stock twice
Spreadsheets store quantities, but promises live elsewhere - in email threads, in someone's head. When a wholesale order and a website spike claim the same units, Excel has no mechanism to stop it. An MRP system does: stock gets reserved the moment an order lands, and an allocation engine refuses to hand the same lot to two orders.
3. A "where did this batch go" question took more than an hour
A supplier calls about a defective batch. In Excel, the answer is a manual crawl: receipts, production notes, packing slips, memory. If your products carry lot numbers or expiry dates - food, cosmetics, supplements - this is not an inconvenience, it is a compliance gap. Lot-tracked MRP answers it with a query: this lot arrived on this date, went into these production batches, shipped in these orders.
4. Only one person can safely edit the workbook
Somewhere around the fifth tab and the third VLOOKUP, the workbook develops a priesthood: one person who knows which cells are formulas and which are hand-typed. When they are on holiday, receiving stops being logged. A system with real user accounts, roles, and an audit trail removes the single point of failure - and tells you who changed what.
5. You cannot state the true cost of last month's biggest order
Excel costing is almost always average costing, updated occasionally. But you did not consume average materials - you consumed specific lots bought at specific prices. When material prices move, averages hide losing orders for months. MRP systems that freeze per-order COGS from the actual lots consumed make margin a fact, not an estimate.
6. Expiry dates live in a column nobody sorts
A spreadsheet can store expiry dates; it cannot act on them. Nothing warns you, and nothing makes the picker take the older pallet first. FEFO picking - First Expired, First Out - needs to be enforced at the moment of allocation, automatically. That is a behavior, and spreadsheets do not have behaviors.
What actually changes with an MRP system
| Job to be done | Excel | MRP system |
|---|---|---|
| Stock levels | Typed after the fact, drifts | Updated by the movement itself |
| Order promises | In heads and inboxes | Reservations against specific stock |
| Batch traceability | Manual reconstruction | Query over lot history |
| Expiry handling | A column, maybe sorted | FEFO enforced at allocation |
| Costing | Periodic averages | Per-order, frozen at allocation |
| Who changed what | Unknowable | Logged with user and timestamp |
| Concurrent users | Risky | Designed for it |
Notice what is not in this table: dashboards, AI, integrations. The core upgrade is unglamorous - a live, shared, enforced version of the truth. Everything else is built on that.
The three things a spreadsheet cannot do
The table above is a list of things Excel does badly. This is the shorter list of things it cannot do at all, however careful you are, because they are properties of the format rather than of your discipline.
Two people cannot both be right. A file is one truth at a time. The moment receiving and dispatch both need to write, somebody is working from a version that was already stale when they opened it, and no amount of naming conventions fixes it.
A rule in a spreadsheet is a suggestion. You can sort by expiry date. You cannot stop someone shipping the wrong lot, because the sheet has no say in what leaves the building. A rule that can be ignored under time pressure will be, and it will be ignored on exactly the day it mattered.
An overwritten cell leaves nothing behind. Excel records the current number, not the sequence of events that produced it. That is fine until someone asks why the count changed, or which batches used a suspect delivery, and the honest answer is that the information was never written down.
Those three are also why the answer to "what problems does an MRP system solve that a spreadsheet cannot" is not really about features. It is that stock levels become a consequence of recorded movements rather than a number somebody maintains.
So when is it actually time?
Signals are useful but they invite arguing. The cleaner test is arithmetic: add up the hours per week your team spends keeping the spreadsheet honest. Reconciling the count, chasing which version is current, rebuilding a batch history for a customer question, redoing a promise that was made twice.
When that number stops shrinking as you get better at it, the spreadsheet is not the thing holding you back any more, it is the thing you are working for. Most teams cross that line well before they admit it, because each individual reconciliation is only twenty minutes.
The one timing rule worth keeping: move before it is an emergency. A migration run during a recall, an audit or a peak season is a different and much worse project than the same migration run in a quiet month.
How to switch without chaos
The switch fails when teams try to migrate everything on day one. A sequence that works:
- Start with products and locations. Import your SKU list and define where stock lives. Do not touch history.
- Load opening stock as lots. Count once, enter what is physically there, with expiry dates where relevant. This count is the last big count you should ever need.
- Run receiving and orders in the system from day one. New movements go in the system, full stop. The spreadsheet stays read-only as an archive.
- Add BOMs and production next. Once daily stock movements are stable, define recipes and start running batches through the system.
- Turn on QC and costing last. These layers pay off most, but only once the movement data underneath them is trustworthy.
Expect two awkward weeks while habits reroute. The test of success is simple: a month in, does anyone still open the old workbook to answer a question? If not, the migration is done.
What Excel is honestly still good for
Fairness matters here, because the goal is a correct decision, not a sales pitch. Excel remains the right tool for one-off analysis: modeling a hypothetical price change, sketching a new product's BOM before it exists in any system, or building a quick chart for a board update. The distinction that matters is between analysis (temporary, exploratory, thrown away after the question is answered) and operations (the live record of what your business actually has and owes). Excel is well-suited to the first and structurally weak at the second, because nothing enforces that the file in front of you is the current version.
The migration mistakes that cause the most damage
Beyond the five-step sequence above, three specific mistakes account for most failed switches we have seen described by manufacturers, and they are all avoidable:
- Migrating on a random day mid-month. Pick a boundary - the start of a week, the day after a big shipment clears - so the opening count has a clean line: everything before this date is history, everything after is in the new system. A migration that starts "sometime this week" produces a fuzzy boundary that nobody can reconcile later.
- Copying every historical column into the new system. Old notes fields, deprecated statuses, and one-off adjustments from three years ago do not need to exist in the new system's live data model. Bring forward current stock and open orders; leave history in an archived export you can reference if truly needed.
- Skipping training because "it's just like Excel." It is not. Reservations, lot allocation, and permission-based access behave differently from a shared file, and a team that treats the new system like a spreadsheet with extra steps will fight it instead of using it. Even a short walkthrough of the actual daily workflow - receive, produce, ship - heads off most of this.
How to know the switch actually worked
Beyond "nobody opens the old workbook," three concrete signals confirm the migration succeeded rather than just stalled in a comfortable middle state: the stock count in the system matches a physical spot-check within a small margin; a lot or batch can be traced from receiving to shipment without anyone reconstructing it from memory; and the monthly close no longer needs a side reconciliation between "what the system says" and "what we think really happened." If any of those three is still false after a month, the migration is not finished - it is paused, and worth finishing before adding more features on top.
For a sense of what these concepts look like in a shipping product, see how IEMSuite handles MRP for small manufacturers - or start from our plain-English MRP guide if you want the fundamentals first.