In short: An Excel planning migration fails on sequencing far more often than on the target system, because replicating the workbook tab by tab puts the least valuable work first. Sequence by value instead, starting with the calculation the spreadsheet genuinely cannot do at the volume, version count or audit depth the business needs. Agree a reconciliation contract before the first parallel number appears, because the project's credibility rests on how the first difference gets handled. The person who built the workbook holds the undocumented business rules and is both the largest risk in the project and its most useful asset.
The workbook is called Master Plan v14 FINAL. It has thirty-one tabs, four of which nobody can explain, and it takes ninety seconds to recalculate. One person built it over six years and understands all of it. The business runs on it. Every consultant who has seen it has recommended replacing it, and it is still there, because each attempt started by describing everything the spreadsheet does wrong to the person who built it.
Migrations off spreadsheet planning fail for reasons that have very little to do with the target system. They fail because the sequence puts the hardest and least valuable part first, and because the people whose working method is being replaced were never given a reason to want it. Both are fixable.
Take the spreadsheet seriously first
A spreadsheet is a fast, flexible, universally understood modelling environment with zero deployment latency. That is a genuine set of advantages and pretending otherwise costs you the room.
Four things it does better than most planning systems. Schema change is instantaneous: a planner who needs a new column has it in four seconds, where the same request in a configured system is a ticket. The arithmetic is visible: click a cell and read the formula, which is a level of transparency that most planning engines cannot match. There is no deployment step, so an idea and its test are the same action. And it handles the genuinely one-off analysis, which is a large share of what a planner actually does in a week, better than any structured tool.
Any migration that removes all four and offers nothing in return will be resented, correctly.
Be precise about what it cannot do
The limits are real and they are specific enough to name.
Concurrency. Two people cannot work the same model at once without a merge problem, so the workbook has an owner and a queue.
Versioning that means anything. A file name is not a version. Reproducing the number that was published in March requires the March file, the March inputs and the March formulas, and one of those three is usually missing.
Lineage. When a number is wrong, tracing it back through a chain of workbooks that reference each other takes hours, and the answer is often that a source file moved.
Scale of calculation over a hierarchy. Aggregating and disaggregating across a product and location hierarchy with thousands of combinations is where spreadsheets stop being practical, and the workarounds people build for it are where the errors concentrate.
Auditability of change. Who changed the number, when and why is not recorded, and in a regulated or externally audited context that is a compliance problem rather than an inconvenience.
On error rates there is real research to cite rather than an assertion. Panko's review of spreadsheet error research, first published in the Journal of End User Computing in 1998 and updated in the years after, brings together field audits and laboratory studies finding errors in a large majority of operational spreadsheets examined. The rate per cell is low; the number of cells is high; the two multiply.
That multiplication is worth doing on your own workbook. If a formula cell has a one in two hundred chance of containing an error, which is at the optimistic end of what the audit literature reports, a workbook with 3,000 distinct formulas has an expected 15 errors in it. Most will be harmless. The question is whether you know which ones are not, and in an unaudited workbook nobody does.
Sequence the migration by value rather than by tab
The instinct is to replicate the workbook. That produces a long project whose first deliverable is something the business already has.
A better sequence moves in four stages, each of which stands on its own.
Stage one, the data feed. Automate the extraction that currently happens by hand. Whatever the planner downloads, copies and pastes every Monday morning becomes a scheduled load into a table they can point at. Nothing about their method changes; they get two hours back and the inputs stop being wrong because of a paste error. This is the cheapest stage and the one that buys the most goodwill.
Stage two, the calculation. Move the heavy arithmetic, the parts that are slow, error-prone and stable in definition. Statistical forecasting, hierarchy aggregation, safety stock calculation, netting. These are the pieces where a system genuinely outperforms a workbook and where the definitions are least contested. The planner still reviews and adjusts in a familiar surface.
Stage three, the review surface. Now move where the planner works, once the numbers arriving there are already trusted. This is the stage that meets the most resistance and it is much easier after two stages of demonstrated benefit.
Stage four, the exception workflow. Last, because it depends on everything above being stable, and because a workflow imposed on a process nobody trusts yet becomes something people work around.
The ordering principle is that each stage removes work without removing control, until the final stage where control moves and by then the case has been made.
Put a number on stage one before you start it, because it is the number that funds the rest. Time the current preparation step honestly: a planner spending 90 minutes every Monday assembling inputs, plus 40 minutes on Wednesday refreshing them, is spending about 112 hours a year on data assembly. Across four planners that is 448 hours, or a quarter of a full-time role, on work that has no judgement in it. That figure is defensible in front of a finance director in a way that a forecast accuracy improvement usually is not, and it is available before any system has been chosen.
The reconciliation contract
The moment the new calculation runs alongside the workbook, somebody will find a difference and the project's credibility depends on how that difference is handled.
Agree the contract before the first comparison. It has four parts: the population being compared, the tolerance, who investigates a difference, and what happens to a difference nobody can explain.
Make the tolerance a number. If you are comparing 8,000 item-weeks of forecast, agreeing that a difference under 0.5 percent of the item's mean demand is immaterial converts an unbounded argument into a list. Suppose the first run produces 1,100 differences above tolerance out of 8,000, which is 13.75 percent. That sounds alarming and it is a work list with a finish line. In practice those 1,100 will cluster into perhaps six root causes: a rounding rule, a calendar offset, a different treatment of zero-demand weeks, an outlier rule, a hierarchy mismatch and one genuine spreadsheet bug. Fixing six causes clears the list.
The part people skip is deciding in advance what happens when the spreadsheet turns out to be wrong. It will be, several times. Agreeing beforehand that a difference traced to a spreadsheet error is closed as resolved, rather than requiring the new system to reproduce the error, saves a difficult conversation later. AA8 covers the parallel run design in full, including exit criteria.
Some tabs should not migrate at all
Not everything in the workbook is a system requirement. A good share of it is analysis somebody did once, kept because deleting things feels risky.
Classify every tab into four buckets. Recurring calculation with a stable definition, which migrates. Recurring report, which becomes a report rather than a calculation. One-off analysis, which stays in a spreadsheet forever and should. And dead, which is deleted.
That classification is usually done in a single afternoon with the workbook's owner, and it typically halves the apparent scope. It also gives the owner a role in the project other than defendant.
The bucket that causes trouble is the second one. A recurring report built as a calculation looks like a requirement, and if it migrates as a calculation it brings a whole chain of intermediate key figures with it that exist only to produce a number somebody reads once a month. Ask what decision each report supports. Where the answer is that it goes into a pack and nobody has queried it in two years, it is a report and it belongs in whatever reporting tool the business already has, drawing from the planning data rather than being computed inside the planning model. Keeping reporting logic out of the planning model is one of the few architecture decisions that pays back every year rather than once.
Keep a deliberate spreadsheet path afterwards. A planning system that cannot export a usable extract, or accept a bulk paste, will drive people back to private workbooks no matter how good the interface is. The goal is to move the system of record for planning numbers, and to leave the ad hoc analysis where it works well.
What changes for the person who built it
The workbook owner is the project's biggest risk and its most valuable asset. They hold the undocumented business rules, and the migration is asking them to hand over the thing that makes them individually important.
The practical response is to make the new role explicitly larger. Whoever owned the model becomes the owner of the calculation definitions in the new system, with the authority to change parameters and the responsibility for the forecast quality measure. That is a promotion in substance if not in title, and it converts the person most able to obstruct the project into the person most invested in it. E5 covers what happens to adoption when this is handled badly.
Where this stops
The staged sequence assumes you can automate the data feed without a large integration project. Where the source data is genuinely hard to reach, stage one is not cheap and the sequence has to change, usually by starting with the calculation against a manual extract and automating later.
The reconciliation contract also assumes the spreadsheet is deterministic enough to reproduce. Some are not: they contain manual adjustments applied inconsistently, or values pasted in from a source nobody records. Where that is the case, the honest position is that a full reconciliation is impossible, and the comparison becomes a judgement about whether the new output is defensible rather than whether it matches. Say that at the start rather than discovering it in week six.
And there is a category of business where the spreadsheet is genuinely the right tool. A planning problem with a few hundred item-locations, one planner, no audit requirement and a stable method does not need a planning system, and the cost of one will not be recovered. Sizing that honestly is E4's and Z2's subject, and a vendor telling you the answer is always a system is worth discounting, mine included.
Start by classifying the tabs. Sit with whoever owns the workbook, go through it tab by tab, and mark each one as recurring calculation, recurring report, one-off, or dead. That single afternoon gives you a scope, a sequence and a collaborator, and it costs nothing beyond the time of the one person you most need on side.