Self-hosted ERP for EU data sovereignty

Why self-hosted ERP for EU data sovereignty starts with where the data is processed

A finance or HR leader who must keep ledgers, payroll-related files and employee records on EU infrastructure usually inherits a question that the license alone cannot answer: where the data sits and who can reach it. For this decision, the hosting model and the vendor's access paths decide compliance, not the open-source license. The same Odoo or ERPNext code can be compliant in one deployment and non-compliant in another, depending on where the database, backups, logs and support sessions live. Under GDPR, EDPB Guidelines 05/2021 treat remote access from a third country, even just displaying data on a screen for support, as a transfer, so the vendor's support model belongs in the assessment from the start.

The short answer is that Odoo Enterprise on-premise or a self-hosted ERPNext site inside an EU tenant are the two main routes that keep control of location and access with the customer. Odoo Enterprise on-premise requires an Enterprise subscription, and the Enterprise source is not publicly available, so the team must confirm that subscription terms and any update channels meet its requirements. A self-hosted ERPNext site inside an EU cloud account or data center keeps the database and files under the customer's control, but the team must still confirm where backups, Frappe Cloud support plans and any managed components are located if they are used. Odoo Online can be considered only after the vendor confirms in writing the storage region, backup location, sub-processors and the circumstances under which Odoo staff can access customer data.

Before choosing a route, ask four questions of each candidate: where the production database, file storage and backups are physically located; which staff and sub-processors can view or copy data, and from which countries; whether support sessions can be run without exposing personal data; and how a third-country authority request would be handled. The EDPB notes that complying with such a request is itself a transfer, so the controller should assess that exposure before engaging a processor. Record the answers in the transfer impact assessment and in the processor agreement, because they will be the first items a data protection authority or auditor asks for.

Which requirements shape a sovereign ERP build

This table maps the legal and regulatory requirements that affect where an ERP runs, who can reach it and how long records stay available, with the source of each rule and what it means for the build. Read it as a checklist to confirm with your counsel and assessors, since the FTC and SEC rows apply only if your organization is in scope. The main takeaway is that remote support access and cloud storage can create transfers even when the data sits in an EU region.

Requirement	Source	What it means for the build
Transfers include remote support access and storage outside the EEA	GDPR Chapter V and Article 44; EDPB Guidelines 05/2021 (version 2.0)	Map every vendor, partner and support session that can view ERP data from a third country, and treat screen display as a transfer. Confirm the hosting region for backups and logs too.
Fines for unlawful transfers	GDPR Article 83(5)(c)	Infringements of Articles 44 to 49 can reach EUR 20 million or 4% of worldwide annual turnover, so transfer mapping belongs in the design phase, not after go-live.
Exposure to third-country authority requests	EDPB Recommendations 01/2020; GDPR Article 48; 18 U.S.C. 2713	Assess whether any US-parented processor could be compelled to disclose data, since a compliance with such a request may itself be a transfer. Confirm the contractual and technical position with counsel.
Adequacy depends on a pending decision	Implementing Decision (EU) 2023/1795; Case C-703/25 P	Relying on the Data Privacy Framework for a US vendor depends on a pending appeal. Confirm the current status before choosing that route.
Multi-factor authentication and encryption	16 CFR 314.4 (FTC Safeguards Rule, if in scope)	Require MFA for every ERP user, encrypt data in transit over external networks and at rest, and confirm these settings in each environment including test copies.
Change management and activity logging	16 CFR 314.4 (FTC Safeguards Rule, if in scope)	Route configuration and code changes through approval and testing, and log authorized user activity in the ERP and its hosting layer.
Penetration testing and vulnerability assessments	16 CFR 314.4(d)(2) (FTC Safeguards Rule, if in scope)	Without effective continuous monitoring, plan penetration testing and vulnerability assessments at least every six months, including the ERP and its integrations.
Three-year record retention, first two years accessible	17 CFR 240.17a-4(b) (SEC Rule 17a-4, if in scope)	Broker-dealers must keep bills, bank statements and business communications for three years, with the first two easily accessible. Size storage and archive retrieval for this window.
Switching to on-premises infrastructure	EU Data Act, Articles 25, 29 and 50 (Regulation (EU) 2023/2854)	Customers may move from a data processing service to on-premises infrastructure with a notice period and transition period. Keep exports and data formats portable so a self-hosted target stays possible.
Prevention of third-country access to non-personal data	EU Data Act, Article 32	Providers must take measures against conflicting third-country access to non-personal data held in the Union. Ask hosting providers how they meet this obligation in writing.

How a US-hosted ERP creates transfer and government access exposure

A US-hosted ERP can create a transfer of personal data under GDPR even when no one copies a file out of the EEA. The EDPB's Guidelines 05/2021 state that remote access from a third country is a transfer, even when the person only displays data on a screen for vendor support or administration. Storage in a cloud outside the EEA is also a transfer. For a finance or HR team, this means a support engineer in another country opening the general ledger, payroll records or employee files is part of the transfer analysis, not only the hosting location. Before engaging any hosting provider, support partner or processor, ask for a written list of every location from which data can be stored, viewed or administered, and record which Chapter V transfer mechanism covers each one. Article 44 applies to onward transfers as well, so the subprocessor chain matters.

The larger exposure is government access. The CLOUD Act provision at 18 U.S.C. 2713 requires providers of electronic communication and remote computing services to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. A European subsidiary of a US provider, or a US provider's EU region, can therefore receive a US order for data it controls. GDPR Article 48 limits how such an order is treated in the EU: a third-country judgment or decision requiring disclosure is recognized or enforced only if it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. The EU-US Data Privacy Framework adequacy decision, Commission Implementing Decision (EU) 2023/1795, covers only organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending. Confirm the current status of that appeal and of your provider's certification with counsel before relying on it.

Where the provider needs data in the clear, EDPB Recommendations 01/2020 state that the EDPB cannot envision an effective technical supplementary measure if the destination's public authority powers go beyond what is necessary and proportionate. Encryption with keys held by the provider does not close this gap for a hosted ERP that processes records in plain form. Treat the assessment as a decision with three outputs: whether the provider can be excluded, whether a self-hosted deployment in your own EU infrastructure removes the provider from the access chain, and what contractual and organizational measures remain. Run the same analysis for non-personal ledger and inventory data under Article 32 of the Data Act (Regulation (EU) 2023/2854), which requires providers to take measures against conflicting third-country governmental access to non-personal data held in the Union. That duty is a parallel obligation, so a transfer assessment for personal data does not settle it.

Which open source ERP fits a sovereignty mandate

Sovereignty depends less on the license than on where the software runs, who can reach the data, and who supports it. The four options below differ mainly in hosting control, upgrade obligations and the vendor access paths that must be confirmed before any personal or financial data moves onto them.

Odoo Enterprise on-premise (Custom plan)

Odoo Enterprise is built on the LGPL-3.0 Community core, and only the Custom plan can be hosted on-premise or on Odoo.sh. Only Custom includes multi-company, Studio, external API access and custom modules, so a plan that fits a sovereignty mandate may also be the one that carries the highest subscription cost. On-premise upgrades use the Enterprise upgrade service, so confirm whether upgrade databases are processed inside your environment and whether support engineers can view production data during tickets.

Odoo Community, self-built

Odoo Community is licensed under LGPL-3.0 and gives full control over the deployment, but it has no access to the upgrade service and no Enterprise features such as the mobile apps. Your team carries every major version upgrade, security patch and custom module migration, and standard support is tied to the vendor's release cycle. Confirm internally who owns patching and whether your staff can run upgrades on a timeline that keeps a supported version in place.

ERPNext self-hosted

ERPNext is licensed under GPL-3.0 and runs on the Frappe Framework, which is licensed under MIT, so the full stack can be deployed with Docker Compose or the bench tool inside your own network. Frappe's warranty coverage requires a listed version and a matching Frappe Cloud support plan, which means self-hosted deployments rely on in-house or partner support. Confirm which Frappe version you will standardize on, since version 14 has already reached end of life, and plan for the Server Script setting if you need custom logic.

Odoo Online as a conditional option

Odoo Online is hosted by the vendor and is only available on its SaaS plans, with releases every two to three months and no extended support. It can only be considered for personal or financial data if the hosting location, sub-processors and access by vendor staff meet your transfer assessment, and the Odoo Online plans do not include the features that a multi-entity or custom-module setup usually needs. Confirm the data location of hosted services and support access paths in writing before any data is loaded.

Hosting options compared for Odoo and ERPNext

Odoo Online is the software-as-a-service option, where Odoo operates the application and hosts the database on infrastructure the vendor manages. Your organization does not control the server, patch cadence or maintenance windows in the way it would with a self-hosted system. The Odoo pricing page limits the Odoo Online plans to the free one-app plan and the Standard plan, and it reserves multi-company, Odoo Studio, external API access and custom modules for the Custom plan.

Operator: Odoo runs the hosting, backups and upgrades. Your team and any partner work inside the application layer.
Release cadence: Odoo SaaS versions are released every two to three months and cannot use extended support, so every major version change arrives on the vendor's schedule.
Support lifecycle: Standard support covers three years after a major release, and the paid extended support options do not apply to Odoo Online.
Data location: The hosting region, backup location and sub-processors are set by the vendor's contract, not by your team.
Administrative access: Confirm in writing which vendor staff can access the database, under what circumstances, and how remote support sessions are logged.

Before you rely on Odoo Online for sovereignty, get the hosting region, backup location, sub-processor list and remote support access rules in writing from Odoo's contract documents.

How the sovereign ERP rollout runs in phases

The sequence moves from knowing where personal data flows to a documented, tested cutover that retires the US-hosted instance, with each phase producing evidence the next one depends on.

Map data flows and transfer exposure
Your team and the DeployOpen architects list every place financial and employee data sits or is viewed today, including the US vendor's support access, backups, logs, add-ons and any integrated SaaS tools. Each flow is tagged by data category, legal entity and whether a third-country party can reach it, including remote access that only displays data. The step closes with a signed data map and a transfer register that the data protection lead approves. If a flow is not on the map, it is not in scope for the rollout, so reviewers should challenge gaps before moving on.
Decide hosting and lock the contract terms
Choose the hosting model, such as your own EU data center, a European cloud account you control, or a European provider, and assess whether any processor is subject to third-country law with extraterritorial reach. Under EDPB Guidelines 05/2021, that exposure has to be assessed before engaging the processor, and the assessment should cover how a third-country authority request would be handled. Negotiate written terms covering processing location, support access from outside the EEA, sub-processors, notification of government requests and exit assistance. The output is a signed hosting scope and a decision record that names what is excluded. Ask your legal counsel to confirm the transfer tools that still apply.
Build the environments and wire identity
DeployOpen builds the production, test and restore environments inside the agreed hosting scope, using the chosen platform route (Odoo on-premise Enterprise or Odoo.sh, or ERPNext via Docker Compose or bench). Odoo LDAP authentication and ERPNext LDAP integration connect the ERP to your directory so that joiners, movers and leavers are handled centrally. Confirm which edition and plan support on-premise hosting and LDAP before the build starts, since the Odoo plans differ. The output is a documented environment inventory, a working identity connection tested with sample accounts, and a restore from a backup that has been checked end to end.
Migrate data in planned batches
Migration runs in trial loads that move master data first, then open balances and a bounded amount of history, with reconciliation at each stage. The ERPNext Data Import tool is documented for importing only a few thousand records at a time, so bulk datasets such as employee records or ledger lines must be split into batches sized to that limit and loaded in a planned order. Finance and HR sign off the reconciled totals and personnel counts for each trial. The output is a batch plan, reconciliation reports for each trial load and a signed sign-off record. Ask your partner to show how batch sizes are set for Odoo and ERPNext in your own data volume.
Configure access, segregation and logging
Role design follows the data map, so payroll, bank details and personnel files are restricted to named roles, and administrative and server-side scripting rights are granted narrowly. Server Scripts in ERPNext are disabled by default from version 15 and must be enabled deliberately, so the decision to enable them is recorded and reviewed. Audit logging covers logins, privileged changes and data exports, and logs are forwarded to a store your security team controls inside the agreed EU hosting scope. The output is a role matrix, a logging configuration and a test showing that a user outside a role cannot see restricted records.
Test penetration and vulnerabilities
Security testing covers the application, the hosting layer, the identity integration and the backup path. Where continuous monitoring is not in place, the FTC Safeguards Rule at 16 CFR 314.4(d)(2) calls for penetration testing and vulnerability assessments at least every six months, so the test schedule should be set against that requirement if your organization is a covered financial institution. Findings are triaged with owners and fix dates, and retests confirm closure. The output is a penetration test report, a vulnerability register and a retest record. Remediation of high-severity findings should complete before cutover.
Cut over and retire the US-hosted instance
Cutover is scheduled at a period boundary agreed with finance, with a freeze on the source system, a final delta load, reconciliation sign-off and a rollback plan tested on the restore environment. Users are moved to the EU instance and the legacy access paths are closed. Retirement follows only after the retention obligations for the old records are mapped, since rules such as SEC Rule 17a-4(b) can require certain records to remain preserved for a set period for broker-dealers. Vendor access, licenses, backups and integrations are removed in writing. The output is a cutover runbook with sign-offs, a decommissioning record confirming deletion or archive of US-hosted data, and a written confirmation from the vendor where applicable.

Evidence a regulator or auditor will ask for

This table maps each piece of evidence a data protection authority, auditor or assessor is likely to request to the requirement it supports and the system component that produces it. Read it as a checklist to agree with your ERP partner before go-live. DeployOpen prepares this evidence, but independent auditors, certification bodies and data protection authorities decide any assessment outcome.

Evidence item	Requirement it supports	Component that produces it
Data location and transfer map	GDPR Article 44 transfer conditions, including onward transfers	Infrastructure inventory, database and backup locations, and a documented list of every remote access path from outside the EEA
Hosting and sub-processor contract terms	Article 28 processor terms and Chapter V transfer mechanisms	Hosting agreements, sub-processor register, and the signed standard contractual clauses where any third-country party is involved
Third-country authority exposure assessment	Transfer impact assessment expected under EDPB Recommendations 01/2020	Written assessment of the hosting provider's legal exposure to foreign government access requests, kept with the transfer map
Admin and support access logs	Access control and logging of privileged activity under the GDPR security principle	Operating system and PostgreSQL audit logs, Odoo or ERPNext user activity records, and records of each vendor support session
MFA and encryption configuration	Strong authentication and encryption of personal and financial data in transit and at rest	Identity provider settings for LDAP or social login, TLS certificate and cipher configuration, and disk or database encryption settings
Change records for configuration and custom modules	Change management over system configuration and code that processes employee and financial data	Version control history, approval tickets, test records for each release, and logs of server script or parameter changes
Restore test results	Availability and integrity of personal data, and the ability to restore it after an incident	Dated restore tests from encrypted backups stored inside the EU, with reconciliation results for a sample of financial records
Penetration test and vulnerability assessment reports	Regular testing of safeguards for systems holding customer financial information	Independent test reports, scan outputs, remediation tracking and retest evidence for the ERP and its hosting layer
Retention settings for financial and HR records	Statutory retention periods for accounting records and employee data minimization	Configured retention rules, archive policy, documented deletion runs and a log of records removed after the retention period

What to ask an implementation partner about sovereignty

Start with location and access, because most sovereignty failures come from a copy of data or a login that sits outside the EU without anyone recording it. Ask the partner to list, for each production database, file store, backup target, log pipeline and monitoring tool, the country and provider where it lives, and whether any replica or snapshot leaves the EU. Then ask who can reach production from outside the EU, through which path (VPN, bastion, vendor support tunnel), and where that access is logged and for how long those logs are kept. Remote screen sharing counts as a transfer under EDPB Guidelines 05/2021, so ask whether support sessions that display customer or payroll records are allowed from third countries at all. Ask how each remote support grant is approved, time-limited and revoked, and who holds the revocation right when the client's own team is unavailable.

Next, ask for the full sub-processor chain and for the partner's own plan for a third-country authority request. Each hosting provider, managed database service, email relay, monitoring vendor and backup vendor should appear on a named list with its location and contract terms. Ask how the partner would respond to a request from a non-EU public authority: whether it would notify the client, challenge the request, and minimize what it discloses. Under GDPR Article 48, a foreign judgment is enforceable only where an international agreement such as a mutual legal assistance treaty applies, so the answer should reference that framework. Ask who signs the transfer impact analysis, who owns it after go-live, and whether the client's data protection officer reviews it before production use.

Then test the platform choice itself. Ask which Odoo edition and plan the partner recommends. Only the Custom plan can be hosted on Odoo.sh or on premise, and only the Custom plan includes multi-company, Studio, external API access and custom modules, so confirm this against current pricing before the quote. For ERPNext, confirm that the deployment runs on the client's own servers and not Frappe Cloud. Ask how upgrades reach an air-gapped or isolated environment without vendor access, and whether the partner tests each patch in a copy first. Ask how custom code stays upgradable: whether it lives in a separate app rather than edits to core, and whether Server Scripts are enabled. From version 15 they are disabled by default through server_script_enabled, and Frappe Cloud public shared benches do not allow them, so the answer determines where business logic can run.

What buyers ask before a sovereign ERP project

What drives the cost of self-hosting an open-source ERP?

Cost comes from five places: infrastructure in your own cloud account or data center, the hosting plan you choose, licences or subscriptions, the one-time migration and configuration work, and recurring security testing and upgrades. Self-hosting ERPNext has no license fee, and the ERPNext pricing page lists Frappe Cloud hosting from 5 US dollars per month for shared sites, but that is a managed option you may not need for sovereignty. For Odoo, the Enterprise edition needs a subscription, and only the Custom plan can run on Odoo.sh or on-premise, so confirm the plan with Odoo before you budget. Ask any implementer for a quote that separates one-time work (fit-gap, migration, hardening) from recurring work (upgrades, patching, support), and ask who pays for each line.

How long does a sovereign ERP rollout take?

Length depends on scope more than on the software: the number of legal entities, modules in scope, how much history must move, the number of integrations with banks, HR and identity systems, and how many localization rules apply. Migration is often the longest phase because opening balances and open items must be reconciled before cutover. ERPNext's Data Import tool advises importing only a few thousand records at a time, so large histories need batching and several trial loads. Ask for a written plan with phases, sign-off points and the dependencies on your internal teams, and treat any duration without a stated scope as an estimate to challenge.

What does our internal team need to provide?

An ERP project needs named people, not just budget. Data owners must confirm which records are authoritative and sign off on reconciliation. Decision makers must settle process design, chart of accounts and customization limits before build starts. Identity staff must supply the directory and single sign-on design, since Odoo and ERPNext both document LDAP integration and social login options. Network staff must allocate hosting, certificates, backups and firewall rules inside your boundary. Finance and HR leads should also plan user acceptance testing time, because that is where most defects surface. Agree these roles in the statement of work.

Can our team run a self-hosted ERP without a partner?

It is possible if you already operate Linux, PostgreSQL or MariaDB, reverse proxies and backup systems, and you have finance staff who can own configuration. The harder parts are upgrades, custom module maintenance and security patching. Odoo's standard support covers three years after a major release for on-premise use, and Odoo.sh and on-premise need an Enterprise subscription to use the upgrade service, while the Community edition has no access to it. Frappe's policy says warranty coverage requires a listed version and a matching support plan. Decide which of these you will carry in-house, and confirm the vendor terms before committing.

Does Odoo Online meet an EU data sovereignty requirement?

Odoo Online may not, so verify it against your own data map before relying on it. Sovereignty depends on where data is stored, who can administer it, and whether any remote access or support session shows personal data from a third country. The EDPB guidelines treat remote access from a third country, even only displaying data, as a transfer, and storage in a cloud outside the EEA as a transfer too. Odoo Online is hosted by the vendor, so ask Odoo in writing where each database is stored, which sub-processors touch it, and how support access works. Odoo.sh or on-premise Enterprise in your own infrastructure gives you more control, but only the Custom plan allows that hosting.

Does moving off a US-hosted ERP trigger Data Act switching rights?

The Data Act gives customers of data processing services the right to switch to another provider or to on-premises infrastructure, and it applies since 12 September 2025. Under Articles 25, 29 and 50 of Regulation (EU) 2023/2854, the maximum notice period is two months, the transition period is 30 days, and switching charges are banned from 12 January 2027. Whether your current contract qualifies depends on whether it is a data processing service under the Act, so have counsel review the contract and the exit terms. Also confirm with your current vendor how they will export data in a usable format, since the right to switch does not remove the need to plan the migration.

What security testing should a sovereign ERP receive?

Test the ERP as a system, not only the application code. Scope should cover the web and API layer, the database and backup paths, authentication flows, custom modules and the hosting platform. For financial systems, the FTC Safeguards Rule at 16 CFR 314.4 requires penetration testing and vulnerability assessments at least every six months where continuous monitoring is not in place, along with encryption, multi-factor authentication and activity logging. Ask your implementer for a written test plan, the retest process after findings, and how results feed your compliance evidence. DeployOpen runs application, infrastructure and API security testing, but the scope and frequency should be agreed in writing for your environment.

How DeployOpen scopes and runs a sovereign ERP build

DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source ERP inside the client's own infrastructure. For EU data sovereignty work, we start by mapping where personal and financial data live, who can reach it, and which transfers and foreign access paths must be closed before any platform is installed.

How we scope

We map every system, database, backup and support access path that touches employee and financial data in the ERP.
Scope is agreed in writing before work starts, with deliverables, timelines and exclusions stated for each module.
We record which Odoo edition, plan or ERPNext deployment model is in scope, including hosting location and support access.

How we build

We install and configure the platform inside your cloud accounts, data centers or private networks, with EU-located storage and backups.
We set up identity integration, role-based access, audit logging and encrypted connections as defined in the agreed scope.
We test migrations and integrations in staging copies, including neutralized test databases, before any production cutover.

How we hand over

You receive configuration records, architecture documentation, access matrices and the data flow map for review by your DPO and auditors.
We document upgrade procedures, backup and restore steps, and the controls that support your GDPR transfer and records assessments.
Knowledge transfer sessions cover administration, change approval and the steps your team runs without us.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Upgrade work is planned against the vendor's support windows and tested on a copy before production.
Retainers can cover periodic penetration testing and vulnerability assessment of the ERP environment, scoped with your team.

Self-hosted ERP for EU data sovereignty

Why self-hosted ERP for EU data sovereignty starts with where the data is processed

Which requirements shape a sovereign ERP build

How a US-hosted ERP creates transfer and government access exposure

Which open source ERP fits a sovereignty mandate

Odoo Enterprise on-premise (Custom plan)

Odoo Community, self-built

ERPNext self-hosted

Odoo Online as a conditional option

Hosting options compared for Odoo and ERPNext

How the sovereign ERP rollout runs in phases

Map data flows and transfer exposure

Decide hosting and lock the contract terms

Build the environments and wire identity

Migrate data in planned batches

Configure access, segregation and logging

Test penetration and vulnerabilities

Cut over and retire the US-hosted instance