TL;DR
ERP projects that fail in Thailand rarely fail because Odoo is the wrong product, and rarely fail because the implementation team cannot write code. They fail because decisions in the early weeks were taken in the wrong order.
Panorama Consulting reports in 2026 that more than a quarter of organisations exceed the ERP budget. The cause Panorama names is the discovery of system misfit late in the project, scope creep that follows, and custom builds requested to patch the gap.
In the view of the Enersys team, as an Odoo Silver Partner, this problem is solvable. The solution lives in the first weeks of the engagement, not after go-live.
This piece sets out seven principles the team uses with clients.
- Process before module. Not a map of the legacy onto Odoo.
- Phased rollout. Not big bang.
- Configure ninety percent before customising the remaining ten. Not the other way around.
- Data migration runs as a parallel workstream. Not as a final-week task.
- Change management gets investment equal to the technical side. Not an afterthought.
- Executive sponsor and a business owner per module. Not everything on the project manager.
- Hypercare for thirty to sixty days after go-live is a phase with a clock. Not a free service.
Anyone in a CEO, COO, CFO, or project sponsor seat for ERP will find this worth fourteen minutes.
Why ERP Projects Fail, and How Odoo Failures Look Different from Big-ERP Failures
Over fourteen years of work with Thai enterprises in energy, banking, media, and government, the Enersys team has seen three shapes of ERP failure.
The first shape. The system goes live successfully in technical terms, but the staff refuse to use it. They return to Excel. Finance teams pull reports from Odoo and reconcile them against their own spreadsheets every day, because they do not trust the numbers.
The second shape. The system runs, but it has been over-customised to the point where upgrading Odoo to a new version is hard. The client is stuck on v15 while Odoo has shipped v19. Every upgrade requires rewriting custom logic.
The third shape. The project overshoots budget and runs two or three times past the agreed timeline. Scope that was negotiated at eight modules at kickoff grows to fourteen modules by go-live, without any revisit of the business case.
The three shapes appear different on the surface. The root cause is the same. Steps in the early phase were skipped.
Odoo differs from larger ERPs such as SAP or Oracle in that early mistakes are cheaper to correct, and mid-project pivots are possible. That does not mean it forgives every mistake. Structural errors will still break the project.
Principle 1. Process Before Module
The first place the Enersys team spends time in any project is not on installing Odoo. It is on understanding the client's business processes.
Teams who have lived with ERP for long enough know this. Successful projects are not the ones that make Odoo behave like the legacy system. Successful projects use Odoo as the moment to revisit processes that have accumulated over years, and to move toward industry best practice where it makes sense.
At kickoff, the first question we ask the client is not "what do you want Odoo to do." The first question is "what does the current process look like, and which parts does everyone quietly know are not working."
Good discovery produces three artefacts.
- An AS-IS process map of what exists today.
- A TO-BE process design of what the client wants in the future.
- A gap analysis that distinguishes processes worth keeping for real business value, processes kept by habit, and processes that disappear because Odoo removes the need.
Projects that skip discovery and start with module mapping eventually return to discovery after go-live, when staff complain that the system "does not work like before." The project then enters a cycle of adding custom logic to make Odoo behave like the legacy system. That is the start of failure shape two.
Voxtron, in its 2026 article on common Odoo implementation mistakes, names replication of legacy inefficiency as the number-one mistake in failing projects.
Principle 2. Phased Rollout, Not Big Bang
Big bang go-live means launching every module on the same day. It sounds convenient. In practice it opens every risk at the same time.
Three problems with big bang.
First, staff have to learn every module simultaneously while still doing day-to-day work. The quality of learning is poor across all modules.
Second, when problems arise on launch day, the support team has to cover every module at once. The one person who knows Odoo well is pulled in many directions. Small problems become large problems because no one can respond in time.
Third, retrospectives after a phase cannot happen, because there are no phases. Everything closes on one day.
The Enersys default sequencing for new clients runs as follows.
- Phase 1. Core financial and purchase. The foundations every team uses.
- Phase 2. Sales and CRM. The revenue side.
- Phase 3. Inventory and manufacturing. The operations side.
- Phase 4. HR and payroll. The people side.
- Phase 5. Reporting and analytics. Drawn from the data that earlier phases have now made complete.
Each phase sits four to eight weeks from the next. That time is used to stabilise, train, retrospect, and enter the next phase with lessons in hand.
Voxtron in 2026 reports that phased rollouts cut deployment time by 30 to 50 percent overall against big bang, because learning and problem-solving become more efficient.
Principle 3. Configure Before Customise, at a 90/10 Ratio
Odoo addresses the business needs of most SMEs without writing new code. Standard modules, Odoo Studio, and configuration handle around ninety percent of business requirements in typical cases.
Custom development should hold the remaining five to ten percent, for cases such as.
- Specific Thai legal requirements where standard modules do not handle the local detail. For example, the depth of withholding tax and the e-Tax workflow.
- Integrations with the client's internal systems for which no standard connector exists.
- Workflows that are a real competitive differentiator for the client's business.
Projects break down when custom code exceeds ten percent of scope, or when custom appears in areas where standard already works. Over-customisation carries three costs.
The first is the implementation cost upfront, which rises directly.
The second is the maintenance cost over three to five years, which compounds.
The third is the cost of every Odoo version upgrade, which requires rewriting custom logic. If a client does not absorb that cost, they stay on the old version, and the upgrade gap widens.
When a client asks for custom work, the Enersys discovery team asks three questions first. Will standard, used close to its native form, be workable. Is this customisation a true competitive advantage, or a habit from the old system. If standard changes in the next Odoo release, will this custom code become a burden.
Those questions cut scope creep, which Panorama identifies as the leading source of budget overrun in its 2026 report.
Principle 4. Data Migration Is a Parallel Workstream
Many projects assume that data migration is a final-week task before go-live. In practice, it should begin in the third week of the project and run in parallel with configuration.
Three reasons.
First, data quality in the legacy system is usually worse than the client expects. We have seen clients whose customer master data is 20 to 30 percent duplicates, with addresses incomplete and tax IDs missing. Finding that in week three leaves time to clean. Finding it in the final week means go-live moves.
Second, the schema mapping between the old system and Odoo is rarely straightforward. The old system might keep customers and suppliers in one table. Odoo separates partners by customer rank and supplier rank. The mapping has to be designed with the business team before live migration begins.
Third, migration tests take time. The first dry run reveals many problems. Three or more dry runs before go-live materially reduce risk on launch day.
Projects that treat data migration as an afterthought either push go-live back or launch with incomplete data, which damages staff trust on day one.
Principle 5. Change Management Investment Equal to Technical
In ERP projects, the technical side often takes 80 percent of attention and change management 20. That is why systems can be technically successful while staff return to Excel.
Change management that works has four parts.
Stakeholder mapping. Identify the persona of each user group. Finance uses Odoo differently from Sales. Operations uses it differently from HR. Each group needs its own preparation.
Champion network. In each department, find the people who are open to change. Invest deeper training time in them than in others. Position them as the first stop for colleagues' questions. This reduces load on IT and support significantly.
Training that is not a user manual. Teach real workflows, not click sequences. Trainees should see how their day-to-day work happens in Odoo, including the edge cases that come up in practice.
Communication before, during, and after. Before go-live, send weekly updates. During go-live, run a support channel that everyone knows about. After go-live, share success stories and the points the team is improving.
Voxtron lists weak change management, which sends people back to Excel, as the fourth most common mistake on failing projects.
Principle 6. Clear Sponsor and Owners
ERP is not an IT project. It is a business project that uses IT as a tool. That distinction governs who is responsible for what.
In projects that succeed, three roles are visibly held.
Executive sponsor. A C-level leader with real skin in the game. The role is not to approve scope on day one. The role is to attend the steering committee every two weeks, to decide trade-offs that the team cannot resolve, and to signal to the organisation that the project matters.
Business owner per module. The Finance lead owns the accounting module. The Sales lead owns the sales module. Each owner decides the business rules for the module, signs off UAT, and is the final approver before go-live.
Project manager. Plans timelines, manages dependencies, and reports to the sponsor. Not the decision maker on business rules.
When everything falls on the project manager without active business owners, the PM ends up arbitrating business rules they do not fully understand. Wrong decisions follow, and the project fails on business value even if it succeeds on technology.
Principle 7. Hypercare Is a Phase with a Clock
Go-live is not the end of the project. It is the start of the final phase, hypercare.
During the 30 to 60 days after go-live, the implementation team continues to work with the client at full attention. The main jobs are.
- Answer tickets and questions arising in the first days within four hours.
- Monitor system stability and performance.
- Run weekly workshops to review issues and to discuss usage adjustments.
- Collect feedback for continuous improvement.
A common error is to treat hypercare as a free service tacked on at the end. The client expects the implementation team to be available 24/7 with no SLA, and the implementation team has not assigned people to that period in the plan.
In Enersys projects, hypercare is a defined phase. It has a duration. It has SLAs spelled out in the contract. A dedicated team is on standby. A formal handover plan closes the phase and transitions the client into an ongoing support contract.
A clear hypercare reduces confusion on day one of the new system, and lets the client know who to call and when.
Common Mistakes and How to Prevent Them
A summary drawn from Enersys field experience and the Voxtron 2026 reports.
Replicating legacy inefficiency. Forcing Odoo to behave like the old system. Prevention: build a TO-BE process design in discovery and convene a steering committee that approves process changes, not just scope changes.
Scope creep. Mid-project feature requests. Prevention: a change request board that evaluates every request on business value, cost, and timeline impact before accepting.
Data migration rushed in the final week. Prevention: begin in week three and run at least three dry runs.
Weak change management. Prevention: budget change management at no less than 20 percent of project cost.
Module overload on launch day. Voxtron reports that installing too many modules at the start can slow the sales process by up to 40 percent. Prevention: phased rollout, as in Principle 2.
No post-launch scalability planning. Systems designed for today's transaction volume become tomorrow's bottleneck. Prevention: capacity planning during design, and load testing before go-live.
The Enersys Approach
Enersys earned Odoo Silver Partner status in 2025, after working with Thai enterprise clients since 2012. The team holds certified experts across every Odoo version from v17 through v19.
The methodology we follow with clients runs in seven phases.
Phase 0. Strategic alignment. One to two weeks. Confirm scope, executive sponsor, and success metrics.
Phase 1. Discovery. Four to six weeks. AS-IS and TO-BE process maps, gap analysis, BRD. Our partner team works on site with the client.
Phase 2. Solution design. Two to four weeks. Module mapping, customisation scope (capped at ten percent), integration plan, data migration plan, TDD.
Phase 3. Build. Eight to twelve weeks. Configuration, the customisation that is required, integration build, and data migration build, all as parallel workstreams.
Phase 4. UAT and training. Four to six weeks. Business owner UAT, champion training, end-user training, a dry-run go-live.
Phase 5. Go-live. One to two weeks. Phased cutover in the sequence described in Principle 2.
Phase 6. Hypercare. Thirty to sixty days. SLA-bounded support, weekly retros, and handover to an ongoing contract.
Total duration for a mid-sized project is four to six months, in line with the industry benchmark Voxtron describes.
Clients that follow this methodology mostly go live on time and on budget. Not because our team executes better than others. Because the seven principles above prevent the failure modes Panorama and Voxtron describe.
Closing
ERP projects are not decided by the Odoo version chosen or the technical skill of the implementation team. They are decided by the order of decisions in the project's first weeks.
If an organisation is considering Odoo, the questions to ask before issuing an RFP.
Are we ready to revisit our own processes for four to six weeks before any build begins.
Do we have an executive sponsor ready to attend steering meetings every two weeks across the project.
Are we willing to allocate twenty percent of the budget to change management.
Will the technical team accept the ten percent customisation cap.
Will leadership decide trade-offs the team cannot resolve, on the day they need a decision.
Mostly yes means the organisation is ready for a project that succeeds. Mostly no means the time spent preparing before kickoff will pay more than starting fast and running into the failure modes described here.
The Enersys team, as an Odoo Silver Partner, is open to a conversation with organisations shaping their own ERP roadmap.
Sources
