ERP implementation and custom modules
Every failed ERP rollout we have been called in to rescue failed the same way. The software was configured to match a process document, and the process document did not match what the factory actually does.
Why ERP projects go wrong
The process document describes the approved process. The plant runs the real one, which contains six exceptions that exist because a customer is important, a machine is unreliable, or a supplier is unpredictable. Those exceptions are not sloppiness — they are the business working around reality, and the ERP has to accommodate them or the staff will work around the ERP.
What happens next is predictable. Data entry gets done at the end of the week from a notebook. The stock figure in the system stops matching the stock on the floor. Within a year the ERP is an expensive reporting system fed by the same spreadsheets it was bought to replace.
The second failure mode is customising too early. A team hits friction in month two, requests a modification, gets it, and repeats — until the system is so far from standard that upgrading is impossible and every change needs the original vendor. The discipline is to run standard for a full cycle before customising anything, so you can tell the difference between a genuine gap and an unfamiliar habit.
How we approach it
We start on the floor, not in the conference room. Two to three weeks watching the actual process, talking to the people who enter the data and to the people who ignore the system, and writing down the exceptions. That document is the real specification, and it is worth having whether or not you proceed with any ERP at all.
Then we map it against the standard product. Most of it fits. The parts that do not become a short, deliberate list of custom modules, built as clean extensions rather than as modifications to core — so the platform can still be upgraded afterwards.
We work with ERPNext and Odoo where an open platform suits, and we build custom modules alongside SAP, Microsoft Dynamics or Tally where the estate is already committed. We do not resell licences, so we have no commission riding on which one you choose.
Migration and cutover
Data migration is where the schedule usually goes. Fifteen years of records contain duplicate masters, part numbers with three spellings, transactions against customers who no longer exist, and stock adjustments nobody can explain. Cleaning that is a business exercise with a technical component, not a technical exercise, and it needs someone on your side who is allowed to make decisions.
We run parallel for at least one full cycle — both systems live, both producing the month-end numbers, and every difference investigated rather than explained away. Cutover happens when the two agree, not when the plan says it should.
What this actually covers
Process discovery
Two to three weeks on the floor documenting the real process, including the exceptions that never made it into the SOP.
ERPNext and Odoo
Implementation and configuration on open platforms, where owning your data and your customisations matters.
Custom modules
Clean extensions for the parts that genuinely do not fit — built so the core platform can still be upgraded.
Data migration
Master cleansing, transaction history, opening balances, and a reconciliation report you can actually audit.
Integration
Connecting the ERP to your storefront, your shop-floor systems, Tally and your bank, without a nightly CSV.
Reporting
The eight reports management actually looks at, built properly, instead of forty nobody opens.
The sequence
Same shape on every engagement, so you always know what week you are in and what happens next.
Discovery on the floor
We watch the real process for two to three weeks and write down what actually happens, including who bypasses the current system and why. This document is yours regardless of what follows.
Gap analysis
The real process mapped against the standard product. Anything that fits stays standard. Anything that does not becomes a short, explicit list with a cost against each item.
Configure, then customise — in that order
We run standard through a full cycle before building anything custom, so you can tell a genuine gap from an unfamiliar habit. This single rule prevents most ERP disasters.
Migrate and run parallel
Masters and history migrated with a reconciliation report. Both systems live for at least one full cycle, with differences investigated rather than explained away.
Cutover and support
Go-live when the two systems agree, with intensive support through the first month-end — which is when every remaining problem surfaces at once.
Handed over, in your accounts
Not a demo and a login. These are the artefacts you keep, and they are what makes leaving us possible.
- A written process model of how the business actually runs, exceptions included
- A gap analysis: what the standard product covers, and what genuinely does not
- Configured environments — development, test and production — with role-based access
- A data migration with a reconciliation report tying old balances to new
- Custom modules built as upgrade-safe extensions, with source in your repository
- Role-specific training and a written runbook for month-end and year-end
Typically built with
- ERPNext
- Odoo
- Frappe
- Python
- PostgreSQL
- MariaDB
- Tally integration
- REST APIs
The selection principle is deliberately dull: largest hiring pool, longest support window. See why we choose these.
ERP, answered
The things people ask on the first call, written down so you do not have to.
How long does an ERP implementation take?
For a single-location manufacturing or distribution business, four to eight months from discovery to a stable go-live, including a parallel run. Multi-location or multi-entity adds significantly. The two things that stretch it are always the same: data quality in the legacy system, and how quickly your side can make decisions about exceptions. Neither is a software problem, which is why we surface both in the first three weeks rather than in month five.
Should we use ERPNext, Odoo, SAP or Tally?
It depends on scale and on what your estate is already committed to. ERPNext and Odoo suit small and mid-sized businesses that want to own their data and their customisations without per-user licensing that scales painfully. SAP and Dynamics make sense at larger scale or where a group standard already exists. Tally is accounting rather than ERP — it is excellent at what it does and is usually something to integrate with rather than replace. We do not resell any of these, so there is no commission riding on the answer.
Why do so many ERP projects fail?
Almost always because the system was configured against the documented process rather than the real one. The real process contains exceptions that exist for good commercial reasons, and if the ERP cannot express them, staff route around it — data entry drifts to the end of the week, stock figures stop matching the floor, and within a year you have an expensive reporting layer fed by the spreadsheets it was meant to replace. The second common cause is customising in month two instead of month twelve, which closes off the upgrade path permanently.
Can you build custom modules for an ERP we already have?
Yes, and it is a common way we get involved. The discipline is building them as clean extensions through the platform’s supported extension points rather than modifying core, so your upgrade path stays open. We will also tell you when a request is better solved by a configuration change or a process change than by code, which happens more often than you would expect.
What happens to our existing data?
It gets migrated, but the honest framing is that it gets cleaned first, and that cleaning is a business exercise. Duplicate customer masters, part numbers with three spellings and stock adjustments nobody can explain all need decisions from someone on your side with the authority to make them. We provide the tooling, the reconciliation reports and the exception lists; you provide the judgement. Budgeting real time for this is the difference between a smooth cutover and a bad one.
What usually comes with this
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- BuildE-commerce DevelopmentStorefronts, B2B ordering portals and multi-vendor marketplaces, including the catalogue and pricing rules that make them specific to you.Read more
- RunMaintenance & SupportTaking over a system someone else wrote — including the archaeology needed before anyone can safely change it.Read more
- GrowStaff AugmentationEngineers who join your standup, your repo and your review process. Billed monthly, replaceable, and yours to direct.Read more
Thinking about erp?
Start with a call rather than a brief. Thirty minutes, no deck, and an honest answer about whether we are the right people for it.

