ERP total cost of ownership (TCO) is every cost of acquiring, implementing, running, changing and eventually replacing an ERP over a fixed period, usually five years. It includes licences or development, implementation partners, customisation, upgrades, hosting, support and the time your own staff spend on the system, not only what appears on the vendor's invoice.
First-year cost is a poor guide to which option is cheaper. A licensed ERP often looks cheaper to start and grows with users and modules; a custom ERP usually costs more up front and less per year after. The only fair comparison is the same period, the same scope and the same assumptions. This guide gives you that model, with variables in place of prices so you can fill it with real quotes.
What goes into ERP total cost of ownership?
TCO has five groups of cost: acquisition, implementation, running, change, and exit. Each group behaves differently for licensed and custom ERP.
| Cost group | Licensed ERP (SaaS or package) | Custom ERP |
|---|---|---|
| Acquisition | Subscription per user or per module, sometimes a platform fee | Development of the agreed scope |
| Implementation | Partner fees for configuration, data migration, training | Discovery, migration, testing, training (often part of the build) |
| Customisation | Extensions, add-ons, partner-built modules | Already part of the build; later changes are new development |
| Running | Subscription renewals, add-on subscriptions, integration tools | Hosting, monitoring, backups, support and maintenance |
| Upgrades | Vendor upgrades included, but customisations may need retesting or rework | Framework and dependency updates you schedule and fund |
| Internal staff | System administrator, key users, partner management | Product owner, key users, vendor management |
| Exit | Data export, contract terms, replacing add-ons | Code and data are yours; switching the support team takes handover effort |
If you are weighing a system built around your own processes, our custom ERP software page explains the approach. If you have already chosen a package, the same model applies; only the lines change.
Which costs are most often missed?
The costs that do not arrive on a vendor invoice are the ones most often missed. Internal time, retesting after upgrades and the gradual addition of users and add-ons are the usual gaps.
- Internal staff time. Key users spend time on design workshops, testing, training others and handling exceptions. This is real cost even if no invoice arrives.
- User growth. Per-user pricing means headcount growth raises the bill every year.
- Add-ons and connectors. Payment, ecommerce, reporting and document tools often carry their own subscriptions.
- Upgrade retesting. Package upgrades can affect customisations and integrations, which then need testing or rework.
- Integration maintenance. Connected systems change their APIs, and someone has to keep the connections working. Budget for monitoring and fixing them.
- Parallel running and data clean-up. Time spent on data migration is often underestimated.
- Exit cost. What it costs to leave, five or ten years later.
How do you build a five-year ERP TCO model?
List every cost line for each option, decide which lines are one-off and which recur, apply your growth assumptions, and add them up year by year. The template below uses letters in place of prices; replace them with figures from real quotes and your own payroll costs.
The variables
| Variable | Meaning | Licensed | Custom |
|---|---|---|---|
| U | Number of users in year 1 | Yes | Only if hosting or tools are per user |
| g | Yearly user growth rate | Yes | Rarely |
| L | Licence or subscription per user per year | Yes | No |
| A | Add-on subscriptions per year | Yes | Sometimes (third-party services) |
| P | Implementation partner fees (one-off) | Yes | No |
| C | Customisation and extension work (one-off) | Yes | No |
| D | Development of agreed scope (one-off) | No | Yes |
| H | Hosting, monitoring and backups per year | Often included | Yes |
| S | Support and maintenance per year | Partner support | Development team support |
| R | Upgrade retesting or framework updates per year | Yes | Yes |
| N | Change requests and new features per year | Yes | Yes |
| I | Internal staff time per year | Yes | Yes |
| X | Exit cost (one-off, end of period) | Yes | Yes |
The formulas
Licensed five-year TCO = P + C + the sum over five years of (U for that year x L + A + S + R + N + I) + X
Custom five-year TCO = D + the sum over five years of (H + S + R + N + I) + X
Where users grow, users in year n equal U x (1 + g) raised to the power (n minus 1). Keep both columns honest: if you include internal time on one side, include it on the other.
Template
| Line | Year 0 | Year 1 | Year 2 | Year 3 | Year 4 | Year 5 |
|---|---|---|---|---|---|---|
| Licences (users x L) | ||||||
| Add-ons (A) | ||||||
| Partner implementation (P) | ||||||
| Customisation (C) | ||||||
| Development (D) | ||||||
| Hosting (H) | ||||||
| Support (S) | ||||||
| Upgrades and retesting (R) | ||||||
| Changes and new features (N) | ||||||
| Internal staff time (I) | ||||||
| Exit (X) | ||||||
| Total |
Year 0 is the project period before go-live. Run the model twice: once with the user growth and change volume you expect, and once with a more demanding case.
Should you discount future costs?
Discounting converts future payments into today's money so that a cost in year five weighs less than the same cost today. If your finance team already uses a discount rate for investment decisions, apply it to both options. If not, a simple undiscounted total is acceptable for a first comparison, provided both columns are treated the same way. What matters more is that recurring lines such as licences and support include any price increases written into the contract.
Illustrative scenario: how the curves usually differ
The scenario below is illustrative and uses no real prices. A services company with a growing team compares a subscription ERP with a custom ERP for the same scope.
- Licensed option. Lower one-off cost (P plus C), but the licence line rises every year as users grow, and the company has bought two add-ons. Each major upgrade triggers retesting of the custom extensions.
- Custom option. Higher one-off cost (D), then a flatter yearly line made of hosting and support. New features cost development effort, but there is no per-user charge.
The two cumulative cost lines often cross at some point. Where they cross depends on user growth, how much the package must be customised, and how much new development the custom system needs each year. Without your numbers, nobody can tell you which year that is, and a vendor who claims a fixed break-even point without seeing your model is guessing.
What else should a TCO comparison weigh?
Money is not the whole decision. A cheaper option that cannot support your process, or that locks your data in, can cost more in lost efficiency than it saves.
- Fit to process. How much of your operation works without customisation?
- Control of the roadmap. Licensed ERP follows the vendor's roadmap; custom ERP follows yours, and you fund it.
- Ownership. With custom development, ask who owns the code. At Timeline Digital, project source code transfers on full payment and client data is the client's throughout; see IP ownership.
- Support continuity. Can another team support the system if the original vendor leaves?
- Risk of change. Price increases, product retirement or a partner leaving the market.
Checklist: before you trust a TCO comparison
- Same scope and same five-year period for both options
- User growth assumption written down and applied to licences
- Add-ons, connectors and third-party services listed
- Implementation partner fees and customisation quoted, not guessed
- Hosting and support quoted for the custom option
- Upgrade retesting included for both options
- A realistic yearly budget for changes and new features
- Internal staff time estimated for both options
- Exit cost and data export terms reviewed
- Second run with a more demanding growth case
When is a TCO model not the right tool?
A TCO model is the wrong starting point if your requirements are still unclear, because both columns will be guesses. Define the scope first with a software requirements brief, then model cost. It is also less useful for very small teams with standard processes, where a packaged product is usually the obvious choice and a detailed model adds little. For the wider buy-or-build question, see ERP vs custom development.
How to start
Collect real quotes for each line, estimate internal time with the people who will do the work, and fill the template above for both options. The custom ERP development cost guide shows how to size the custom side, and the cloud ERP vs on-premise ERP guide covers the hosting line.
When you want the custom column filled with real numbers, discuss the project with us. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, so the development and support lines in your model come from working software and an agreed scope.