ERPNext Buyer Objections Answered: GST, Support, Data Ownership, Migration & Lock-In (2026)

I have had this conversation with enough prospective clients to know where the hesitation lives. It is rarely about features. It is about risk: will this meet my compliance obligations, am I locking myself in, and what happens the day something breaks. Below are the five objections I hear most often, answered the way I would on a call.

Which objections come up most, and what is the short answer to each?

Each gets its full answer below, including the parts that are not flattering. How we run an implementation, stage by stage, is on the ERPNext implementation services page.

Is ERPNext actually GST-compliant, or will I need custom development?

For standard Indian SME cases, ERPNext is GST-compliant with configuration, not custom code. GST lives in the India Compliance app, built by Resilient Tech and open source (GST moved out of ERPNext's core in version 14). It handles e-invoicing, e-way bills, GSTR-1 preparation and purchase reconciliation; the API features (e-invoice, e-way bill) need an India Compliance account. The objection usually comes from someone burned by a system that claimed compliance and then needed months of custom work to file correctly.

Where custom work does come in: unusual tax cases sometimes need configuration beyond the defaults, such as multi-state operations with complex reverse-charge cases or specific industry exemptions. That is normal for any ERP. The GST 2026 readiness checklist has the configuration list if you want the detail before deciding.

Skimmable summary: GST in ERPNext comes from the open-source India Compliance app; edge cases need configuration, not a custom build.

Does choosing open-source ERPNext mean I'm on my own if something breaks?

No. You choose your support model separately from the software licence. That can be an implementer, Frappe Cloud's managed hosting with support plans, or an in-house team backed by the community. People used to proprietary software raise this most, because there the vendor and the support contract are one relationship. Open source separates them: the software has no licence fee and you can read it; support is a decision you make deliberately.

In practice, most SMEs use an implementer for setup and ongoing support. That works much like proprietary ERP support, except you are not tied to one vendor if the relationship sours. The Frappe community forum and the GitHub issue trackers are active, and Frappe's own engineers respond to reported bugs there. It is a different support surface from a proprietary ticket queue, not a lesser one. How we do it is on the support page.

Skimmable summary: open source does not mean unsupported; you choose an implementer, Frappe Cloud or an in-house team, and no single vendor owns the relationship.

Who actually owns my data and customisations if I use ERPNext?

You own both. ERPNext stores everything in a standard MariaDB database. Custom code lives in a Frappe app you can read, export or move to any hosting provider, with no one's permission. ERPNext has no proprietary lock: your database is yours, exportable in standard formats, and your custom app code is yours, on infrastructure you choose.

With a proprietary SaaS ERP, "your data" often means data you can view through the vendor's export tool, in a format designed for their convenience, on infrastructure you never touch. ERPNext keeps every exit open: change hosting, change implementer or run the whole stack yourself, at any point. The caveat is discipline: the exit is only real if you hold the database backups, the code repository and the hosting credentials. The ERPNext platform page covers how we set that ownership up.

Skimmable summary: your data and customisations sit in a standard database and readable code you control, provided you hold the backups, repository and credentials.

What's the real risk of a migration to ERPNext going wrong?

Poor data mapping and too little testing, not the platform. The common failure is opening balances or history migrated incorrectly, not the system crashing or losing data. Any ERP migration, on any platform, carries real risk if mapping and validation are rushed.

The fix is process. A proper migration maps every field from your source system (Tally, Zoho, Excel) to its ERPNext equivalent, runs a parallel reconciliation period before cutover, and keeps the old system readable for a defined window after go-live. The Tally to ERPNext migration guide walks through the sequence, and the migration page shows how we run it.

Skimmable summary: migration risk sits in data mapping and validation; a parallel reconciliation is the real safeguard.

What happens if our implementer disappears or the relationship doesn't work out?

Any competent Frappe developer can pick up support, because the codebase, customisations and documentation are standard and readable. That is different from a proprietary ERP, where vendor-specific knowledge can be a single point of failure. The objection really asks how dependent you are on one relationship. With ERPNext, less than with most alternatives: nothing about the platform belongs to your original implementer.

One condition. This holds only if your implementer delivers clean, documented custom apps rather than undocumented edits to core files. Ask about that directly before you commit; it is one of the real differences between a good implementation and a risky one.

Skimmable summary: open code means you are not tied to one implementer, provided their work was clean and documented.

When is the objection right, and ERPNext the wrong choice?

Sometimes the hesitation is correct. ERPNext is the wrong choice, or not yet the right one, when:

• You only need books and GST. Tally or Zoho Books will serve you with less setup; see ERPNext vs Tally.
• A parent company or major customer mandates SAP or another named ERP. Integration and audit familiarity will win; see ERPNext for large enterprises.
• Nobody will own the system. Without an implementer on contract or someone in-house who understands it, an open system drifts. Decide who owns it before you buy.
• Counters must bill through frequent outages. Stock ERPNext POS needs a connection; see does ERPNext work offline?
• You must be live next week. A polished SaaS you subscribe to starts faster; ERPNext needs implementation time.

How do you de-risk the ERPNext decision before committing?

If the objections still feel abstract, work through this before signing anything:

1. Check GST against your actual cases. List your tax scenarios (inter-state, reverse charge, exemptions) and have them shown in the India Compliance app, not promised.
2. Choose your support model on paper. Implementer, Frappe Cloud or in-house: name the model, the response time and who owns upgrades.
3. Ask for the exit in writing. Database export path, custom-app repository access and hosting credentials should all be yours from day one.
4. Insist on parallel reconciliation. No cutover until a defined period of the old system and ERPNext side by side reconciles clean.
5. Audit the implementer's code discipline. Ask to see a past project's custom app: documented, versioned, no core-file edits.

Frequently asked questions