Nearly every MIP starts life in a spreadsheet, and for good reason: at closing, Excel is fast, flexible, free, and everyone can read it. The honest question is not whether spreadsheets are bad, they aren't, but at what point staying in one stops being pragmatic and starts being a risk that quietly compounds.
This article is not an attack on spreadsheets. Excel is one of the most successful tools ever built precisely because it can hold anything, a register, a vesting schedule, a waterfall model, with zero setup cost and total flexibility. When a plan is small and quiet, a well-kept spreadsheet is a perfectly adequate home for it, and pretending otherwise would be selling you something.
But this series has spent several articles describing what a MIP does over a holding period: participants join and leave, pools get resized, equity rounds land, vesting accrues, leaver events demand precise historical answers. Each of those events tests the record, and spreadsheets fail those tests in specific, predictable ways that have nothing to do with the competence of the person maintaining them.
So this article does three things: it describes honestly where a spreadsheet is genuinely fine, it names the specific failure modes that emerge as a plan grows, and it gives you the signals that you have crossed the line, because the goal is not to leave Excel on principle, but to leave it before the exit window rather than during it.
A spreadsheet is an adequate, sometimes even the sensible, home for a MIP when most of the following hold true:
Notice that these conditions describe a plan at rest. And that is the honest summary: spreadsheets are good at storing a position and bad at absorbing change. Every condition above is a way of saying "not much happens to this plan." The moment things start happening, the picture shifts, not gradually, but with each event.
Spreadsheet failures in MIP administration are remarkably consistent across programmes. Five patterns account for nearly all of them.
The file lives with one person, usually in finance, and so does the knowledge of how it works: the hidden tabs, the manual adjustments, the cell that must never be touched. When that person leaves (and over a five-year hold, they often do), the successor inherits a file they can open but not understand. This is the ownership gap from two articles ago, expressed in software.
A copy goes to the fund for reporting. Another goes to counsel for a leaver question. Someone saves "register_v7_FINAL_updated". Within a year there are four files that each look authoritative, and the plan has acquired the second expensive mistake from this series: more than one source of truth, except now the competing versions are timestamped ambiguously and scattered across inboxes.
A spreadsheet shows you the current state; it cannot tell you who changed what, when, or why. For most business files that is tolerable. For a register whose historical states move money, what exactly had vested on the leaver date, what the pool looked like before the second round, it is a structural defect. In due diligence, "the cell says 40%" is not an answer to "show me how it became 40%."
Vesting schedules, pro-rata calculations, and leaver arithmetic live in formulas that one inserted row can silently corrupt. Spreadsheet errors do not announce themselves; they produce plausible wrong numbers that get reported, relied on, and eventually discovered, usually by someone else's advisers, at the worst possible moment.
A spreadsheet is a grid. A MIP in an active buy-and-build is not: multiple entities, share classes, jurisdictions, vesting cohorts, and instrument types, all interrelating. Modelling that in a grid forces either heroic formula engineering or manual duplication, and both fail the same way, quietly.
None of these five failures is caused by carelessness, and that is the point. They are structural properties of the tool meeting the demands of the job. A diligent, capable person maintaining a MIP in Excel is not protected from any of them, diligence delays the failures; it does not remove them.
The line between "fine in Excel" and "quietly compounding risk" is crossed at recognisable moments. Any one of these signals is worth a conversation; two or more mean the move is overdue.
| Signal | What it tells you |
|---|---|
| The first contested leaver | You now need defensible historical states, vested balances as of a specific date, which a current-state file cannot prove |
| A second entity or share class enters the structure | The plan has left two dimensions; the grid has not |
| An add-on brings a new management team into the pool | Event volume is about to multiply, joiners, allocations, possibly a new jurisdiction |
| The keeper of the file resigns or changes role | The single-author risk is materialising right now, and migration doubles as a forced clean-up |
| The fund starts asking for regular reporting | Copies will start circulating, version drift begins the day the second copy is sent |
| Exit is 18–24 months away | The record is about to be examined professionally; migrate and reconcile now, while there is still time to fix what surfaces |
The worst time to migrate is the one when most programmes actually do it: inside the exit process, under deadline, with the buyer's advisers waiting. A migration is also a reconciliation, every discrepancy the spreadsheet has quietly accumulated surfaces at once. Done two years before exit, that is a healthy clean-up. Done during diligence, it is a fire drill that the other side gets to watch.
Moving off the spreadsheet does not have to mean an enterprise software project. What the plan actually needs is a small set of properties, and any solution that delivers them, a purpose-built equity administration platform, or a professionally maintained register with disciplined process around it, is an improvement:
Purpose-built platforms exist for exactly this, and for most programmes of real complexity they are the right destination, we work with them daily and remain deliberately platform-agnostic about which. But it is worth being honest that the tool is the smaller half of the answer. A platform enforces the discipline a spreadsheet leaves optional; it cannot supply the ownership, the promptness, or the process this series keeps returning to. The best tooling in the world, unowned, produces a beautifully structured version of the same old gap.
When a MIP record turns out to be a mess, the spreadsheet gets the blame, it is visible, it is fragile, and replacing it feels like decisive action. But in our experience the file is usually the symptom. The same programmes that let a spreadsheet rot would have let a platform rot too, just more legibly. The root causes are the ones this Hold block has been circling: no owner, no rhythm, events recorded late, discretion undocumented.
That said, tools shape behaviour, and this is the genuine case for moving: a spreadsheet makes the undisciplined path the easy one, paste a copy, patch a cell, reconcile later, while a proper system makes the disciplined path the default. If the ownership and the process are in place, the platform multiplies them. If they are not, fix that first, or you will simply be migrating your problems into better software.
The right sequence is process first, platform second, and both well before the exit window. A programme that gets ownership and promptness right in month one and migrates in year two will sail through diligence. A programme that buys software in a panic during the sale process has bought a very expensive way of discovering how many discrepancies it had.
Ask what the register runs on, and who can reproduce last year's numbers. If the answer is a spreadsheet and a name, follow up with the signals table above. The cost of asking is one email; the cost of not asking is discovered in diligence.
Time the migration to the exit, not to the crisis. Eighteen to twenty-four months before a likely process is the sweet spot: late enough that the structure is settled, early enough to fix whatever the reconciliation surfaces.
Budget for the clean-up, not just the tool. The value of a migration is the reconciliation that comes with it. Fund the work of making the record right, not merely the licence to store it somewhere nicer.
If you stay in Excel for now, stay deliberately. One master file, one owner, changes logged in a simple change tab, copies clearly stamped as reports. That is spreadsheet discipline, it does not remove the structural limits, but it buys you time honestly.
Watch for the signals, and act on the second one. One signal is a prompt to plan; two is a prompt to move. Waiting for the file to visibly fail means waiting too long, because spreadsheets do not fail visibly.
Treat the migration as a reconciliation project. The goal is not the new system, it is the moment every balance, date, and document reference has been verified on its way in. That verified baseline is the asset you will be grateful for at exit.
Every programme we have ever seen started in a spreadsheet, and there is no shame in that, it is the natural first home for a plan, chosen for entirely sensible reasons by entirely sensible people. The difference between the programmes that thrive and the ones that struggle is not where they started. It is whether anyone noticed the moment the plan outgrew the file, and acted on it while acting was still cheap.
That moment is almost always earlier than it feels. The file still opens, the numbers still look right, and nothing has visibly broken, which is exactly what the quiet years before an expensive discovery look like. Recognising the signals, and making the move in calm times rather than during the sale process, is the discipline. And it is the work we do at MIP Desk.
We work with PE fund managers and their portfolio companies across the Benelux, Europe, and the UK, assessing registers, running migrations and reconciliations, and keeping programmes exit-ready throughout the hold.