ERP Project Costs – Estimating
What an ERP decision actually costs, built line by line — and held to it through selection and implementation.
The number most ERP business cases get wrong
Ask a company what replacing its ERP would cost and you will usually get an implementation figure and a subscription figure. Ask what keeping the current system costs over the same five years and the question often lands as a surprise — which is the problem, because the current system is what every other option has to beat.
Your existing system's cost runs underneath every path. It does not stop when a decision is made. It runs at full rate through selection and implementation, overlaps the new system through parallel operation, and leaves a residual tail behind. Paths do not differ in whether they carry that cost. They differ only in when and how it ends.
Stated as an identity, this is the whole model
Path cost = the current system's continuing cost + the cost of change + what is left over afterward
Modeling the current system as though it stops at the decision — or as a flat line that never escalates — is the most common error in ERP business cases, and it points the same way every time: toward whichever path is being sold.
An example of what the model catches
On a recent analysis, four paths were costed over five years. Replace came out cheapest at $4.77M and Stabilize at $5.26M — not because the replacement project was cheap, but because it stopped paying for the incumbent while the lighter path carried it at full rate for the whole window.
Then read the same model at three years. Replace becomes the most expensive path of the four. Nothing changed but the length of the look. A company that will not commit past three years should reach a different conclusion than a five-year framing suggests — so both are shown, always, and neither is shown alone.
One more line from the same analysis, because it is the kind of thing a cost model is for: the high end of Replace's range exceeded the high end of Stabilize's. On cost alone those two paths were not cleanly separated, and any statement that replacing was cheaper needed that sentence attached to it. We attach it.
How a figure gets built
The question set is fixed before you are involved. A standard library of just over a hundred cost elements across fourteen groups is brought to every engagement. The register is populated from that library — never authored from scratch, and never assembled from what a client or a seller happened to put in front of us. A cost element with no answer is a finding, not a blank. Where an element genuinely does not apply, it is trimmed with a reason recorded rather than quietly omitted.
This matters most for the costs nobody volunteers: transition and parallel operation, the unsettled period after go-live, and legacy systems retained after cutover. Those three are the classic omission set, and leaving them out favors change every time.
Every line carries an evidence class, and the class sets the range. The range is not judgment applied at the end. It follows mechanically from how the number was obtained.
| Class | What qualifies | Range |
|---|---|---|
| A | Contracted or quoted, and not exposed to scope or term uncertainty | −5% / +5% |
| B | Benchmarked from comparable engagements against a confirmed quantity | −10% / +20% |
| C | Modeled — a parametric derivation | −15% / +35% |
| D | Allowance — a cost known to exist but not yet characterized | −25% / +75% |
| E | Irreducible — the driving variable cannot be known by anyone, at any level of effort | −40% / +100% |
Ranges roll up by summing the lows and summing the highs. Statistical combination would produce a narrower and arguably more elegant aggregate, and it assumes element errors are independent — which in ERP work they are not. A company whose discipline fails on scope fails on data and on timeline at the same time. The simple sum is the honest treatment, and it survives being asked how it was built.
One example of what a class actually decides. On a recent baseline, an incumbent subscription line was classed B rather than A even though the current price was certain — because the renewal carried no escalation cap against a double-digit observed uplift. A firm price with an uncapped renewal is not a contracted fact about the next five years.
Two kinds of cost, and only one of them is knowable
Treating access cost and implementation cost as one estimating problem gives one of them a false floor of precision.
Access cost is mechanically estimable. It decomposes into units of measure, quantities and unit costs, and each part is knowable at the level the work requires.
That precision has a commercial edge to it. On a recent engagement the client's ERP population was 48 full users and 33 light or occasional ones — engineers entering a change order once a day, approvers, people who only view and report. Sellers price full named seats by default and rarely volunteer a restricted tier unprompted. On year-five quantities that distinction was worth roughly $42,000 a year. And where a seller refuses the tier the cost does not disappear: buyers build workarounds, share credentials, batch entry through one person, or leave populations off the system entirely — and the cost reappears somewhere nobody can see it.
Implementation cost is irreducibly uncertain, and we say so. How many consulting hours an implementation will consume cannot be determined in advance — not by us, not by the implementer, not by anyone. Any total is therefore a construct resting on an unknowable variable, and it is labeled an estimate everywhere it appears. Not a cost, not a budget, not a price.
What makes the comparison survive that is parallel construction. Every path's implementation is built the same way from one common reference case, scaled by path, with the same adders applied as percentages of each path's own figure. A shared uncertainty can move the paths together; it cannot reorder them. So the difference between paths is load-bearing output even where no single absolute figure is defensible — and where one path is estimated by a vendor's fixed-fee proposal and another by a modeled figure, that protection is gone. Parallel construction is a requirement, not an observation.
A seller's figures are intelligence, never inputs
A vendor proposal, price sheet or business case is read closely, and read for what it discloses rather than for what it charges: the scope it assumes, what it bundles and what it names as extra, what the seller evidently believes you need, and above all what it leaves out. That reading is worth the time.
Then the numbers go in the bin. Every figure in the model is built from our own basis — the standard library, your captured current costs, and our read of realistically obtainable market terms — and would stand unchanged if the proposal had never existed.
This is not suspicion of any particular seller. A seller's price is a competitive instrument shaped by the scope it assumes, so adopting the price adopts the scope with it, silently. The result is the seller's business case wearing the buyer's letterhead, and it is very hard to see once it has happened.
The same discipline runs the other way. A market estimate that quietly assumes best-case pricing makes replacement look cheaper than anyone should plan against — the same error, self-inflicted, failing the buyer in the same direction. Expected means expected. Pursuing better terms is later work, and it never gets folded into a planning figure.
Rules that make two paths comparable
A comparison violating any of these is not a comparison.
Common horizon. Every path is costed over the same window.
Common start. Every path is priced from the same day. No path carries an assumed delay the others do not.
Common inclusion set. If an element is counted for one path it is counted or explicitly zeroed for every path. Blanks are prohibited.
Common value state. A hoped-for negotiated price for one path against today's rate card for another is a false comparison, and it runs in the buyer's disfavor.
The current system's cost runs under every path, and it is not flat. Contracted escalation, observed trend, allocation changes, end-of-life support premiums and deferred remediation all belong in that curve.
Incumbent paths inherit today's commercial terms. Where a better deal with the current vendor is genuinely available, that is leverage to be used — never a forecast to be priced in.
One-time and recurring are shown separately and never netted. An annual operating comparison that omits a seven-figure implementation is not an error of emphasis; it is a different question being answered.
Cost is cost. Benefit, ROI, NPV and payback are a separate reading. A seller's benefit model is not admissible as an input to any figure of ours; it may be characterized as a seller claim.
Risk is not cost. Real but unmonetized exposures — support staff attrition, unsupported software, security posture — are carried as risk. Converting risk into dollars hides a judgment inside a number.
Identification, then control — across all three services
The same register and the same rules run through every engagement. What changes is the precision the work has earned, and what is being done with it.
In strategy planning — identification and honest estimation
More things have to be estimated here than anywhere else, because nothing is settled yet — but the estimate is deliberately uncomplicated, and it is built to compare paths rather than to price a purchase. Replacement is costed as a class, standing for a capable modern system, never as a quotation from a named product.
In selection — the estimate becomes specific, and the work turns to control
The model drills into the full architecture: every license type, module, device, integration dimension and threshold trigger, because the project is real and specific sellers are being engaged. Where a strategy engagement came first, that work is confirmed rather than repeated, and the variance between what was estimated and what is now obtainable is itself a finding.
Two rules govern the negotiation. Never negotiate a total, and never accept a not-to-exceed figure: it is priced to protect the implementer, purchased with concessions elsewhere, and it converts an honest uncertainty into a false certainty the buyer pays for twice. Negotiate the building blocks instead — rates by role, travel terms, fixed fees for discrete defined items, billing increments, rate hold periods.
And press every named cost-escalation exposure into the agreement: integration priced on indirect users or transaction volume, module dependencies that surface at configuration, user growth without locked pricing, revenue or core-count thresholds crossed inside the window, renewal without escalation protection.
In pre-implementation readiness — the register becomes the control instrument
Committed is tracked against actual, and variance is attributed: to scope change, to discipline, or to estimating error. Estimating error is the useful one. It feeds the benchmark library and moves elements from modeled to benchmarked on the next engagement, which is why the estimates get better rather than merely older.
Any figure can be taken apart
No element is released without an evidence class recorded against it, and no deliverable carrying cost figures ships without a Cost Basis Audit: per element, its value state, evidence class, source, range, and which paths it applies to.
The drill path is the point. Path total → element group → element line → evidence class → source record. “Something looks off” becomes a working session rather than a rejection, and it takes seconds rather than a week.
That is also the standard we hold ourselves to internally. On the analysis quoted above, an internal project-management line had been summed into every path's implementation figure — charging diverted staff effort as cost while the organizational-impact reading was already carrying it, the same fact counted twice in opposite directions. It was found, excluded, and the rule written down. The audit trail is what made it findable.
Engleman Associates holds no seller relationships of any kind — no fees, referrals or commissions from any ERP vendor or implementer. That is what allows every figure on this page to be built from the buyer's side of the table.
The EAI cost estimating framework and this presentation of it are © 2026 Engleman Associates, Inc. All rights reserved.