What an ERP or CRM implementation actually costs in India

An ERP or CRM implementation in India generally runs from about ₹5 lakh for a single-department rollout to well over ₹50 lakh for a multi-entity system replacing several tools at once. The number most buyers are quoted first — the licence fee — is usually the smallest part of it.

That is the single most expensive misunderstanding in this category, so it is worth being precise about where the money actually goes.

The licence is not the cost

Vendors quote per user, per month, and the arithmetic looks manageable. Forty users on a mid-market platform is a figure a finance head can approve without much argument.

Then the implementation is quoted separately, and it is commonly one to three times the first year's licence. Not because anyone is overcharging, but because the licence buys software that does not yet know anything about your business. Somebody has to tell it: your chart of accounts, your approval limits, your tax treatment, your warehouse locations, your pricing rules, your commission structure. That work is the project. The licence is the starting condition.

When you compare two proposals, compare the total for the first two years — licence, implementation, migration, training and support — or you are not comparing the same thing.

Configuration and customisation are different products

Every platform in this category is designed to be configured. Configuration means using the settings the vendor built for the purpose: defining a tax rule, adding an approval stage, creating a report. It is fast, it survives upgrades, and it is the cheap path.

Customisation means writing code against the platform because the thing you need was not anticipated. It is the expensive path, and the cost is not the initial build — it is that every future upgrade has to be tested against your custom code, forever. A heavily customised ERP is a system you now maintain.

The most valuable thing an implementation partner does is push back on requests that should be configuration and are being asked for as customisation. Often what a client describes as a hard requirement is an existing process that exists because the previous software demanded it. Changing the process is free. Changing the software is not.

The honest test: if a requirement exists because of how your business genuinely differs from others, customise. If it exists because of how your last system worked, configure and change the habit.

What moves the number most

How many departments go live, and in what order. One department is a project. Five simultaneously is not five projects — it is considerably more, because the interfaces between them all have to be right at once, and everyone is learning at the same time.

What the data is coming out of. Migration is consistently the most underestimated line. Data that lives in a previous system with a documented schema is tractable. Data that lives in twelve years of spreadsheets, with three spellings of the same supplier and a column that means two different things depending on the row, is a cleaning project before it is a migration project. It is worth extracting a sample before anyone quotes, because the state of the data is the state of the estimate.

How many integrations it needs. Banking, GST filing, e-way bills, payment gateways, a shopfloor system, an existing website. Each one is a negotiation with something you do not control, and most of the real cost is in handling the far end being slow, down, or returning something unexpected.

Whether financial records live in it. Systems holding money need reconciliation, audit trails and writes that cannot double-post on a retry. That work never appears in a demo and is a large share of the engineering.

How much of your team's time is available. This is the cost nobody quotes. An implementation needs someone inside your business who can decide how a process should work and make that decision stick. If that person does not exist, or exists but has no time, the project stalls at the point where it needs answers — and a stalled implementation still costs money.

The bands these projects fall into

Using the same bands as our contact form:

• ₹5–15 lakh — one department or one function. A CRM for a sales team, inventory for a single location, a focused rollout on a standard platform with light configuration and clean migration.
• ₹15–50 lakh — where most genuine ERP work sits. Several connected modules, a real migration, a handful of integrations, role-based access across departments, and training that has to reach people who did not ask for new software.
• Above ₹50 lakh — multi-entity or multi-location operations, regulated workflows, systems replacing several existing tools simultaneously, or implementations with substantial custom modules.

A single sentence can move a project between bands. "It also needs to handle our three sister companies with separate books" is one of them.

The costs that appear later

Three are predictable enough that you should budget them at the start rather than meeting them in year two.

The second year. Licences renew, and the discount on the first year often does not repeat. Ask what year two costs before signing year one.

Training, and then training again. The people trained during rollout are not the only people who will ever use the system. Staff turnover means whoever owns this internally needs the material to train a replacement without calling the vendor.

The reports nobody specified. Every implementation reaches a point, usually two months after go-live, where someone senior asks for a view of the data that was never in scope. It is normal, it is reasonable, and it is much cheaper if the system was built by someone who expected the question.

Why we will not quote before a discovery conversation

We quote fixed prices, and that is exactly why the sequence matters. A fixed number given before anyone has seen your data, your approval chain or your integration list is either padded to cover the unknown, in which case you overpay, or optimistic, in which case the gap reappears later as change requests.

A short discovery session establishes which departments are in scope, what the data is coming out of, what has to be integrated and who inside your business will own the decisions. That produces a written scope, and the scope produces a fixed quote. If the scope changes later, that is normal — it is priced and agreed before work starts, not discovered on an invoice.

Questions worth asking any implementation partner

• What in our requirement list would you configure, and what would need custom code?
• What does year two cost, in total?
• Who cleans the data before migration, and how is that priced?
• What happens to our customisations when the platform upgrades?
• Which of our requirements would you advise us to drop?

That last one matters most here. An ERP scope that has never been cut is an ERP scope nobody has interrogated, and it will be cut later — after it has been paid for.

When the answer is not an ERP

Sometimes it is not. A business running well on a few well-chosen tools, with one painful gap between them, usually wants that gap closed rather than a platform replacing everything. Closing it is a fraction of the cost and a fraction of the disruption.

We say this when it is true, including when it means a much smaller engagement. The alternative is delivering a system that is resented by the people who have to use it every day, which is the most common way these projects fail — not technically, but in adoption.

If you are weighing this up, what custom software actually costs in India covers the build-versus-buy question in more general terms, and our ERP and CRM systems page describes how we run these engagements.