Choosing your ERP in 2026: why the issue of sovereignty changes everything

The ERP is not just any software. It manages billing, archives contracts, keeps commercial history, hosts payroll, structures accounting, and models production. Everything that constitutes the operational value of a company passes through it. An ERP outage means a lost day. An ERP loss can sometimes mean the death of a company.

This criticality changes the nature of the choice. An ERP is not a tool that is replaced every two years. It is a ten to fifteen-year investment, inseparable from the organization, inseparable from the data. And data, in 2026, has become as much a political issue as an operational one. Cloud Act, FISA 702, geopolitical fragmentation, extraterritorial sanctions, tensions between economic blocs: what seemed taken for granted in the 2010s — the idea that an American cloud was worth any other cloud — no longer holds. The jurisdictional risk on corporate data is now an unavoidable parameter in the purchasing decision.

This article offers a comparative reading of fourteen ERPs on the market, organized around issues of sovereignty, cost, ergonomics, functional richness and depth, technical stack, and data ownership.

Warning.Auguria is a consulting and integration firm specialized in Odoo. Aware of this bias, we have sought in this comparison to present each solution with the same rigor, highlighting its strengths and weaknesses, including for Odoo. Depending on the company's context, another ERP may be the best choice — and we say so when that is the case. The goal is not to convince, but to enlighten.

The specific risks of the proprietary model

Before delving into the evaluation criteria, it is important to mention a point often overlooked in ERP comparisons: the structural risks of the proprietary model. These risks are not isolated cases or theoretical hypotheses. They are regularly observed in the field, and they are inherently absent from the open-source model.

Retrieving your own data can be expensive.In a proprietary solution, particularly in SaaS, your business data is stored in structures and formats controlled by the vendor. When the time comes to leave — end of contract, change of tool, commercial disagreement — the complete and usable export of your informational assets is not always straightforward. Some vendors charge for extraction. Others only provide degraded exports, forcing the company to pay a service provider to reconstruct its data in a usable format. There are documented cases of organizations that had to pay significant amounts, sometimes in six figures, just to retrieve what belonged to them.

License audits are a commercial lever.SAP, Oracle, Microsoft, IBM, and several other major publishers conduct regular compliance audits. The finding is well-known: these audits often lead to significant adjustments, sometimes in the hundreds of thousands of euros or even millions, when the company is deemed to be in overuse. Overuse is not always intentional — it often stems from an inextricable contractual complexity, where it is difficult for the client to know precisely what they are allowed to use.

The publisher imposes its schedule.When SAP sets the end of support for SAP ECC to the end of 2027 (with a paid extension until 2030), tens of thousands of customers worldwide find themselves forced to migrate to S/4HANA according to a timeline they did not choose. The same pattern regularly plays out with Oracle, Microsoft, Sage, or Cegid during major product transitions. The client follows the publisher's pace, not their own.

Price increases are captive.Once an ERP is installed, business processes configured, users trained, and integrations in place, the psychological and financial cost of exit becomes prohibitive. The publisher knows this and raises its annual prices accordingly. Increases of 5 to 20% per year on proprietary SaaS subscriptions have become the norm, not the exception. Over ten years, the cumulative effect is massive.

The publisher can be acquired or disappear.Infor was acquired by Koch Industries in 2020. Cegid was taken over by KKR. Many players in the French mid-market have changed hands over the past five years. Each acquisition redefines the product strategy, business terms, and roadmap. In the extreme case of a publisher that shuts down or discontinues a product line, customers are left with unsupported software, no access to the code, and no clear option for continuity.

The proprietary stack amplifies all of this.When the development language (SAP's ABAP, Microsoft's X++, Oracle's SuiteScript) or the database (HANA, Oracle Database, SQL Server) are themselves proprietary, the previous risks accumulate. Skills are rare and expensive, the underlying licenses add to the ERP license, and portability becomes nearly nonexistent.

These risks do not invalidate the choice of a proprietary solution. They exist in exchange for real qualities: sometimes unmatched functional depth, mature industrial ecosystems, native integrations with other tools. But a clear-headed decision incorporates risks as much as strengths. Ignoring them is exposing oneself to discovering them at the worst moment — the moment when one would precisely like to exit.

The four axes of sovereignty evaluation

Once these risks are established, the reading of ERPs is organized around four complementary axes. They are independent: an ERP can be good on one and bad on another. Complete sovereignty requires ticking all four.

Axis 1 — The publisher's jurisdiction.What national or supranational law applies to the publisher? A publisher subject to U.S. law — even if it operates its servers in Germany or France — remains exposed to the Cloud Act, which allows U.S. federal authorities to demand access to data stored by an entity under U.S. jurisdiction, regardless of where it is physically located. FISA 702 goes in the same direction for electronic communications. A European publisher, on the other hand, is not subject to these provisions.

Axis 2 — The status of the source code.Is the ERP code proprietary and closed, or is it open, readable, and modifiable? A closed code creates total functional dependency on the publisher: to understand a malfunction, to add a function, to correct a vulnerability, one must go through them. Open code allows a third-party integrator or an internal team to audit, correct, and extend. This difference radically changes the dynamics of the contractual relationship over time.

Axis 3 — The technical stack: language and database.An ERP relies on two structuring technical components: a programming language for the application layer, and a database for the storage layer. Each has its own license and its own skills market.

On the language side, some are free and universal: Python (PSF License), Java (OpenJDK under GPL with Classpath Exception), PHP (PHP License), JavaScript. There are many developers, free tools, and abundant documentation. The skills acquired on one project are reusable elsewhere. In contrast, several major ERPs use proprietary languages developed and controlled by their vendor: ABAP for SAP, X++ for Microsoft Dynamics F&O, SuiteScript for Oracle NetSuite, and the 4GL Harmony for historical Divalto. These languages create a captive market: developers are rare, their daily rates are high, and their skills are not easily transferable.

On the database side, we see the same divide. PostgreSQL (PostgreSQL License, BSD type), MariaDB, and MySQL (GPL) are free and open-source. Oracle Database, Microsoft SQL Server, Azure SQL Database, and SAP HANA are proprietary and paid — sometimes heavily. In a significant ERP deployment, the database license can represent a substantial portion of the total cost, sometimes equivalent to that of the application layer.

An ERP built on a 100% free stack guarantees portability, long-term cost control, and access to an open skills market. A proprietary stack adds a layer of technical and financial lock-in, making any future migration considerably more complex.

Axis 4 — Hosting.Where is the infrastructure physically located, and above all: who operates it legally? A French host — OVHcloud, Scaleway, 3DS Outscale, NumSpot, or qualified regional hosts — is subject to French and European law. An operator subject to American law — Amazon's AWS, Microsoft's Azure, Google's Google Cloud Platform — remains exposed to the Cloud Act, even when its data centers are located in Frankfurt, Paris, or London. The physical location of the servers is not enough: it is the jurisdiction of the operator that determines extraterritorial exposure.

These four axes are independent and cumulative. A European open-source ERP hosted on AWS loses its sovereignty at the infrastructure level. A German proprietary ERP deployed on-premise on its own servers retains jurisdictional sovereignty but remains locked by its code and stack. Only the combination of the four axes provides complete sovereignty.

Overview of ERPs

We present the solutions in two distinct families. First, the ERPs built around an open-source core, whose model profoundly changes the relationship between the company and its publisher. Then the proprietary ERPs, whose functional maturity is often their main asset, but which require accepting the structural risks outlined above.

Family 1 — Open Source Core ERPs

The open-source model in ERPs is not just a matter of licensing or being free. It modifies five fundamental parameters:

• The code can be read, audited, and corrected by any competent developer.
• Data is stored in a standard database (PostgreSQL, MariaDB, MySQL) directly accessible without intermediaries.
• In case of difficulty with the publisher, any other provider can take over.
• In the event of the publisher's disappearance, the code remains usable and maintainable by the community.
• Export, backup, and data migration do not depend on the permission of a third party.

However, a nuance is necessary. The so-calledopen coremodel — practiced notably by Odoo and Axelor — offers a Community part under a free license and an Enterprise part under a proprietary license with access to the sources. The Enterprise part is neither free nor redistributable. Strict GPL or AGPL models (Dolibarr, Tryton, ERPNext, Axelor Community) guarantee total openness.

Odoo

Description.Published by the Belgian company Odoo SA, based in Ramillies. All-in-one ERP suite covering almost all management functions. Open core model: Community under LGPLv3, Enterprise under proprietary license with access to the sources. Three official hosting modes: Odoo Online (multi-tenant SaaS), Odoo.sh (PaaS on Google Cloud Platform — GCP, Google's infrastructure cloud, an American operator subject to the Cloud Act), and On-Premise (free deployment).

Strengths.Remarkable functional scope, with over 90 official modules and several thousand third-party apps. Modern user interface, one of the best in the ERP market. Fully open technical stack (Python, PostgreSQL). Global network of integrators and partners. Affordable pricing, particularly at entry. Customization open to any Python developer. The official On-Premise mode allows for complete sovereign deployment without giving up the Enterprise license.

Weaknesses.Centralized publisher roadmap, without a formal mechanism for client influence. Annual release cycle with three years of support in Enterprise, which imposes regular and costly migrations. Enterprise commercial policy is tightening, with significant price increases in recent years. The Enterprise code is not free despite the readability of the sources, which limits the scope of the 'open source' label. Coexistence with the OCA community (Odoo Community Association) which maintains a large catalog of complementary free modules: the relationship between the publisher and the OCA is dynamic, sometimes in discussion, and illustrates the duality of the open core model. Uneven functional depth depending on the modules — some fall short of vertical specialists (complex production, EAM, specialized retail).

Sovereignty.Software: excellent (Belgian publisher, free stack). Hosting: variable depending on the mode. Online and Odoo.sh are on GCP and therefore subject to the Cloud Act. On-Premise on sovereign cloud (OVHcloud, Scaleway, Outscale, NumSpot) or own servers = complete sovereignty.

Dolibarr

Description.French project supported by the Dolibarr Foundation, an associative structure. Strict GPLv3 license. No single commercial publisher: governance is community-based, collaborative development.

Strengths.Maximum sovereignty on the four axes, without any reservations: French publisher, strict GPL code, free stack (PHP, MariaDB or PostgreSQL), fully free hosting. No licensing costs. Active community for over fifteen years. Excellent fit for the needs of micro-enterprises and small SMEs. Dolistore marketplace with a rich catalog of third-party modules. Simple architecture, making it easy to maintain and understand.

Weaknesses.Functional coverage is more limited than Odoo, particularly weak on heavy industrial topics, complex multi-country operations, advanced supply chain, and multi-level production. Less modern, less fluid interface. Insufficient depth for complex mid-sized companies. A more limited and less structured ecosystem of professional service providers. Associative governance that does not offer a predictable commercial roadmap — an advantage in terms of sovereignty, a disadvantage for buyers who want a strong vendor commitment.

Sovereignty.Maximum, across the four axes, without reservation.

Tryton

Description.Originated from a historical fork of OpenERP in 2008. Supported by the Tryton Foundation, a European foundation with a presence in Germany, Belgium, and Spain. GPLv3 license. Python and PostgreSQL stack.

Strengths.Extremely rigorous, modular, and stable architecture. Solid accounting depth. Particularly clean code, appreciated by demanding developers. Maximum sovereignty (European foundation, open stack).

Weaknesses.Austere user interface, little investment in UX. Very limited partner ecosystem, leading to low resource availability. Documentation can be lacking. Limited job market, complicating recruitment. High expertise cost due to the rarity of skills.

Sovereignty.Maximum.

Axelor

Description.French publisher. Unified ERP, BPM, and CRM suite, under AGPLv3 open source license for the Community version, proprietary for the Enterprise version. Java and PostgreSQL stack. Integrated low-code studio.

Strengths.Low-code studio allowing customizations without coding, which reduces dependence on developers. Wide functional coverage, native integration with ERP + BPM + CRM. Independent French publisher. Open technical stack.

Weaknesses.Modest market share compared to Odoo, which limits the ecosystem of providers and the customer base. AGPLv3 license is restrictive for proprietary integrations (any modification used over a network must be published). Low international recognition. Average functional depth in some specialized areas.

Sovereignty.Excellent on all four axes in Community edition. Enterprise remains under proprietary license (sources accessible).

ERPNext (Frappe)

Description.Indian publisher, Frappe Technologies. Strict GPLv3 license. Python and MariaDB stack. Wide functional coverage. Based on the Frappe framework, which is reusable for other applications.

Strengths.Fully open source, no proprietary Enterprise version. Open stack. Wide functional coverage. No licensing costs. Dynamic community. Frappe platform usable beyond ERP.

Weaknesses.Indian publisher, which raises questions of geographical, cultural, and legal distance for a European organization. European provider ecosystem still modest. French localization could be improved — French accounting, taxation, and payroll are not the publisher's natural territory. Average functional depth in some critical areas.

Sovereignty.Good in the strict sense (India outside the US extraterritorial framework, strict GPL, free stack). Caveat regarding the location of the publisher, which can be blocking for certain organizations.

Family 2 — Proprietary ERPs

The following ERPs rely on proprietary code, paid licenses (often per user), and frequently on proprietary technical stacks themselves. They inherently carry the risks mentioned at the beginning of the article: data captivity, license audits, imposed timelines, price increases, dependence on the publisher's longevity, technical lock-in.

However, these solutions have strengths that the open-source model does not always match: ultra-specialized vertical ecosystems (fashion, automotive, accounting expertise, defense), native integration with other components of a proprietary information system (notably Microsoft Office), or functional depth built over several decades. The right choice is not to reject them by principle, but to evaluate them by honestly looking at the benefit/risk balance.

SAP S/4HANA and its variations

Description.Global reference for large account ERPs. German publisher, headquartered in Walldorf. Listed both in Frankfurt and on the NYSE. Available in S/4HANA (large account), Business One (SME), Business ByDesign, and GROW with SAP (mid-market SaaS).

Strengths.Unmatched functional depth in finance, supply chain, and production. De facto standard in several major sectors: heavy industry, aerospace, energy, pharmaceuticals. Very dense global ecosystem (consultants, training, certifications, vertical specialists). Recognized ability to support very large multinational organizations with high regulatory and tax complexity.

Weaknesses.Very high total cost of ownership across all areas (licenses, integration, maintenance at 22% per year, rare and expensive human resources). Abrupt and costly migrations — the end of support for SAP ECC at the end of 2027, with a paid extension until 2030, forces tens of thousands of customers to switch to S/4HANA on a mandated timeline. Proprietary ABAP code, a SAP-specific language that requires rare expertise. Historically complex UX, the addition of Fiori improves but does not solve everything. Unilateral vendor roadmap. Proprietary HANA database stack. License audit practices known for their strictness.

Sovereignty.Partial. Favorable German jurisdiction and native GDPR, but the NYSE listing, massive US operational presence, and cloud offerings RISE/GROW largely relying on AWS, Azure, and GCP reintroduce extraterritorial exposure through hosting. On-premise deployment on sovereign infrastructure remains technically possible, but is counter to the current commercial strategy of the vendor.

Oracle NetSuite

Description.American pure SaaS player, owned by Oracle. Well established in the mid-market segment and financial-focused SMEs. Presence in France.

Strengths.Pure SaaS model, with no client-side infrastructure management. Native internationalization: multi-currency, multi-country, local compliance. Robust financial reporting, Oracle heritage. Continuous updates. Short implementation time for standard scopes.

Weaknesses.Industrial coverage and low production. Customization constrained by SuiteScript, a proprietary JavaScript-like language. Costs that rise rapidly with the number of users and modules. Strong technical and contractual lock-in on Oracle. Fully proprietary database stack. Oracle has long been known for its aggressive license audit practices.

Sovereignty.None. US publisher, Oracle infrastructure, exposure to Cloud Act and FISA 702.

Microsoft Dynamics 365

Description.Modular ERP/CRM suite from Microsoft, hosted on Azure. Broken down into Finance & Operations (large enterprise), Business Central (mid-market), Customer Engagement (CRM).

Strengths.Native integration with Office 365, Teams, Power BI, Power Platform — a decisive argument when the IT system is already 100% Microsoft. Modern UX. Massive partner ecosystem. Low-code customization capability via Power Platform.

Weaknesses.High and rising license costs. Very strong Azure lock-in. Complex migrations between versions. Low portability outside the Microsoft ecosystem. Dependence on Power Platform for extensibility, which itself becomes a recurring cost. X++ is a proprietary Microsoft language, captive.

Sovereignty.None. US publisher, Azure hosting, applicable Cloud Act. The Blue offer (Microsoft + Capgemini + Orange) attempts to mitigate this risk but does not eliminate legal uncertainty as long as the underlying technology remains under US control.

Infor CloudSuite

Description.Industry-specific ERP suite: fashion, automotive, distribution, healthcare, industrial equipment. American publisher, owned by Koch Industries since 2020.

Strengths.Very deep and mature industry verticals: Fashion, Automotive, M3 (discrete manufacturing), LN. SaaS on AWS. Approach based on standardized industry best practices, which reduces configuration costs on typical scopes.

Weaknesses.Partner ecosystem less dense in France than SAP or Microsoft. Customization tools are being modernized. High cost. AWS lock-in. Platform modernization can be cumbersome for clients on older versions.

Sovereignty.None. US publisher, AWS infrastructure, Cloud Act applicable.

Sage

Description.British publisher, long established in France. Historically fragmented range: Sage 100 (SMEs in France), Sage X3 (international mid-market), Sage Intacct (SaaS finance, designed in the US), Sage Business Cloud.

Strengths.High product maturity. Very strong French tax and social compliance (accounting, payroll, FEC, declarations). Strong installed base, particularly among accountants. Dense ecosystem of French service providers. Good reputation in payroll and accounting.

Weaknesses.Technical heterogeneity between products — moving from Sage 100 to Sage X3 is not an upgrade, it's a software change. Often outdated UX. Commercial strategy pushing migration to Intacct, designed and operated in the United States, raising increasingly acute sovereignty issues. Rising costs. Proprietary database stack (SQL Server, Oracle).

Sovereignty.Good on historical products (UK, excluding Cloud Act). To be examined product by product for Intacct (US-designed) and for SaaS offerings whose hosting needs to be verified.

Cegid

Description.French publisher, strong in certain verticals: retail (Cegid Retail), accounting and payroll (Cegid Loop), HR (Cegid Talentsoft), tax management.

Strengths.Very deep and mature verticals in targeted segments. Impeccable French compliance. Strong foothold in the French market. Mature SaaS.

Weaknesses.Not well suited outside of targeted verticals. Heterogeneity of range resulting from growth through acquisitions. Capital largely held by foreign investment funds (notably KKR), to be integrated into the analysis of the publisher's capital sovereignty. Proprietary database stack (SQL Server). Increasing license and SaaS costs.

Sovereignty.Good on the jurisdictional axis (FR), with attention to the evolving capital structure and hosting (often Microsoft Azure).

Divalto

Description.French publisher specialized in SMEs in industry, trade, and distribution. Main range: Divalto Infinity (ERP) and Divalto Weavy (mobile CRM).

Strengths.Very good fit for French industrial SMEs. Well-served trade, construction, and technical distribution verticals. Close to the publisher. French capital independence. Reasonable pricing.

Weaknesses.Modest recognition and ecosystem size compared to major players. Limited international coverage. Ongoing migration from the historical Harmony stack (proprietary 4GL) to .NET, creating a technical transition for historical clients. Proprietary database stack (SQL Server).

Sovereignty.Excellent on the publisher axis (FR, independent capital). Hosting is most often controlled by the client. Partially proprietary technical stack.

IFS Cloud

Description.Swedish publisher, a reference in asset-intensive and project-driven industries: energy, defense, aerospace, equipment maintenance, on-site services.

Strengths.Remarkable functional depth in EAM (Enterprise Asset Management), complex project management, and field services. Strong presence in European defense and aerospace. Swedish jurisdiction. Modern UX since IFS Cloud.

Weaknesses.High cost. Partner ecosystem less dense in France than SAP or Microsoft. Partially proprietary technical stack (Java + Oracle DB). IFS Cloud is often deployed on Azure, which reintroduces a hosting question. Capital mostly held by investment funds (EQT and Hg).

Sovereignty.Good on the publisher front (Sweden). To be examined regarding hosting (common Azure) and the database (proprietary Oracle).

The mirage of "sovereign cloud"

A special mention is warranted for the offers labeled "sovereign cloud" or "trusted cloud." Several American hyperscalers have formed joint ventures with French operators: Bleu (Microsoft Azure × Capgemini × Orange), S3NS (Google Cloud × Thales). The stated goal is to obtain the SecNumCloud qualification from ANSSI and to isolate European operators from American injunctions. On paper, the system improves the situation. In legal practice, the debate remains lively: as long as the underlying technology is designed, operated, and licensed by a publisher subject to American law, total isolation is legally contestable.

For those seeking full and complete assurance, true sovereign clouds remain limited to European operators with European capital and European technology: OVHcloud, Scaleway, 3DS Outscale (qualified SecNumCloud), NumSpot, and qualified regional French hosts.

Summary Table

Cost legend: € very low · €€ moderate · €€€ high · €€€€ very high · €€€€€ premium large account.

Which ERPs offer complete sovereignty?

For an ERP to achieve full sovereignty, the following four conditions must be met simultaneously:

1. Publisher under non-extraterritorial jurisdiction, ideally European.
2. Open source code, auditable, modifiable.
3. Language and database under open license.
4. Controlled hosting: self-hosting or sovereign cloud not linked to an entity subject to U.S. law.

Solutions that meet the four conditions unreservedly:

• Dolibarr— France, GPLv3, free PHP and MariaDB or PostgreSQL, free self-hosting.
• Tryton— European foundation, GPLv3, free Python and PostgreSQL, free self-hosting.
• Axelor Community— France, AGPLv3, free Java OpenJDK and PostgreSQL, free self-hosting.
• Odoo Community— Belgium, LGPLv3, free Python and PostgreSQL, free self-hosting.
• ERPNext— India, GPLv3, free Python and MariaDB, free self-hosting — sovereign in the strict technical sense, subject to accepting a publisher outside the European Union.

Sovereign solutions under condition:

• Odoo Enterprise on-premisedeployed on sovereign cloud (OVHcloud, Scaleway, Outscale, NumSpot) or on private servers: sovereign in practice, with the nuance of a proprietary Enterprise license (accessible sources, non-redistributable). Odoo Online and Odoo.sh, which rely on GCP, do not meet this requirement.
• Axelor Enterpriseon sovereign infrastructure: same logic.

Solutions excluded from complete sovereignty:

• All American publishers: Oracle NetSuite, Microsoft Dynamics 365, Infor — excluded by the publisher's jurisdiction.
• SAP, IFS, Sage, Cegid, Divalto — publishers outside direct American jurisdiction (Sage is British, outside the Cloud Act), but proprietary code and most often proprietary technical stack (HANA, Oracle DB, SQL Server). Sovereignty remains partial.

In conclusion

Choosing an ERP means choosing a dependency for the next ten to fifteen years. The nature and depth of this dependency vary significantly depending on the chosen solution.

Opting for an American publisher means accepting extraterritorial exposure in exchange for undeniable product maturity, sometimes unique integration with other US tools, and a dense ecosystem.

Opting for a European proprietary publisher means reducing part of the jurisdictional risk, but retaining most of the structural risks of the proprietary model — data captivity, license audits, imposed timelines, captive price increases, dependence on the commercial strategy of a single publisher.

Choosing a European open source means gaining complete control over the software, data, and infrastructure, in exchange for a higher initial investment in skills and integration.

None of these options is universally superior to the others. The right ERP is the one that best combines the coverage of the company's business, its size, its culture, its investment capacity, its existing information system, and its level of requirement regarding sovereignty.

The goal of this comparison is not to designate a winner, but to provide a framework for choosing wisely. An organization can, with full knowledge, choose SAP for its functional depth or Microsoft Dynamics for its consistency with an already installed Office information system. The condition is that the associated risks are identified, documented, and accepted — not discovered along the way.

Choosing your ERP is choosing your dependency. You might as well know which one you are choosing.