⚡The short answer
ERP cost conversations fail because buyers anchor on the license number the vendor quotes and discover the implementation number eighteen weeks later. The license is the price of admission. The implementation — configuration, data migration, integration, testing, training and go-live support — is the actual project, and it routinely costs one to three times the license in year one.
The ranges below are total first-year figures we observe in the market: software, services and internal costs combined. They assume a competent implementation partner and a client that staffs the project properly from its own side. The single best predictor of which end of the range you land on is not the vendor you choose — it is how much you insist on customizing, which gets its own section below.
See our ERP development and implementation services
| Company size | Typical ERP scope | First-year total (market range) | Typical timeline |
|---|---|---|---|
| Small (under ~100 staff) | Finance plus one or two modules, single entity, few integrations | $75,000–$250,000 | 4–9 months |
| Mid-market (~100–1,000 staff) | Finance, inventory, procurement, multi-entity, several integrations | $250,000–$1,000,000 | 9–18 months |
| Enterprise (1,000+ staff) | Full suite, multi-country, heavy integration and compliance surface | $2,000,000+ | 18–36+ months |
⚖️License vs implementation: the ratio that frames everything
Across the market, implementation services typically run one to three times the first-year license or subscription cost. A $100,000-per-year subscription commonly arrives with a $150,000 to $300,000 implementation engagement attached. When a vendor leads with the per-user monthly price, they are quoting the smaller half of the commitment.
The ratio moves with your behaviour, not with the price list the vendor publishes. A company that adopts the standard workflows built into the ERP, migrates clean data and limits integrations lands near one-to-one. A company that demands the software replicate its existing processes exactly, migrates fifteen years of dirty data, and connects twelve other systems lands at three-to-one or beyond. The license fee is fixed; the implementation fee is a mirror of your own complexity and your willingness to change.
SaaS subscription models have changed the shape of the spend but not the total. Spreading the license over monthly payments feels gentler than a perpetual license, and it removes the upfront capital hit. It also means the meter never stops — model the five-year total cost of ownership, not the year-one cash flow, when comparing subscription ERP against alternatives.
| Where first-year money goes | Small company (typical share) | Mid-market (typical share) |
|---|---|---|
| License / subscription (year one) | 20–35% | 15–30% |
| Implementation services (config, build, test) | 30–45% | 35–50% |
| Data migration | 10–20% | 10–20% |
| Integrations with other systems | 5–15% | 10–20% |
| Training and change management | 5–10% | 5–15% |
| Internal team time (real but unbudgeted) | Varies — often the largest hidden cost | Varies — often the largest hidden cost |
🗃️Data migration: the line item that eats projects
Every ERP implementation inherits data from somewhere: legacy systems, spreadsheets, an accounting package, or all three at once. That data must be extracted, cleaned, mapped to the structure of the new system, deduplicated, validated and rehearsed — usually two or three full migration rehearsals before go-live. On a typical mid-market project, migration runs $30,000 to $150,000, and it is the workstream most likely to be underestimated by half.
The cost driver is not volume; it is quality and ownership. Migrating 500,000 clean, well-structured records is fast. Migrating 50,000 records where the customer master has duplicates, the chart of accounts was reinterpreted by three different bookkeepers, and nobody can say which spreadsheet is authoritative — that is slow, and it requires your people to make decisions, not just the consultants to run scripts. Migration is where an ERP project first meets the truth about your data, and the meeting is usually uncomfortable.
The cheapest migration decision is scope. Not everything deserves to move. Transaction history older than a defined window, dead customers, obsolete items and archived projects can live in a read-only archive instead of being transformed into the new system at full price. Every record you do not migrate saves extraction, cleansing, mapping and validation effort — and an archive query tool costs a fraction of a full historical migration.
Data migration is the only ERP workstream that cannot be fixed by adding consultants, because the hard part is decisions about your data that only your people can make. Staff it from your side, start it in month one, and rehearse the cutover twice before you believe the date.
🪤The customization trap
Every ERP buyer says the same sentence in week one: we are not that different, standard workflows are fine. Most then spend the next six months requesting changes to make the system match how they already work. Each individual request sounds small. In aggregate, customization is the single largest driver of implementation overruns, and the market rule of thumb we observe holds: heavy customization pushes implementation from one-times-license toward three-times, and then keeps charging you at every upgrade.
The mechanism is worth understanding. A configuration uses the built-in options of the system and survives upgrades. A customization is code or workflow that the vendor does not own — it must be re-tested, and often re-built, against every major release. Organizations that customize heavily eventually defer upgrades because the re-testing cost is too high, and end up running a frozen, unpatched version of a system they are still paying subscription fees on. That is the trap fully sprung.
The discipline that works: treat every customization request as a business case, not a preference. If the process the request protects genuinely differentiates the business — pricing logic that wins deals, a fulfilment method competitors cannot copy — customize with a clear conscience. If the process is different only because it grew that way, adopt the standard workflow and put the savings into training. Most customization requests are the second kind wearing the clothes of the first.
👥Change management: the budget line that predicts success
ERP projects do not fail at go-live; they fail in the months after, when people route around the new system and rebuild their spreadsheets. The technology works. The organisation declines to use it. Change management — communication, training, process redesign with the people who do the work, and visible executive sponsorship — is what prevents that, and it typically deserves 5 to 15 percent of the project budget.
Training alone is not change management. A two-hour session on where the buttons are produces users who can operate the system and resent it. What works is involving process owners early enough that the configured workflows reflect operational reality, training role-by-role on real transactions rather than demo data, and floor support in the first weeks after go-live when the questions actually arrive.
The honest internal cost: your best people will spend 20 to 50 percent of their time on the project for months, and their day jobs will feel it. Organisations that backfill or explicitly de-prioritise other work get through. Organisations that expect the project to absorb into spare capacity discover there is no spare capacity, and the project slips quarter by quarter.
📈Why ERP projects overrun
ERP overruns are so common they are structural, and the causes repeat across vendors and industries. None of them are surprises — they are all visible in the first month of a project, which is why an experienced implementation partner prices them into the plan instead of discovering them in the invoice.
| Overrun cause | How it shows up | The countermeasure |
|---|---|---|
| Scope discovery mid-project | Requirements surface during build that nobody listed during sales | Paid discovery phase before fixed commitments |
| Customization creep | Hundreds of small requests to replicate old processes | Customization business cases; adopt standard workflows |
| Data problems | Migration rehearsals reveal unusable source data | Data audit in month one; migrate less, archive more |
| Understaffed client team | Decisions wait weeks because your people are busy | Named, committed internal team with protected time |
| Integration underestimation | Each connected system has its own surprises | Prototype the riskiest integrations first |
| Big-bang go-live | Everything launches everywhere on one date | Phased rollout by module or business unit |
🧭Phased rollout economics
A phased rollout — finance first, then inventory, then manufacturing, or one business unit before the rest — costs slightly more in total services than a theoretical perfectly-executed big bang. It costs dramatically less than an actual big bang, because the theoretical one does not exist. Each phase teaches the team lessons that make the next phase faster and cheaper, and no phase can sink the whole company because the blast radius is one module or one site.
The sequencing has real economics. Start with the module that has the cleanest data and the most cooperative process owners — usually finance — because an early visible win funds organisational patience for the harder phases. Start with your most complex division and you get the worst possible trade: maximum risk at minimum experience.
There is a limit. Phasing by business function is sound; phasing by indefinitely deferring the hard modules is how companies end up running two systems forever, with the integration between them as a permanent tax. A phased plan needs committed dates for every phase, not just the first one.
🛠️When custom ERP development beats configuring a suite
There is a real alternative to the license-plus-consultants model, and it is under-discussed because neither the big vendors nor their implementation partners profit from mentioning it: building the system you actually need. Custom ERP development makes sense when your core process is genuinely differentiated, when the customization bill to make a suite fit would approach the cost of a build, or when per-user subscription fees at your scale exceed the amortised cost of owning the software.
The honest comparison is five-year total cost of ownership. A mid-market company paying $150,000 per year in subscription and carrying a heavily customized suite is spending $750,000 over five years and still does not own anything. A focused custom build covering the workflows that actually run the business — not the entire suite surface, most of which you never touch — can land in the same range with no per-user fees and no upgrade treadmill. It is not the right answer for most companies, but for process-differentiated businesses it is increasingly the financially rational one.
We build both ways — suite implementations and custom ERP systems — so the recommendation survives contact with our own incentives. If a configured suite fits your processes, take it. If the fit requires bending the software until it is neither standard nor yours, that is the conversation where custom development deserves a real evaluation.
🎯How to budget without lying to yourself
Build the budget in four envelopes, not one number: software (license or subscription), implementation services, internal cost (the time of your own people, honestly valued), and a contingency of 15 to 25 percent held by the executive sponsor rather than the project manager — contingency the project can see is contingency the project will spend.
Then stress-test the plan against the three questions that predict overruns. How much customization are we requesting, and did each request survive a business-case review? When does data migration start, and has anyone audited the source data? Who is the internal team, and what was explicitly removed from their plates to make room? A plan with good answers to those three is a plan that lands near its estimate.
If you are at the budgeting stage, we will walk your scope against these ranges and tell you which envelope looks light — including when the honest advice is that your process fits a lighter-weight system and an ERP is more than you need.