A custom ERP is software built around how your company actually works, covering the stock, orders, production, accounts and compliance steps your current tools handle badly. This guide follows the decisions in the order you face them: whether you need one, whether to build or buy, what shapes cost and time, how to move your data, how to roll out, and who owns the system afterwards. Each section links to a longer article.
Do you need one? Count your spreadsheets
A custom ERP rarely replaces the accounting package. It replaces the layer of spreadsheets that has grown beside the main system: a work-order workbook on the shop floor, a dispatch sheet at the transport desk, a reconciliation file that finance rebuilds every month.
Each spreadsheet marks a place where the main system stopped describing the business. Run a short count:
- List every spreadsheet that more than one person edits or relies on.
- For each, write what the main system cannot do that forced it to exist.
- Mark whether it holds a rule that decides money: a price, a credit limit, a production yield.
A handful of reporting sheets means you need better reporting. Sheets that carry pricing, planning or credit rules mean the software is shaping your operations instead of serving them. The longer argument is in custom ERP versus off-the-shelf.
Build or buy: three tests
Buy a packaged product when all three of these hold. Build when any one fails.
| Test | Buy if | Build if |
|---|---|---|
| Fit | A mature product covers almost all your process through settings alone | Your way of working is what wins customers |
| Stability | Your organisation is still changing shape quickly | The core process has been stable for years |
| Ownership | You have no one to own a platform after launch | You can name the people who will own it |
Open-source and mid-market packages sit between the two. The ERPNext, Odoo and custom comparison covers them. A custom ERP can also wrap around a package you already run.
What drives the cost
Five variables set the price of a custom ERP. Headcount is not one of them.
- Process variance. The more exceptions per process, the more rules to build and test.
- Integration surface. Each system the ERP exchanges data with is a separate piece of work to build and maintain.
- Data condition. Clean masters are quick to move. Duplicates and mismatched units are not.
- Modules in phase one. Two modules cost far less than eight.
- Work on site. Time spent mapping the floor, the warehouse and the accounts desk adds cost and removes risk.
A range quoted before these are measured is a guess. Ask any vendor to tell you which of the five their number assumes. The cost drivers article goes through each, and what drives the cost of custom software in India covers the broader quote.
How long it takes
A custom ERP is built and released in phases, so ask about the date of the first live module, not the date of "completion". Phases usually run in this order:
| Phase | What you receive |
|---|---|
| Process mapping | Written maps of each process, with the exceptions listed |
| Design | A domain model and a module plan, with phase one agreed |
| Build and release | Working modules every fortnight in your test environment |
| Migration | Reconciled data and a cutover and rollback plan |
| Go-live and support | Live modules, a support route and a handover plan |
Discovery is the phase most often squeezed because it produces no visible software. Squeezing it moves the same questions into the build, where wrong answers cost more to fix. For phase detail, see the phase-by-phase timeline.
Data migration is decided by master data
Migration effort follows data quality, not row count. A large table of clean transactions moves quickly. A smaller set of item records that contradict one another can delay a go-live.
Check four things before anyone quotes a date:
- Duplicate masters. The same customer, supplier or item entered under several names.
- Units. Kilograms in one record, tonnes in another, pieces in a third.
- Opening balances. Stock and ledger figures that have never reconciled.
- Open documents. Orders, invoices and payments in flight on the cutover date.
ERP data migration: where it goes wrong lists the checks and the reconciliation sequence.
Moving off what you run today
Many Indian businesses start from Tally. A common first design keeps it: day-to-day operations run in the new system, and summary entries flow into Tally, so the finance team keeps a tool it knows and the filing process does not change on day one. Read when Tally stops being enough and the Tally to custom ERP migration page.
Spreadsheets and SAP ECC follow similar paths, covered in the legacy modernisation guide.
Cutover options
There are two sequences. A one-weekend switch means a single rollback decision. Overlapping systems go live module by module, and the old system keeps running everything not yet moved.
The better test is this: if the project stopped at the halfway point, would you have something worth keeping? Overlap passes that test more easily. Big bang or phased rollout works through the choice.
Integrations that get underestimated
Every connection is a contract that someone must build and maintain: banks, payment gateways, logistics partners, tax systems. GST is the one most Indian projects meet first.
According to an EY India alert on CBIC Notification No. 10/2023 (Central Tax), dated 10 May 2023, the e-invoicing turnover threshold was lowered from 1 August 2023 (the notification sets the amount). Source: EY India, e-invoicing threshold. Check the notification text for your own case. Once you issue e-invoices and e-way bills in large numbers, they sit inside your dispatch path. A slow or failed call to the government portal can hold a truck at the gate. The GST integration article covers the design.
Why these projects fail
Most failures begin before anyone writes code. The unclear requirement, the unexamined assumption, the skipped discovery: each is cheap to fix in week two and expensive in month nine. Why software projects fail before the code lists the early warning signs. Four are worth checking now:
- No one on your side owns the process decisions.
- The scope is a list of screens and not a list of processes.
- Nobody has seen real data from the current system.
- The plan has no stopping points.
Ownership after go-live
When the project closes, the system keeps running. Decide before signing who fixes a fault at night, who approves a change request, and who trains the next hire. The ownership article sets out three models: your team, the vendor, or a mix.
Also settle the legal side. The source code and documentation belong in a repository under your company's name from day one, with an assignment that states term and territory. See security and IP for offshore engineering teams for the clause detail.
A first-meeting checklist
Take these to any ERP vendor:
- Which five cost variables does this quote assume?
- When does the first module go live, and what does it cover?
- Who owns the code from the first commit?
- How is data checked before cutover, and by whom?
- What does the rollback plan say?
- Who supports the system after go-live, and at what cost?
- If we leave, what do we receive and how soon?
For a wider vendor shortlist, see choosing a software development company in India.
What a sensible first phase contains
A first phase should be small enough to finish and large enough to matter. A usable test: it covers one process from start to end, uses real data, connects to the one or two systems that process depends on, and replaces at least one spreadsheet that people use daily. For a manufacturer, that could be order intake through to dispatch and invoice. For a distributor, it could be stock by warehouse with purchase and sales orders.
Write down three measures before work starts: how long the process takes today, how many manual re-entries it needs, and how many spreadsheets it uses. Measure again after go-live. Without a before figure, nobody can say whether phase one worked, and the case for phase two rests on opinion.
Questions buyers ask
Is a custom ERP always more expensive than a package?
Not over a long period. A package carries licence fees per user and customisation cost. A custom system carries build cost and ownership cost. Compare both over your planned horizon with the same number of users.
Can a custom ERP replace SAP or Tally completely?
It can. Many companies keep Tally for statutory books at first and move operations. A phased plan lets you retire the old system only after the new one has run in parallel.
What is the smallest sensible first phase?
One module that hurts most, with its data and its integrations. Add the others when the first is running.
What happens if we want a different vendor later?
With your own repository, written documentation and a handover clause, another team can pick up the work. That is the reason to settle ownership at signing.
Where Brihat Infotech fits
Brihat Infotech builds custom ERP systems for manufacturers and other process-heavy organisations. The team maps your processes on site before proposing any module, releases in phases and leaves your code in your own repository from the first commit.