This is the map. Each section summarises a decision and links to the piece that goes into it properly.
1. What a custom ERP actually replaces
Rarely the accounting system. What it replaces is the spreadsheet layer that grew up beside it — the parallel workbook production keeps for work orders, the sheet the transport desk maintains, the reconciliation file finance rebuilds every month.
Each of those marks a point where the incumbent stopped describing the business. Counting them, honestly, is the most reliable diagnostic there is.
→ The real cost of forcing your business into template software
2. The decision before the decision
Is the unusual thing about your process a differentiator, or an accident of history? Building around an accident encodes it for another decade.
If a packaged product covers around ninety per cent through configuration alone, buy it. Custom earns its cost only where the way you work is why you win.
→ ERPNext vs Odoo vs a custom build · Custom ERP vs SAP · Build vs buy
3. What moves the number
Five variables decide the cost, and none of them is headcount: process variance, integration surface, the condition of the data, module count in the first phase, and how much of the work happens on site.
Any range quoted before those are measured is a guess with a currency symbol on it.
→ What actually moves the cost of a custom ERP · How we price
4. How long it takes
First modules in three to five months; a full operational core in nine to fourteen, phase by phase. The phase most often compressed is discovery, which is the one with no visible output — and compressing it moves the same work into build, where being wrong is expensive.
→ How long a custom ERP takes, phase by phase · How we engage
5. Migration is decided by the master data
Migration effort tracks data quality, not record count. A million clean transaction rows move in an afternoon; four thousand item masters that disagree with each other can hold a go-live for a quarter.
→ ERP data migration: the master data decides the timeline
6. Moving off what you have
For most Indian businesses the incumbent is Tally, and the right first shape is usually to keep it — operations move to the new system, which posts summarised entries into Tally, so finance keeps a tool it trusts and the filings do not move on day one.
→ When Tally stops being enough · Migrating from Tally to a custom ERP
7. Sequencing the rollout
One cutover weekend or overlapping systems for a year. The trade is not risk against speed — it is whether the project can be stopped at sixty per cent and still be worth something.
→ Big bang or phased: sequencing a system replacement
8. The integrations that get underestimated
Every system the ERP must exchange data with is a contract to build and maintain. In India, GST e-invoicing and e-way bills deserve particular attention: at volume they stop being a form and become a dependency in the despatch path.
→ GST, e-invoicing and e-way bills at real volume · Tally integration
9. Why these projects fail
Almost never in the code. The fatal decisions cluster in the weeks before it, when everyone was eager to start and nobody wanted to slow down for questions.
→ Software projects fail in the two months before the code
10. Who owns it afterwards
The project ends and the platform does not. Hypercare, the support model and the internal capability decide whether adoption survives its second year.
→ Who owns the ERP after go-live
If you read one thing
Count your spreadsheets, then ask what each one is compensating for. If the answer is a handful of reports, you need better reporting. If the answer is how you price, produce or decide credit, the template has been taxing your operations for years — and the invoice simply never arrived in a form anyone could file.