What an Odoo implementation involves
Odoo is a suite of business apps (CRM, sales, accounting, purchase, inventory, manufacturing, project, HR, website and more) on one Python framework and one PostgreSQL database. Every app is a module, and modules extend each other's models, views and logic. That design lets one system replace several, and it is why each customization costs something at every upgrade.
An implementation decides which apps to use, how your processes map onto them and where configuration is enough. The gaps become Studio changes or custom modules, integrations with systems Odoo will not replace, and a migration from the previous system. Most of the effort is design and testing.
Odoo S.A. releases a major version each year; Odoo 20.0 was released in September 2026. Each major version gets three years of standard support, with paid extended support on Odoo.sh (for a limited number of versions) and on-premise. New projects should target the current version unless a required module has not been ported yet.
Community and Enterprise: what changes in the build
Both editions run the same server code. Enterprise adds modules on top of Community and requires a subscription.
| Topic | Community | Enterprise |
|---|---|---|
| License | LGPLv3. | Odoo Enterprise Edition License v1.0. Use and modification require a subscription covering the number of users. |
| Accounting | The Invoicing app. | The full Accounting app on top of Invoicing. |
| Customization tools | Configuration and custom modules. | Adds Studio, a no-code editor for fields, models, views, reports and automations. |
| Apps | Core apps such as CRM, Sales, Purchase, Inventory, Manufacturing and Project. | Adds apps such as Helpdesk, Documents, Sign, Knowledge and Payroll. |
| Hosting | Self-hosted. | Odoo Online, Odoo.sh or self-hosted with a registered subscription. |
| Version upgrades | Your team or an implementer, for example with the OCA's OpenUpgrade scripts. | Odoo's upgrade service covers standard apps and Studio changes. Custom modules are the maintainer's job unless a maintenance of customizations subscription covers them. |
From process map to go-live
Walk through quote to cash, procure to pay, stock, manufacturing and month-end close with the people who run them. Record volumes, exceptions, approval rules, required reports and connected systems. Settle company structure, currencies and fiscal localization early, because they shape the chart of accounts.
Run standard apps against each process in a test database and classify every gap: change the process, configure, use an OCA or vendor module, use Studio, or write a custom module. Each custom item gets an owner, an estimate and an upgrade impact note.
Custom modules live in Git with automated tests and code review. Settings, reference data and access groups go into data files or scripts so the same setup replays into staging and production.
Test complete flows with users from each department on migrated data: integrations, scheduled actions, printed documents, access rights and month-end reports. Use a neutralized copy of production, with scheduled actions off and outgoing mail captured.
Freeze master data, load open items and opening balances, reconcile with finance, then move users over. Train key users first, publish short process guides and keep close support through the first weeks.
Configuration, Studio or a custom module
Use the lightest tool that meets each requirement. Each step toward code adds flexibility and upgrade work.
Settings and configuration
Fiscal positions, routes, approval settings, automation rules and server actions cover many needs without code. They are stored as data and move with the database at upgrade time.
Studio (Enterprise)
Adds fields, models, views, reports and automations through the interface. Odoo's upgrade service covers Studio changes while Studio stays subscribed, but they are harder to review and version than code, so agree who may use Studio in production.
Custom modules
Python models on the ORM, inherited XML views, access and record rules, QWeb reports and OWL components. Keep inherited changes small and avoid overriding core methods. Every module is ported and retested for each major version.
OCA and third-party modules
The Odoo Community Association maintains open-source modules by version branch. Check the module exists for your target version, read the license in its manifest (many are AGPL-3), and treat it as code you maintain.
Integrations to design
Odoo 19.0 added the External JSON-2 API, which uses API keys as bearer tokens. XML-RPC and JSON-RPC are deprecated, with removal of their remaining services scheduled for Odoo 22 (fall 2028), so new integrations should use JSON-2.
| System | Common approach | Design point |
|---|---|---|
| Banks and payment providers | Statement imports or bank synchronization where your bank and edition support it, plus payment provider modules. | Agree who reconciles and how unmatched lines are handled. |
| E-commerce | Odoo eCommerce, or a connector to an external shop. | Decide which system owns products, prices and stock. |
| Identity provider | auth_oauth and auth_ldap from the standard modules; OCA modules add OpenID Connect and SAML. | Decide how users are provisioned into Odoo access groups and how leavers are deactivated. |
| Other business systems | JSON-2 calls from dedicated integration users, or EDI files handled by a custom module. | API keys last at most three months, so automate rotation and alert before expiry. |
Data migration and version upgrades
Migrations usually come from an older ERP or accounting package, spreadsheets or an earlier Odoo version. Move master data (customers, vendors, products, bills of materials, chart of accounts) and open items (unpaid invoices, open orders, stock on hand) with opening balances, and archive closed history. The import tool reads CSV and Excel files with external IDs, so repeated loads stay consistent. Rehearse on a copy and reconcile each run with finance: trial balance, aged receivables and payables, stock valuation.
A major upgrade changes the schema and the framework APIs custom code relies on. For Enterprise, Odoo's upgrade service migrates the database and provides test databases to validate flows, integrations and reports first. A database with custom modules cannot be upgraded until those modules exist for the target release, and Odoo states that this is the maintainer's responsibility. Community databases move with OpenUpgrade or custom scripts. Treat major upgrades as a recurring, budgeted project.
Hosting, access and hardening
Odoo's SaaS. Odoo's pricing page describes the Standard plan as hosted on Odoo Online without custom modules, so it suits projects that stay within configuration and Studio.
Odoo's platform for Enterprise with custom code. It builds Git branches into development, staging and production environments with SSH access and continuous integration.
Community, or Enterprise with each database registered against the subscription. Run multiple workers behind a reverse proxy, PostgreSQL on its own host or a managed service, and the filestore on persistent storage. Back up database and filestore together and test restores.
Serve Odoo over HTTPS with proxy_mode enabled. Use dbfilter and set list_db to False to hide the database manager, give admin_passwd a long random value, and connect with a PostgreSQL user that is not a superuser. Rate-limit logins at the proxy and turn on two-factor authentication or passkeys.
Odoo operating ownership
An ERP touches finance, operations and IT at once. Each part needs a named owner after go-live.
Platform
- Run Odoo workers, PostgreSQL, the filestore and the proxy.
- Apply minor updates and security fixes on a tested schedule.
- Monitor memory, slow requests, scheduled actions and database growth.
Functional owners
- Own configuration for each app.
- Approve changes to access groups, approvals and reports.
- Keep process guides current.
Development
- Maintain custom modules in Git with tests and review.
- Track OCA and third-party module versions and licenses.
- Port modules ahead of each major upgrade.
Security and compliance
- Review administrators, integration users and API keys.
- Define which changes are logged and reviewed.
- Keep evidence of access reviews, backups and change approvals.
Odoo implementation questions
Can we start on Community and move to Enterprise later?
Yes. Enterprise adds modules on the same server code, and Odoo documents the switch. Its upgrade service does not cover changing editions, so plan the switch separately and test it on a copy.
Should we use Studio or custom modules?
Studio suits fields, views, simple automations and reports that business administrators maintain. Custom modules suit logic that needs tests, version control, integrations or complex calculations. Many projects use both, with written rules for which change goes where.
Can Odoo support SOC 2 or ISO 27001 readiness?
Odoo provides access groups, record rules, tracked field changes and two-factor authentication. DeployOpen reviews the access model, hosting and change process, runs security testing and helps prepare evidence for SOC 2, ISO 27001, DORA or NIS2 readiness. It does not issue audit reports or certifications.
Scope and handover
Effort depends on the number of apps and companies, the localization, custom modules and integrations, source data quality, the number of users to train and the hosting choice. Custom development and data migration usually shape the plan more than installation.
DeployOpen runs discovery and fit-gap, configures Odoo, builds and tests custom modules, integrates SSO and other systems, migrates data, deploys and hardens self-hosted or Odoo.sh environments, trains key users and supports go-live. Handover includes the process map, fit-gap decisions, module repository, integration specifications, migration scripts and reconciliation records, access group matrix, restore test results and an upgrade plan.
