1. Introduction and context
Many organisations that have digitised their processes in recent years come to a point where the original ERP choice must be reviewed again. The core question in this article is: do you stay on an existing ERP that is strong in customisation and sector-specific processes (such as Alan ERP via Kjerner), or is a migration to a modular, more standard-driven platform like Odoo rationally wiser?
This comparison is intended as decision support. The aim is not to designate 'winners', but to make differences visible in fit, risk and impact. In practice it is often less about functionality on paper and more about the consequences for governance, integrations, change and total costs over multiple years.
The text is relevant for three groups of decision-makers:
- Management/MT: strategic agility, risks, supplier dependence and investment level.
- Operations: process fit, planning/control, sector rules and the extent to which working methods must change.
- IT: architecture, integration management, security/compliance and manageability with growth.
Comparing is especially useful when there is a change in context: rapid growth, additional locations, new countries/languages, broadening of the product portfolio, or a wish to standardise processes because variants become too expensive in management. It can also be relevant if the integration landscape becomes more complex (more e-commerce, WMS/MES, data platforms) and the need increases for uniform data management and reporting.
Scope and assumptions: Alan ERP is approached here as publicly positioned by Kjerner (including 'custom ERP', model-driven construction, sector-specific solutions and multiple hosting forms). Odoo is treated as a modular ERP with a standard app approach that can be adapted via configuration and extensions. Because implementations make the difference, this is not a 'feature checklist', but an analytical framework based on publicly available characteristics and typical implementation choices.
Reading guide: first the positioning and starting points of both types of ERP are explained. Then follow the strengths of Alan, the strengths of Odoo, a systematic comparison, and a separate section on AI, data and integrations. Then the costs and impact of a migration are elaborated. Finally, conclusion/next steps follow and how pantalytics can support an objective approach.
2. ERP type and starting point of Alan ERP versus Odoo
Alan ERP (via Kjerner) is publicly presented as 'custom ERP' for organisations with unique or complex processes. The customer base is emphatically Dutch-oriented, with focus on growing companies (from SMEs to larger organisations) that often work from Excel or legacy and are ready for an integrated system. That is an important starting point: the product and service model seems set up for variation per customer, where the platform is used to model processes and generate screens based on that model.
The sector focus is explicit. Besides generic ERP modules, domain depth is mentioned in among others:
- Manufacturing/production, including production planning and MES-like processes.
- Food industry, with concrete verticals such as cheese production/ripening/trade (Alan Cheese ERP) and AGF (fruit and vegetable trade).
- Rental intermediation (property/rental intermediation).
Functional starting point with Alan ERP is: a set of standard modules (e.g. CRM, HRM, projects, purchasing/sales, planning, a bookkeeping module and a mobile app) combined with a model-driven way of adapting. That means that the final solution can be strongly implementation-dependent: the design of processes and data in the model largely determines what is delivered, how maintainable it is and what changes cost later.
Odoo is used in this comparison as a reference for a different type of approach: a broadly applicable, modular ERP that starts from standard apps (for sales, purchasing, inventory, production, finance, HR, CRM, etc.) and that is then extended where necessary. The philosophy is usually 'standard-first': harmonise processes towards standard where possible, and only extend where business value justifies it.
The strategic starting question behind the comparison is therefore: do you choose a customisation/model-driven approach (Alan) in which deviating processes can be central, or a standard-first platform (Odoo) in which scalability and reuse of standard weigh more heavily? That touches control and speed (now), but also scalability, dependencies and change costs (later).
3. Where Alan ERP is stronger
A first visible advantage of Alan ERP is the vertical domain depth in specific sectors. Publicly described examples (such as in the cheese vertical) are not trivial: batch management, sale by weight, drying and inventory valuation, treatment schedules, production and labelling processes, packaging and planning. This kind of functionality is often not 'out of the box' in generic ERPs, or requires additional modules and extra process design. If such sector rules are core to margin, compliance or traceability, sector-specific depth is a real distinguishing criterion.
A second strong point is the model-driven 'custom' approach. Where many ERPs are primarily configuration-driven (fields on/off, set workflows, rights, parameters), Alan is positioned as a platform on which processes can be modelled and where screens are generated from that model. That can be suitable when process logic really deviates from standard patterns: for example complex pricing or quality rules, specific batch or lot transformations, or exceptional approval chains that do not fit comfortably in standard workflows.
For organisations in manufacturing and production, the production and planning orientation can be relevant. Kjerner explicitly mentions production planning and MES-like processes. In many ERP projects, production is the place where standard ERP can fall short: shopfloor reality, short cycles, deviations, rework, weighing and traceability. An ERP designed from that reality or frequently applied in that context can lower implementation risks—provided the match with one's own factory situation is confirmed in a fit-gap.
On the theme of data sovereignty and hosting, multiple options are explicitly mentioned: cloud, on-premise and hybrid. In addition, EU hosting is mentioned (data centre in Germany). For organisations with strict requirements around data residency, compliance or customer contracts, this is a practical advantage: you can choose hosting forms that fit risk acceptance and governance, and you can concretely test in conversations how 'control over data' is configured contractually and technically.
Finally, the integration positioning is broad: it is stated that coupling with any external system is possible, with examples such as weighing systems (including VWS), a coupling with Exact (mentioned in AGF context) and Visma Net Financials (as financial solution in the cheese vertical). In sectors where peripheral equipment, logistics systems or sector platforms dominate, integration capacity is a hard precondition. However, the distinction remains important between 'coupling is possible' and 'coupling is standard, maintainable and manageable by multiple parties'. That always requires testing in architecture and management agreements.
4. Where Odoo is stronger
Odoo is usually stronger when the organisation mainly needs standardisation across multiple domains. If requirements are close to generic ERP processes—or if one is willing to harmonise processes—a standard-first approach can lead more quickly to a consistent configuration for multiple departments (sales, purchasing, inventory, finance, production, service, HR). That is especially relevant when growth leads to many variants ('this is how we do it in location A, this in location B') and management costs increase as a result.
A second distinguishing point is the product strategy around apps and extensibility. In Odoo-like ecosystems, there is usually more transparency about available modules, extensions and integrations (via marketplaces and community/partner developments). That does not mean that every extension is by definition quality, but it does offer freedom of choice and a broader range of 'building blocks' before you start customisation. In a customisation-driven model, the market is often less visible; the offer is then more implicitly with the supplier/implementation partner.
Odoo can also help reduce implementation dependence, provided the scope is correctly chosen. Where the solution mainly consists of standard functionality, every future change is often more a configuration or process decision than a development project. This is no guarantee: in Odoo too, customisation can pile up, and then dependence shifts to development capacity and release management. But if the organisation consciously steers on 'maximum standard', the change budget can become more predictable.
Data and reporting are often a scale theme in multi-entity organisations. A platform that is broadly rolled out and facilitates a uniform data model makes it easier to harmonise KPI definitions (e.g. margin, inventory rotation, OTIF, scrap, forecast accuracy). That reduces discussions about 'which truth is correct' and makes integration with BI or a data platform more consistent. The decision point is not whether reporting is possible (that is almost always so), but how much standardisation you need to build reliable management information with acceptable management costs.
Finally, multi-site/multi-country potential plays a role when multiple entities, languages, currencies or local variants are needed. In that scenario, not only functionality is relevant, but also governance: how do you enforce standard processes, how do you manage local deviations, and how do you prevent each entity from retaining its own 'variant' of the same process? A generic modular ERP is often designed with this kind of scaling issues in mind, but the outcome depends strongly on implementation choices and central process ownership.
5. Comparison
Placed side by side, you see two different starting points. Alan ERP is visibly strong in a Dutch context, with sector-specific solutions and an emphasis on modelling/customisation. Odoo positions itself more broadly and generically, with scale via modules and extensions. The effect of this is that the roadmap and governance feel different: with Alan, the solution is often more closely intertwined with the implementation partner and the modelled design; with Odoo, the discussion shifts more often to 'which standard modules do we use and which extensions do we accept'.
Functional coverage per core process is in principle possible in both cases, but with different risks and efforts:
- Sales/purchasing/inventory: generically well-supported in both models, but sector-specific rules (sale by weight, batch transformations, drying) can give Alan an advantage in vertical domains.
- Finance: Alan mentions an own bookkeeping module and couplings (including with Visma Net Financials). The choice between 'finance in ERP' versus 'finance in a separate financial package' has impact on reconciliation, reporting and audit trail.
- Planning/production: Alan positions itself strongly towards production planning and MES-like processes. For Odoo this depends more on chosen modules, configuration and the extent to which shopfloor integrations are needed.
- CRM/HRM/projects: these are domains where standardisation often goes faster in a modular app model, provided the organisation does not have very specific HR or project logic.
The process fit question is often decisive: how unique are the processes really? If the organisation has unique process steps that directly contribute to product quality, traceability or margin, then it is logical that those processes are leading and that the ERP adapts to them. If the variants are mainly historically grown, or are mainly 'preferences', then harmonisation towards standard is often cheaper and less risky in the long term. This is not a black-and-white choice: many organisations choose standard where possible and customisation where necessary, but the percentage of customisation determines the long-term costs and upgrade complexity.
IT architecture and openness form a second decision layer. Publicly it is known that Alan works with an own platform and 'Alan languages', but details about open source/source code access, external partner implementations or development standards are not publicly elaborated. That does not have to be a problem, but it increases the importance of due diligence: how is data export, APIs, development guidelines, test automation, release policy and knowledge transfer? With Odoo, the focus is often on extension and integration patterns and the discipline to keep customisation upgradeable. In both cases there is risk of vendor lock-in; the nature of the lock-in differs (platform knowledge and modelling versus customisation code, partner dependence and release management).
The implementation and change approach also differs. In a model-driven approach, there is often more design work upfront: modelling processes, establishing data definitions, generating and testing screens and flows. That can yield speed if the modelling fits well, but increases risk when requirements are still 'fluid'. In a standard-first approach, the emphasis is more often on configuring, user acceptance and process harmonisation, with customisation only after strict business case. In both approaches: the earlier scope and governance are sharp, the smaller the chance of scope creep and expensive iterations.
Governance and dependencies are the last comparison themes. With Alan, dependence on Kjerner for modelling and platform knowledge is plausibly greater, because the product concept is strongly built around that approach. With Odoo, dependence is shifting: you depend on an implementation partner, but in many cases there is more choice to switch—provided customisation, documentation and management processes are neatly arranged. This is a testing point, not an assumption: organisations must explicitly check how easy it is to place management, further development and incident handling with another party.
6. AI and Integration
Based on the consulted public pages, no explicit AI functionality is described as a core component of Alan ERP. AI is mentioned in relation to Visma Net Financials (as partner solution for finance), but not as an Alan ERP feature. That does not mean AI cannot be deployed, but that AI-driven use cases are likely to be realised via coupled tools, data platforms or partner applications rather than via an explicit 'AI in ERP' offering.
For decision-making, it is important not to reduce AI to 'does the system have an AI button'. AI delivers value if data is available and reliable, processes are stable and ownership is clear. Practical AI applications that often have business value in ERP context include:
- Forecasting: demand forecasting at item/customer level, seasonal patterns, effect of promotions; relevant for inventory, production and purchasing.
- Anomaly detection: signalling deviating transactions (e.g. unexpected price deviations, illogical inventory mutations, unusual scrap), intended for quality assurance and fraud prevention.
- Document processing: automatically processing and matching purchase invoices, packing slips or quality certificates; especially interesting with high volumes and variable document formats.
- Assistants: support for planners, buyers or customer service (e.g. 'why is order X delayed?', 'which alternative batches are available?'), provided definitions and data lineage are clear.
The AI question must therefore be translated into a decision framework: which use cases are concrete, which data fields are needed, what is the data quality, and where does the compute/logic run? In many organisations, it is more realistic to organise AI in a data platform or specialised tool, with the ERP as source and transaction system. The choice between Alan and Odoo then mainly influences: how accessible is data and events, how consistent are definitions, and how manageable are couplings.
Data and reporting maturity is a separate criterion. With Alan, real-time information is explicitly mentioned in AGF context, but there is limited public detail about dashboards, self-service BI, export options or API standards. That means you must explicitly formulate requirements: which KPIs are leading, how do you want to drill down, what is the desired audit trail, how are definitions managed, and how do you prevent multiple 'truths' from arising through exports and Excel layers?
Integrations are often the hidden cost in ERP programmes. Alan claims to be 'connectable with any system' and mentions examples such as weighing systems, Exact and Visma. The right next step is to inventory the integration landscape (WMS, MES, e-commerce, EDI, portals, weighbridges, scanners, customer/supplier systems) and establish per coupling:
- which data object is exchanged (order, batch, price, inventory, invoice);
- which pattern is used (API, batch, file, event);
- who is owner (IT, supplier, process owner);
- how monitoring, error handling and version management are arranged.
Integration architecture and management are decision points because they are directly related to downtime risk and change speed. A coupling that 'works' technically can still be organisationally unsustainable if no one is responsible for incidents, or if changes in one system always cause chain reactions. Therefore, make explicit agreements about management after go-live: which SLAs apply, how release calendars are coordinated, and how test environments and test data are configured.
Data security and compliance deserve a concrete testing list, especially in cloud and hybrid scenarios. Alan mentions EU hosting (Germany) and multiple hosting forms; the exact contractual/technical implementation of 'control' is not publicly elaborated. For both options (stay or migrate), it is wise to test at minimum: data residency, sub-processors, encryption at rest/in transit, key management (who manages keys), logging/audit, back-up and restore, RTO/RPO, access management (MFA, role model), and procedures for data deletion and export. Data sovereignty is namely not only location, but also control mechanisms and legal agreements.
10. Costs and impact of a migration
The financial consideration is rarely limited to licences. A useful framework is TCO (Total Cost of Ownership) over 3-5 years, broken down into one-off and recurring costs, plus organisational impact. Relevant cost components are:
- Licences/subscriptions: ERP licence or subscription, possible costs per user/app/module.
- Hosting: cloud costs or on-prem infrastructure, back-ups, monitoring, security tooling.
- Implementation: project costs at partner/supplier, configuration, testing, project management.
- Customisation/extension: development, documentation, test automation and future-proofing.
- Integrations: building, testing, monitoring, incident handling, change management.
- Support and further development: SLA, management team, backlog, release and regression tests.
- Internal hours: key users, process owners, data cleaning, training, change management.
The migration impact is often underestimated, especially in sectors with batches/lots and complex inventory valuation. Data migration is not only about master data (items, customers, suppliers), but also about transactions and historical context: open orders, inventory positions per location and batch, quality data, price lists, contract conditions, and financial balances. In addition, there is a strategic choice: do you migrate full history or do you archive it and migrate only what is operationally needed? The more history you migrate, the higher the complexity of mapping and reconciliation, but the easier analyses and audits become in one system.
Reconciliation is a hard precondition: inventory, production and finance must demonstrably be correct after migration. That requires trial migrations, count moments, controls on batch and valuation logic, and often also a period of parallel running or intensive cutover support. In food or production contexts, an error in batch structure or valuation can directly impact traceability and margin, and thus operational risk.
Process and organisational change is the other large cost block, but is rarely budgeted as such. A migration to a more standard-driven ERP often leads to harmonisation: fewer variants, tighter data discipline, more central definitions. That is positive for scalability, but means that teams must adjust their working method. Concretely, you often see new roles emerge or formalise: process owner per end-to-end process, key users with test and adoption responsibility, and integration management with monitoring and incident processes. If those roles are not there, the burden falls on the project team or on suppliers, which increases costs and lead time.
The most important risks and mitigations are comparable in many ERP programmes:
- Scope creep: mitigate with a tight requirements framework (must/should/could), change control and explicit 'do-not' list.
- Customisation explosion: mitigate with a standard-first policy, architecture review and business case per customisation.
- Integration breakage: mitigate with integration tests, monitoring, contractual agreements about version management.
- Production standstill: mitigate with pilots, parallel run, clear cutover plans and fallback scenarios.
Lead time and phasing depend on complexity, data quality and change capacity. A 'big bang' can be attractive to get rid of legacy quickly, but increases cutover risk and peak load on key users. A phased approach (per entity, process or location) lowers risk and enables learning, but requires longer period of hybrid integrations and temporary workarounds. The choice must be based on criticality of processes, seasonal patterns (e.g. peak periods in production/trade), and the extent to which systems can co-exist without duplicate work.
Exit and lock-in considerations must be made explicit before you migrate or extend. Think of: contract duration, conditions for data export, availability of documentation, transferability of customisation, and securing knowledge in own organisation. Lock-in is not by definition bad, but must be a conscious choice with appropriate mitigations (e.g. escrow, export formats, API contracts, internal knowledge build-up).
11. Conclusion and next steps
The core of the decision is usually in a limited number of criteria: the extent of process deviation, the necessity of sector-specific depth, the need for standardisation across multiple domains/entities, the importance of a transparent ecosystem, the complexity of integrations, and the governance the organisation can bear.
Alan remains logical in many scenarios when sector-specific requirements (such as in cheese/AGF/rental) weigh heavily, when unique process logic has competitive advantage or compliance value, and when 'custom modelling' is needed to keep the operation workable. This applies especially if the organisation is primarily Netherlands-oriented and the current solution already demonstrably aligns with shopfloor or trade reality.
Odoo is rational when the organisation mainly needs a broad standard ERP across multiple domains or entities, when expansion via modules and a broader ecosystem is desired, and when one is willing to harmonise processes to lower management costs and change costs. This applies especially with growth to multiple locations/countries, or when one wants to enforce a uniform way of working.
Next steps to objectify the choice ideally start with a compact assessment instead of an 'opinion process'. Practically this means:
- Requirements workshops per end-to-end process, with prioritisation (must/should/could).
- Fit-gap analysis on the critical processes (e.g. batch management, valuation, planning, production, traceability).
- Integration map including ownership, criticality and test strategy.
- Data readiness: data quality, definitions, migration complexity and data volume.
- Security/compliance check for hosting, data residency, encryption, logging and sub-processors.
A Proof of Concept or pilot works best if it is small but sharp: one or two critical processes, with predefined measurement points. Think of lead time of an order-to-cash chain, user acceptance with planners or quality, data quality (number of corrections), and integration reliability (error rates, recovery procedures). The outcome must not only be 'it can be done', but also 'it is manageable'.
12. How pantalytics can help with a migration
A migration decision becomes stronger when process content, architecture and financial impact are brought together in one framework. pantalytics can support by normalising requirements and variants: process inventory, prioritisation and translation into a must/should/could set, including risk assessment per deviation. This prevents each team from continuing to defend 'its own list' and creates one decision document that can be shared by MT, operations and IT.
In addition, pantalytics can set up a TCO/ROI comparison for 'staying' versus 'migrating', with multiple scenarios (e.g. phased vs big bang, with/without heavy customisation, finance in ERP vs separate financial package). This makes assumptions explicit: how much internal capacity is available, which integrations are hard, and which process variants are or are not harmonised. ROI in this type of project is usually driven by lower management and integration costs, less manual work (Excel/manual checks), less inventory and quality loss through better data, and being able to scale up faster to new entities.
On the architecture side, pantalytics helps design a target architecture for integrations and data: integration patterns (API/event/batch), monitoring and error handling, data ownership and a migration strategy (what you migrate, what you archive). This prevents integrations from being built 'project-based' without management concept, which later leads to structural incidents.
Selection and governance guidance is also often decisive for success: partner selection, contract and SLA requirements, change governance, and a release and test strategy (incl. regression tests). Especially with platforms that have continuous development, structural test and release management is crucial to limit upgrade pain.
In the execution, pantalytics can steer on migration plan and roadmap: milestones, test plan, parallel run, cutover and key user enablement. With this, the largest risks (scope creep, data quality, production standstill) are practically mitigated, instead of only named. After go-live, pantalytics can support with stabilisation and optimisation: KPIs, incident management, backlog management, process improvement and adoption measurement, so the organisation does not fall back into workarounds and Excel layers.