The first cloud ERP business cases were built to win an argument rather than to predict a cost, and the argument was easy to win. A perpetual licence required a large payment before anything worked. A subscription required a monthly one. Put those two numbers on a slide and the conclusion writes itself. Then the fourth year arrives, the subscription renews with an uplift, and someone in finance asks when exactly the cheaper option becomes cheaper. The honest answer is that subscription and perpetual models have different cost shapes, and comparing them requires assumptions most business cases never wrote down.
What the Perpetual Model Actually Cost
The licence fee was the visible number and rarely the largest one. A traditional deployment carried annual maintenance at roughly 18 to 22 percent of licence value, which over ten years exceeds the original licence. It carried infrastructure — servers, storage, database licences, backup, disaster recovery and the data centre space around them — refreshed every four or five years. It carried people: database administrators, system administrators, and the internal team who applied patches and managed environments. It carried upgrades, and this is the line most models understated badly. A major version upgrade of an on-premise ERP was a project, not a task — testing, retrofitting customisations, regression, downtime and often external help. Organizations budgeting for two upgrades in ten years were being optimistic about both frequency and cost. And it carried the cost of not upgrading, which is harder to see: security exposure on unsupported versions, integration limits, and eventually a modernisation programme priced as a crisis.
What the Subscription Model Actually Costs
The subscription fee covers software, infrastructure, platform operations and upgrades. That is a genuine transfer of cost and effort, and it is why comparisons that set subscription against licence alone are meaningless. But several costs do not disappear, and several new ones appear. Implementation is not cheaper by much. Configuration, data migration, integration, testing and change management dominate the first-year cost in both models. Cloud removes infrastructure build; it does not remove the work of making the system fit the business. Integration is ongoing, not one-off. Cloud vendors release quarterly. Every release is a potential regression in your interfaces, which means someone must own release testing permanently. This is a recurring internal cost that on-premise deferred into occasional upgrade projects. Price escalation compounds. Annual uplifts of even 3 to 7 percent change a ten-year total substantially, and renewal negotiations after the switching cost is sunk rarely favour the customer. A model built on flat pricing is not a model. Headcount and usage drive cost. Per-user pricing means growth increases the bill automatically. That is fair, and it is also a variable most business cases held constant while forecasting aggressive expansion elsewhere in the same document. Extension work moves onto a platform. What used to be a core modification becomes a side-by-side extension with its own development, hosting and maintenance cost.
Building the Comparison Honestly
The defensible approach is a ten-year cash flow with explicit, documented assumptions on both sides. For perpetual: licence, implementation, annual maintenance, infrastructure with a refresh cycle, internal operations headcount, and two realistically costed upgrade projects. For subscription: implementation, annual subscription with a stated escalation rate and user growth curve, integration and release-testing effort, extension development and maintenance, and any premium support tier the vendor expects you to buy in year two. Then discount both to present value, because a payment in year one and a payment in year nine are not comparable amounts, and the whole difference between these models is timing. When this is done properly, the typical result is that subscription looks substantially better in years one to three, roughly comparable around years five to seven, and worse in raw cash terms by year ten — while delivering continuous currency, removing infrastructure risk and eliminating the upgrade cliff. Which of those matters more is a capital and risk question, not an arithmetic one.
| Cost area | Perpetual deployment | Subscription deployment |
|---|---|---|
| Entry costs | Licence and implementation | Implementation and subscription commitment |
| Platform operations | Infrastructure, refresh and internal operations | Contracted platform services and retained administration |
| Change effort | Version upgrade projects and customisation testing | Release testing, integration and extension maintenance |
| Growth and commercial terms | Capacity and contract assumptions | Users, usage, escalation and support tiers |
| Decision model | Document timing, risk and discount assumptions | Apply the same horizon and disclose all assumptions |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Rules for the Business Case
- Model ten years, not three. Three-year models are subscription marketing. Ten years captures the upgrade cycle that defines the on-premise cost.
- Write down the escalation assumption. State the annual uplift explicitly and negotiate a cap before signature. This single number moves the ten-year total more than most other inputs.
- Forecast users properly. Tie licence growth to the headcount plan in the same business case. Holding users flat while forecasting revenue growth is internally inconsistent.
- Cost the internal effort that remains. Release testing, integration maintenance, security administration and vendor management do not vanish with cloud. They change shape.
- Include the price of avoided risk. Removing the upgrade cliff and infrastructure refresh has real value. Quantify it rather than leaving it as a bullet in the benefits section.
- Negotiate renewal terms up front. Caps, multi-year commitments and exit terms are cheapest to obtain before you have migrated. Afterwards, your leverage is gone.
- Track the data-volume and transaction terms. Many agreements price on usage dimensions that grow faster than headcount.
- Review actual against forecast annually. Most organizations never revisit the business case, which is why the same optimistic assumptions reappear in the next one.
Why This Matters Again Now
The same comparison problem has returned with AI-enabled software. Vendors are adding AI capabilities with consumption-based pricing layered on top of per-user subscriptions, and the usage dimension — tokens, queries, documents processed — is one that few finance teams can forecast because nobody yet knows how heavily staff will use it. The discipline that produces a reliable answer is the same one that produced reliable cloud ERP business cases. State the assumptions, model the full period, include the internal effort, and negotiate the escalation and usage terms before the switching cost makes you a captive buyer. Subscription pricing was never a trick. It was a different cost shape, presented against a comparison that had been drawn to flatter it.
Common Questions
Is SaaS ERP cheaper than on-premise ERP?
It is usually cheaper in the early years and comparable or more expensive over ten years in raw cash terms, while removing infrastructure risk and upgrade projects. The answer depends on escalation rates, user growth and how upgrade costs are modelled.
What do SaaS ERP business cases most often omit?
Annual price escalation, user growth, ongoing integration and release-testing effort, platform extension development, and premium support tiers purchased after go-live.
How long should an ERP total cost of ownership model run?
Ten years. Shorter horizons exclude the on-premise upgrade cycle and understate the compounding effect of subscription escalation.
What is the single most important commercial term to negotiate?
The renewal price cap. It has the largest effect on long-run cost and is far cheaper to secure before implementation than after the switching cost has been incurred.
ERP TCO Modeling — Outpace builds ten-year cost models with the assumptions written down, tests them against your real user and volume growth, and tells you which contract terms to fix before you lose the leverage to fix them.