If you have spent a working week observing the seven moments we described — the spreadsheet, the WhatsApp decision, the custom transaction, the workaround, the cross-module reconciliation, the unread report, the consultant call — you likely noticed more than three. Most organisations do. The question that arrives next is harder than the observation itself. It is the question of what to do with what you saw.
The instinct, at this point, is either to panic or to dismiss. Panic says everything you observed is evidence the system is broken and must be replaced urgently. Dismissal says everyone runs on spreadsheets and workarounds, this is normal, nothing to see here. Both responses are wrong, and both are expensive in different ways. Panic produces premature migration decisions that migrate the same problems to a new environment. Dismissal produces inaction until the quiet cost becomes a loud cost.
The useful response sits between them. It requires sorting what you observed into three categories, because the observations you made last week were not all telling you the same thing.
Category one: adaptations
Some of what you observed is not a failure at all. It is a legitimate adaptation the business has made faster than the ERP could accommodate.
The sales team that makes pricing decisions in a WhatsApp group before logging them in the system may be doing so because the speed of customer response required in today's market is faster than the system's approval workflow was designed for. The operations lead who tracks a new KPI in a private spreadsheet may be doing so because the metric matters to the business now and didn't exist when the system was configured. The marketing team that runs campaigns through a third-party platform that posts records back to the ERP may be doing so because they've outgrown the ERP's native marketing module.
These are not problems. They are pace-of-change tells. They are signals that the business has evolved faster than its system, which is what should happen in a healthy organisation. The mistake is treating adaptations as symptoms. The response to an adaptation is usually not to eliminate it but to bring it properly into the system — through configuration, integration, or in some cases, an honest conversation about whether the current ERP can accommodate the adaptation at all.
Category two: symptoms
Other observations are genuine symptoms of system drift. These are the shadow systems that exist not because the business evolved, but because the core configuration no longer matches the current shape of the business.
The custom transaction nobody remembers requesting, still maintained in every upgrade cycle. The month-end reconciliation that requires pulling data from three separate modules to produce one trustworthy number. The report that exists only because someone rebuilds it manually each month, because the system can't produce it cleanly. These are not adaptations to the future. They are residue from the past. They represent work the organisation does to compensate for a system that was right once and is no longer quite right.
Symptoms are the observations that should concern you most, because they compound silently. Each custom transaction added makes the next upgrade harder. Each manual reconciliation erodes the finance team's ability to trust the primary system. Each workaround trains new hires to distrust the tools they're meant to use. Symptoms are the category that eventually produces the migration conversation, because the cost of maintaining the compensating work exceeds the cost of addressing the root drift.
The response to symptoms is a structured evaluation of whether the gap between the system’s current configuration and the business’s current shape is closable through reconfiguration, or whether it has grown beyond what the current platform can accommodate. That evaluation is not the same as deciding to migrate. It is the work you do before you are qualified to make that decision.
Category three: risks
The third category is specific, and it is the category that requires action regardless of what you decide about the broader system.
A key-person dependency — where one individual's knowledge holds together a critical part of the operation — is a continuity risk. An undocumented customisation that nobody internally fully understands is a compliance and audit risk. A consultant dependency where ordinary business changes require external billable hours is a financial risk that compounds with every change request. An integration that creates records in the ERP which nobody inside the organisation can audit is both a financial and a compliance risk, depending on how the system is licensed.
Risks do not wait for the migration conversation. They need to be named, owned, and addressed on their own timeline. Some can be resolved within the current system through documentation, training, or in-sourcing. Others require immediate architectural attention. All of them deserve a different conversation than the one about long-term platform direction.
The mistake organisations make with risks is bundling them into the migration debate. A continuity risk doesn't get solved by migration — it gets solved by documentation. A consultant dependency doesn't get solved by a new platform if the new platform is implemented by the same consultants under the same contract structure. The risks must be sorted out of the broader question and given their own response.
What this sorting produces
When the observations from last week are sorted into these three categories, most organisations discover something useful. The list of things requiring immediate action is shorter than it felt at the start. The list of things that are legitimate adaptations, to be celebrated rather than fixed, is longer than expected. And the list of genuine symptoms — the observations that actually make the case for a broader system conversation — is specific enough to be actionable.
This is the work that precedes a migration decision, not the other way around. Organisations that migrate without doing this sorting tend to migrate their risks and adaptations along with their symptoms, arriving in the new system with the same problems in new packaging. Organisations that do the sorting first tend to migrate fewer workarounds, retain more of what was actually working, and enter the new system with cleaner expectations.
What each category looks like on Odoo
The sorting framework above is platform-neutral. It works regardless of where you end up. But once you have sorted what you observed, the next question is whether the platform underneath can structurally close the gaps you identified — or whether it will reproduce them.
Here is how Odoo handles each category differently from the legacy platforms where these patterns usually form.
Adaptations get absorbed, not bolted on. Odoo’s modular architecture means that when the business outgrows a workflow — a faster approval chain, a new KPI, a marketing channel the original system did not anticipate — the adaptation can be brought into the platform as configuration, not custom development. A new field, a changed approval sequence, an additional integration: these are hours of internal work, not weeks of consultant billing. The adaptation moves from the WhatsApp group or the private spreadsheet into the system, where it becomes auditable, trainable, and maintainable. The pace-of-change tell becomes a platform capability.
Symptoms get addressed at the architecture level. The cross-module reconciliation ritual exists because the legacy platform stores the same data in different places and lets them diverge. Odoo stores data once and surfaces it across every module that needs it. Finance, operations, and purchasing see the same figure because it is the same record. The manual report that someone rebuilds each month exists because the legacy reporting layer cannot produce what the business actually needs. Odoo’s reporting is configurable by the business — not by a developer — and dashboards are built around the questions the team actually asks, not the ones the system was set up to answer years ago. The custom transaction nobody remembers requesting exists because legacy platforms penalise removal. Odoo’s open framework means standard modules cover most operational workflows natively, and when customisation is genuinely needed, it does not carry the same upgrade burden as legacy bolt-on development.
Risks get structurally reduced. The key-person dependency shrinks because Odoo’s consistent interface means fewer specialised workarounds to memorise — the same logic drives sales, purchasing, inventory, HR, and finance. The consultant dependency drops because configuration changes are business-team tasks, not developer projects. The undocumented customisation risk decreases because Odoo’s module structure makes customisations visible, version-controlled, and separable from the core — unlike legacy bolt-ons that become load-bearing in ways nobody can trace. The compliance risk from unauditable integrations diminishes because Odoo’s API framework is documented, maintained, and produces records the business can inspect without external help.
None of this eliminates the need for the sorting exercise. You still need to know which observations are adaptations, which are symptoms, and which are risks before you act on any of them. But the platform underneath determines whether the sorting leads to structural resolution or to the same patterns reassembling in a new environment.
If you have done the sorting and want to map it
Book a 30-minute conversation with the Wiz.Asia team. Bring the observations you sorted — which ones you classified as adaptations, which as symptoms, which as risks. We will map each category against what Odoo handles natively, what would need configuration, and what stays the same regardless of platform.
The output is a category-by-category assessment you can take to your leadership team — whether the path forward involves us or not.
No deck. No demo. You bring the sorting. We bring pattern recognition from comparable organisations across Malaysia and Southeast Asia.
Book a 30-minute conversation →
Wiz.Asia is an authorised Odoo Silver Partner helping organisations evaluate and modernise their ERP platforms — starting with the patterns that cost the most and the workflows that matter first.