When should we move from Excel to dedicated FP&A software?

You should move off Excel when coordination or consolidation has outgrown it — more than roughly twenty people submitting numbers, or multiple legal entities with intercompany activity — not when revenue or headcount crosses a threshold. The most common real trigger is neither of those: it is that actuals get pasted in by hand every month, and that problem is usually solved by connecting Excel to your ERP rather than leaving it.

That distinction matters because the two paths cost very different amounts. A connected spreadsheet layer keeps the model your team already trusts and removes the assembly work. A planning platform replaces the model, which means rebuilding logic, retraining contributors and a multi-quarter implementation. Both are legitimate; they answer different problems, and the expensive mistake is buying the second to solve the first. Our comparison of spreadsheet-native versus web-based FP&A sets out the trade-off.

Bottom line: diagnose before you shop. If the pain is manual data assembly, connect Excel and keep the model. If the pain is coordinating twenty-plus contributors or consolidating legal entities, you need platform capability Excel genuinely does not have. If the pain is that leadership does not trust the numbers, that is usually a definitions problem and no tool fixes it.

The signals that actually mean something

Revenue is a poor trigger. Companies at the same revenue have wildly different finance complexity depending on entity count, contributor count and business model. These eight signals are better, and three of them are not tooling problems at all.

The two entries worth dwelling on are the ones where the honest answer is "not yet." Key-person concentration — one analyst who can rebuild the model and nobody else who can — feels like an argument for a platform, and it is really an argument for documentation and a second pair of hands. Buying software does not transfer knowledge; it relocates it, often into a vendor. And a slow reforecast is usually a model-structure problem: a model that hard-codes outputs instead of deriving them from drivers will be slow to re-run in any environment. Restructure it around drivers first, and you may find the tooling question dissolves.

What Excel is genuinely bad at

Being fair about this matters, because the case for moving is real in specific places and vague everywhere else.

Excel has no concept of who has submitted. Once twenty or thirty non-finance managers are contributing, the missing capability is not calculation, it is knowing whose numbers are in and whose are not, and chasing that by email is where whole weeks disappear. That is the clearest single reason to add a platform layer, and it is the trigger described in collaborative budgeting with department owners.

It also has no real version control. Copies proliferate, and the failure mode is not gradual — it is a board pack circulated and then corrected, which costs credibility disproportionately. And it cannot do statutory consolidation with intercompany eliminations and currency translation. Worth noting that most planning tools cannot either, so if that is your requirement you are shopping in a narrower tier than you may realise; multi-entity consolidation software is the actual category.

What Excel is not bad at is modelling. A well-built spreadsheet model is more flexible than most platform modelling environments, and it is the reason so many teams that migrate keep a shadow workbook. If your team's modelling is genuinely good, that is an asset to preserve rather than a legacy to eliminate.

The middle option most teams miss

There is a third answer between staying and leaving, and it is the one that fits the most common diagnosis.

A connected layer leaves the model in Excel or Google Sheets and replaces only the data-assembly step: actuals flow from the ERP into the sheet on a schedule, with drill-through back to source transactions. The model, the formulas and the institutional knowledge stay where they are. Implementation is days to weeks rather than quarters because there is nothing to rebuild, and the recoverable time — the monthly paste-and-reconcile cycle — is exactly what gets removed.

Aleph sits here, as do Cube and Datarails in slightly different shapes; Aleph holds 4.9 out of 5 from 108 reviews on G2 against a 4.55 category average. Where this option runs out is workflow and consolidation: if you need approval routing across thirty contributors or statutory eliminations, a connected sheet will not get you there and a platform genuinely will. Being clear about which side of that line you are on is the whole decision.

What to do before you buy anything

1. Write down the five outputs finance is accountable for. Board pack, reforecast, headcount plan, budget-versus-actual, cash forecast, or whatever yours are.
2. For each, note whether the constraint is data assembly, coordination, calculation or consolidation. Four different problems with four different answers.
3. Count contributors and legal entities. These two numbers decide the tier more reliably than anything else.
4. Time one reforecast end to end. If it is slow because of structure rather than tooling, fix the structure first — it is free.
5. Check whether definitions are agreed. If two people compute ARR differently, no platform will reconcile them for you.

That exercise takes an afternoon and routinely changes the answer. The most common outcome is a narrower purchase than originally imagined, because the problem turns out to be assembly rather than capability. The second most common is discovering the requirement is consolidation, which sends you to a different tier entirely. Either way it is cheaper to find out now than in month three of an implementation — the pattern behind a good share of failed FP&A implementations.

If you do move, what to keep

Two things are worth protecting through any migration.

Keep the model logic somewhere you control. Whether that is a spreadsheet or an exportable definition, the ability to inspect and change your own planning logic without a vendor is worth real money over a three-year term, and it is the thing teams miss most after moving to a closed platform. Ask about it explicitly — portability is never volunteered.

And keep a parallel cycle. Run the new system alongside the old one for one full close and one full reforecast before you retire the workbook. It is the cheapest insurance available, it is the step most often skipped under timeline pressure, and it is what turns a migration into a non-event. Sequencing guidance is in the implementation steps guide and the implementation timeline; the cost side is in what implementation actually costs and the pricing guide.

Excel or Google Sheets?

A question that comes up in the same conversation and has a clearer answer than most people expect.

For modelling depth, Excel still wins: more capable formulas at the edges, better handling of very large models, and the environment most experienced finance people are fastest in. For collaboration, Google Sheets wins outright — genuine simultaneous editing, no version proliferation, and permissioning that works at the cell and range level without a file-locking dance.

Which matters more depends on the same diagnosis as the platform question. If your pain is that several people need to work in the same model at once, Sheets solves a real problem today at no cost. If your pain is model complexity, moving to Sheets will make it worse. Most teams end up with both, and the sensible split is Sheets for anything collaborative and Excel for the deep model — which is workable provided actuals flow into both from one source rather than being maintained twice. Tools in the connected tier generally support both, which is worth confirming rather than assuming.

What the migration actually involves

If you do decide to move to a platform, the work is more predictable than vendors imply and lands in five phases.

1. Definition agreement. Every metric, agreed and written down. Skipping this is why implementations stall in month two, because the argument surfaces during build rather than before it.
2. Data mapping. Chart of accounts to the new hierarchy, with a named owner for maintaining it afterwards.
3. Model rebuild. The largest phase, and the one whose size depends entirely on whether your logic is reused or re-expressed.
4. Parallel running. One full close and one full reforecast in both systems, compared line by line.
5. Cutover and retirement. Only after parallel running has agreed twice.

Phase four is the one that gets cut when timelines slip, and it is the one that should never be. Running parallel for a single cycle is what converts a migration from an event into a non-event, and the cost of skipping it is discovering a mapping error in a board pack. Phase three is where the money goes, which is why asking whether your model is reused or rebuilt is the highest-value question in any demo.

One thing not to do: migrate during budget season. It is the most common scheduling mistake and it is self-inflicted — the cycle that most needs a stable process is the worst possible time to change the process. Aim for the quiet quarter after the budget is approved, which also gives you a full reforecast to parallel-run against. Timing guidance is in the implementation timeline and the sequencing in the implementation steps guide. For the metric definitions worth agreeing in phase one, the Benchmarkit SaaS benchmarks we co-published is the reference set we would use.