What software, ERP and CRM projects really cost

Two businesses ask for "a system to manage orders and invoicing" and receive quotes that differ by a factor of five. The quotes are not necessarily wrong; the projects are not actually the same. Underneath an identical sentence of requirements sit very different numbers of workflows, integrations, data problems and users — and those, not the sentence, are what a project costs.

Software pricing is closer to construction than to retail: the visible request ("a three-bedroom house") describes almost none of the cost. The cost lives in the ground conditions, the materials specified, and how many changes happen after work starts. This guide is about making those hidden drivers visible before you request quotes, so the quotes you receive are comparable and the budget you set survives contact with reality.

It deliberately contains no price lists. Any specific figure published here would be false precision for your situation; the proportions and drivers below are what actually transfer.

1. Scope and workflow count. Not the number of features on a list, but the number of distinct workflows the system must carry end to end — quote to cash, procure to pay, onboarding, returns, approvals. Each workflow has screens, rules, exceptions and reports, and each must be discovered, built and tested. Ten workflows is not twice five; interactions compound.
2. Integration surface. How many other systems it must talk to, and how politely. A modern API is cheap to integrate; a legacy system with no interface, a government portal, or a spreadsheet that is "technically" the source of truth can each cost more than entire features elsewhere in the project.
3. Data migration. The volume matters less than the quality. Clean, well-structured data from one predecessor system is a rounding error. Fifteen years of inconsistently entered records across three systems — with duplicates, dead customers and fields repurposed over time — is a project within the project.
4. Users, roles and permissions. Fifty users doing the same thing is simple. Fifty users across six roles with different views, approval rights and data visibility is a meaningfully larger design, build and testing surface.
5. Post-launch reality. Support, fixes, adjustments as the business changes, hosting, and the people who must know the system. A quote that ends at go-live describes roughly the first half of the system's real lifetime cost.

When two quotes differ wildly, the fastest diagnostic is to ask each vendor to walk through their assumptions on these five drivers. The gap almost always lives there.

For a typical mid-sized software, ERP or CRM implementation, budget distributes across six phases. The proportions below are directional ranges, not quotations — but they are the right shape for sanity-checking any proposal.

• Discovery and design (10–15%). Mapping workflows, deciding what is standard and what is custom, specifying integrations. Teams that compress this phase do not save the money; they spend it later with interest, as rework.
• Build and configuration (35–45%). The core of the project — configuration for platforms, development for custom work. This is where scope discipline is won or lost.
• Data migration (10–20%). The widest range of any phase, because it is driven by source data quality, which nobody has measured at proposal time. Treat any fixed low number here with suspicion.
• Testing (10–15%). Including user acceptance testing with the people who will actually run the processes. Skimped testing converts directly into post-launch support cost.
• Training and change management (5–10%). Small on paper, decisive in practice. Systems fail from non-adoption far more often than from defects.
• Post-launch support (ongoing). Commonly an annual commitment in the range of a fifth to a third of the build cost, covering fixes, adjustments, hosting and the retention of people who understand the system.

A proposal that allocates 90% to build and a token line to everything else is not a lean proposal — it is an optimistic one.

The three paths have different cost shapes, and the cheapest year-one option is often not the cheapest five-year one.

Off-the-shelf software

Lowest entry cost and fastest start, paid for in fit: you adapt your processes to the product, and the adaptation cost — workarounds, parallel spreadsheets, manual steps — is real but invisible on any invoice. Economical when your processes are genuinely standard and the product's way is acceptable.

Configured platforms — Odoo, Tally

Mid-range and predictable: implementation effort, licensing, hosting, plus customisation where your processes genuinely differ. The cost risk is over-customisation — deep changes recreate custom-software maintenance costs on top of platform licence costs. Kept shallow, this path is the best value for most businesses with mostly-standard processes, whether through Odoo customisation or Tally customisation.

Custom software

Highest build cost and an ongoing maintenance obligation, but exact fit and full ownership. Economical when the process it carries is a genuine differentiator or when integration requirements defeat every platform — evaluated properly in our Odoo-versus-custom guide and delivered through custom software development.

The most expensive outcome across all three paths is choosing one for comfort and migrating off it two years later. Second most expensive: choosing the cheaper year-one option for a process where fit actually matters.

Data cleanup

Not the migration itself — the cleanup that must precede it. Deduplicating customers, closing dead accounts, reconciling the three places the same item is coded differently. This is unglamorous work that only your own team can fully do, and it lands on top of their day jobs. Budget the internal time, not just the vendor line.

Change management and training

Every person whose daily work changes needs time to learn, a period of reduced productivity, and somewhere to ask questions. Multiplied across a whole team, this is one of the largest costs of the project and appears on no quote, because the vendor cannot absorb it for you. Plan for a real productivity dip in the first weeks after go-live.

Integration maintenance

Integrations are built once and maintained forever. Every connected system changes its API, its credentials or its behaviour eventually, and each change lands on your integration layer. Ten integrations is not a feature list; it is a standing maintenance commitment that should shape both your build-versus-buy choice and your support budget.

The internal owner

Someone inside your business must own the system — prioritise changes, manage the vendor, know where the bodies are buried. If that role is not explicitly assigned and resourced, it silently becomes nobody's job, and every future change becomes slower and more expensive.

You do not need a specification document to get comparable quotes. You need honest answers to six questions, written down in a page or two.

1. Workflows. List the distinct end-to-end processes the system must carry — typically five to fifteen, not one and not forty.
2. Systems. List every other system it must exchange data with, and note which have modern APIs and which do not.
3. Data. Name the predecessor systems, the years of history involved, and give an honest grade of the data's cleanliness.
4. Users. Count them, then group them into roles with genuinely different needs. Three roles is a different project from ten.
5. Must differ. Identify the one or two processes where you cannot accept standard behaviour — this determines whether you are buying configuration or construction.
6. Constraint. State the timeline that is real (not desired) and the budget shape the business can carry.

Bring that page to vendors and two things happen: the quotes come back comparable because everyone priced the same reality, and the vendors who engage seriously with your answers distinguish themselves from those selling a standard package. Both outcomes are worth more than any number on the quote itself.