Odoo cost of ownership and editions

What Odoo costs over its life, and why the edition decision comes first

The edition and plan you choose sets the range of options for everything that follows: where Odoo can run, whether you can write custom modules, whether you can use Odoo Studio, and how upgrades and support are handled. That makes the edition decision the first cost decision, because hosting, custom code and upgrade effort all depend on it. Odoo's pricing page lists three plans: One App Free, Standard and Custom. Only Custom can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. Confirm current per-user rates and the yearly discount on the Odoo pricing page before you build any model.

Most reviews of ownership cost start from one of four situations: choosing a plan for a new deployment, moving from spreadsheets or another ERP, a major version approaching the end of standard support, or a Community installation that now needs Enterprise features. Each one changes which costs apply. A Community database moving to Enterprise needs a subscription and module installation, and the Community edition has no access to the upgrade service. Note the date your current or planned version leaves standard support, since that date governs when upgrade work and security patching costs start.

Many organizations estimate ownership cost internally first, covering subscription fees, hosting, staff time and an upgrade every few years. They then ask a partner to validate the assumptions that are easiest to get wrong: the hosting footprint, how much custom code must be ported at each upgrade, and whether the chosen version will still be supported when you expect to upgrade. Ask any partner to show these assumptions in writing, with each one tied to a line in the quote.

What a cost-of-ownership review includes

A cost-of-ownership review turns the edition and hosting choice into a written model your finance and IT leaders can test. Each deliverable below ends with a document your team keeps, not a verdict from an auditor.

Edition and plan fit analysis

We map the apps and features your business needs against Odoo's One App Free, Standard and Custom plans, and against Community and Enterprise. The output shows which plan covers each requirement, such as on-premise hosting, Odoo.sh, Odoo Studio, multi-company or custom modules, so you see gaps before you commit to a subscription.

Hosting option comparison

We compare Odoo Online, Odoo.sh and self-hosting in your own cloud or data center against your control needs, custom code, upgrade cadence and operating effort. You receive a side-by-side table with the staff, backup and patching work each option leaves with your team and with the vendor.

Recurring cost model

We build a model of recurring costs covering subscription fees, hosting, support and upgrade effort, with each line marked as one-time or recurring. Inputs such as user counts, yearly or monthly billing and the number of major upgrades in your planning horizon are set out so you can change them and rerun the totals.

Custom and third-party module register

We list every custom module and third-party module in scope, with its owner, the Odoo features it inherits or overrides and its upgrade exposure at each major version. Modules with the highest porting effort are flagged, so the upgrade budget in the cost model reflects real code rather than a flat allowance.

Written assumptions log

We record every assumption behind the model, including user growth, plan and edition choices, the support window you plan around, data volumes and who pays for each activity. Each entry has an owner and a review date, so finance and IT can see which numbers would change the decision if they proved wrong.

What drives the cost of ownership up or down

This table lists the factors that move Odoo's recurring cost most, why each one changes the bill or the effort, and how to keep it under control.

Driver	Why it changes cost	How to keep it down
Number of users	Odoo's Standard and Custom plans are priced per user per month, so headcount with access multiplies the subscription line. Confirm current per-user prices on the Odoo pricing page before budgeting.	Grant licenses only to people who transact in Odoo, and check whether read-only or occasional users can be served by another channel.
Number of apps in use	Each additional app adds configuration, testing and upgrade scope. The One App Free plan covers a single app, and the Standard plan covers all apps, so app count also affects which plan fits.	Start with the apps that match confirmed processes and add others only with a named business owner and a use case.
Studio and custom Python modules	Studio changes and custom modules sit in your upgrade path. Custom Python modules must be ported at each major version, and Studio changes need review at each upgrade. Only the Custom plan includes Studio and custom modules.	Prefer configuration first, keep custom code small and documented, and ask any partner to price porting effort per module in the quote.
Number of companies	Multi-company is included only in the Custom plan. Each company adds master data, chart of accounts, security rules and reporting to maintain, and it increases the testing needed at upgrade.	Consolidate legal entities where the business allows, and separate companies only where accounting or legal requirements demand it.
Hosting model: Odoo.sh or on-premise	Only the Custom plan can run on Odoo.sh or on-premise. On-premise shifts infrastructure, patching, backups and monitoring to you or your provider. Extended support after standard support is limited to Odoo.sh for select versions and on-premise, so the hosting choice affects long-term support options.	Compare the internal operating effort of self-hosting against the platform fees of Odoo.sh in the same written scope, and confirm current extended support terms with Odoo before deciding.
Upgrade frequency and custom modules to port	Odoo SaaS versions are released every two to three months, and major version upgrades are mandatory every two years on Odoo Online and Odoo.sh. Standard support covers three years after a major release. Each upgrade carries testing and porting effort proportional to custom code.	Plan upgrades inside the standard support window, keep custom modules few and well tested, and budget upgrades as recurring work rather than one-time projects.
Integrations through the external API	Each integration needs authentication, data sync design, error handling, monitoring and maintenance when either system changes. Integration count drives both build effort and ongoing support.	Limit integrations to those with a clear business owner, use a single integration pattern where possible, and document data ownership for each flow.
Number of environments (production, test, staging)	Each environment needs its own hosting, database copies and maintenance. Test databases are needed for upgrades and should be tested before production. Test copies should be neutralized before use.	Keep one production environment and one shared test environment where the team can support it, and refresh test copies on a schedule rather than keeping many standing copies.

How the cost model is built

The model moves from what the business uses, to the plan and hosting that fit it, to a dated upgrade calendar and a list of assumptions the client signs off before any figure is trusted.

Inventory users, apps and features
Count named users by role, list the Odoo apps in scope and the features each team relies on, including multi-company, Studio, external API access and reporting. The output is a usage inventory that the client's operations owner signs off, because it sets every per-user and plan-level figure that follows.
Map editions and plans to the inventory
Compare the inventory against the Community and Enterprise split and the One App Free, Standard and Custom plans on the published pricing page. Record which plan allows on-premise, Odoo.sh, Studio and custom modules, since only Custom is listed for those hosting options and features. The output is a plan map signed off by the finance owner, with per-user prices confirmed as current.
Choose hosting and list its operating duties
Select Odoo Online, Odoo.sh or self-hosting and write down who runs each duty under that choice: backups, patching, PostgreSQL, reverse proxy, monitoring and recovery testing. The output is a responsibility matrix signed off by the infrastructure lead, since self-hosting shifts recurring labor and infrastructure cost to the client.
Inventory custom modules and integrations
List every custom module, third-party module and external integration, with its owner and the Odoo version it was built for. Mark each item by how much porting it will need at the next major version. The output is an exposure register signed off by the application owner, and it feeds the effort estimate for upgrades.
Build the upgrade calendar
Lay out the dates tied to the published standard support windows: Odoo 18.0 standard support runs until September 2027, Odoo 19.0 until September 2028 and Odoo 20.0 until September 2029. Add the two-year mandatory major upgrade cycle for Odoo Online and Odoo.sh. The output is a dated calendar signed off by the platform owner, showing when each recurring upgrade cost falls.
Finalize the costed assumptions register
Record each cost line with its basis, its one-time or recurring nature and the figures the client must confirm, such as subscription counts, hosting fees and partner rates. Ask the implementation partner to quote against the written scope. The output is an assumptions register signed off by the sponsor, and no total is treated as final until every open item has an owner.

Recurring costs after go-live

This table lists the costs that continue after an Odoo system goes live, showing whether each is one-time or recurring, what drives it, and what to ask a partner or vendor to quote.

Cost line	One-time or recurring	What drives it	What to ask for in a quote
Odoo subscription or plan fees	Recurring	Edition and plan (One App Free, Standard or Custom), number of users billed per month, apps in use, and whether the yearly or monthly billing option is chosen	Per-user monthly price for each plan, the yearly discount applied, what the plan includes, and whether the Enterprise subscription is required on-premise
Hosting on Odoo.sh or on-premise infrastructure	Recurring	Odoo.sh requires the Custom plan; on-premise needs your own servers or cloud accounts, storage, backups and network capacity, plus staff to run them	Odoo.sh hosting fees by tier, server and storage sizing assumptions, and whether test or staging environments are included or billed separately
Extended support where it applies	Recurring, only after standard support ends	Applies to select versions on Odoo.sh and on-premise; SaaS versions cannot use it, and security patches come only during standard support	Which versions are covered, the fee basis, the coverage end date, and whether security patches are included
Periodic upgrades and test environments	Recurring, at each major version change	Major upgrades are mandatory every two years on Odoo Online and Odoo.sh, and an upgraded test database must be tested before production; each upgrade needs a test copy and a testing window	Upgrade service fees, the number of test databases provided, testing effort assumed, and whether upgrades are fixed-scope or billed by time
Custom module porting at each version change	Recurring, at each major version change	Volume and complexity of custom Python modules, number of views and reports changed, and how far the core code has moved	Estimated porting effort per module, a rate or fixed fee per module, and what happens to modules that cannot be ported without redesign
Third-party module maintenance	Recurring	Number of third-party modules, their vendor support terms, and how often they lag behind new Odoo versions	Which modules have current versions for the target release, the vendor support terms, and who is responsible for fixes when a module breaks after an upgrade
Backups and monitoring	Recurring	Database and filestore size, backup frequency, retention period, restore testing schedule and monitoring coverage for workers and PostgreSQL	Backup frequency and retention offered, restore test frequency, monitoring scope, and the alerting and response hours covered
Internal skills: Odoo administration and Python	Recurring (staff time or retained services)	Size of the user base, number of custom modules, how often releases occur, and whether in-house staff already know Odoo and Python	Whether the partner offers ongoing administration, the staff time expected from your team, and which skills must be kept in-house for day-to-day changes

How the cost picture changes by starting point

A new buyer should choose the plan first, because the plan decides where the database can run. One App Free and Standard are Odoo Online only, so any need for on-premise or Odoo.sh hosting, Studio or custom modules points to the Custom plan from the start.

Subscription fees: Each plan carries per-user monthly prices with a yearly discount. Confirm current figures on the pricing page at quote time.
Hosting scope: One App Free and Standard run only on Odoo Online, so hosting is not a separate decision on those plans.
Implementation: Configuration, data migration and training are separate from the subscription and should be priced from a written scope.
Recurring upgrades: Odoo Online and Odoo.sh require major version upgrades every two years, so plan a recurring upgrade effort in the budget.

What usually goes wrong with Odoo cost estimates

Most Odoo budgets miss the same few items: the wrong plan or edition, upgrade obligations that recur, and custom code that costs more to carry forward than to build. Check each item against the written scope before accepting a number.

Choosing Standard for multi-company needs

Odoo's pricing page places multi-company, Odoo Studio, external API access and custom modules in the Custom plan, and only Custom can run on Odoo.sh or on-premise. An estimate built on Standard fails once a business needs a second legal entity, a no-code app or an integration. Before quoting, list every required feature and confirm which plan includes it on the current pricing page.

Assuming Community runs free for upgrades

The Community edition is open source under LGPL-3.0, but its upgrade service is not available to Community users. On-premise use of the upgrade service requires an Enterprise subscription, so a Community estimate that omits this line will understate the cost of moving to a newer version. Ask for the subscription cost as a recurring line item.

Missing mandatory upgrades on Online and Odoo.sh

On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years. Odoo Online versions also ship every two to three months and cannot use extended support. Budget a recurring upgrade cycle, including test database validation and user acceptance, rather than treating the platform as a one-time purchase.

Running a version past standard support

Standard support covers the first three years after a major release, including security updates and bug fixes. After that, extended support is the only paid route, and it is limited to Odoo.sh for select versions and to on-premise. Confirm each version's end date when you set the upgrade plan, and price the upgrade before standard support ends.

Underestimating custom module porting

Each major upgrade can require changes to custom modules, because core models, views and APIs change between versions. Estimates that cover only the first build often omit the recurring porting, testing and regression effort. Ask the partner to state how many custom modules are in scope, how each is tested, and what porting is included in the support or upgrade retainer.

What the client needs to provide

An accurate Odoo cost of ownership estimate depends on a short set of inputs from your side. Start with a user count broken down by role and by company, since Odoo's per-user pricing and the plan you need both follow from it. Pair that with the list of apps and features in scope. Odoo's pricing page limits Odoo Studio, multi-company, external API access and custom modules to the Custom plan, so the feature list alone can move you to a different plan.

Next, list the current systems and data sources that must be replaced or connected, along with any existing custom code or third-party modules. Each custom module or unvetted third-party add-on adds porting work at every upgrade, so ask your current implementer or internal developers for an inventory with owners. State your hosting preferences and any data residency constraints early, because they decide whether Odoo.sh or on-premise hosting is possible and who pays for infrastructure. Also give a target upgrade cadence. Odoo's standard support covers three years after a major release, and Odoo Online and Odoo.sh require major upgrades every two years.

Name three owners before the estimate is finalized: one for licensing decisions, one for hosting operations, and one for budget. The licensing owner confirms edition and subscription terms. The hosting owner confirms who patches, backs up and restores the system. The budget owner approves recurring subscription and hosting spend, which continues after go-live. The executive sponsor, often the CFO, COO or CIO, should approve the plan selection in writing.

Identify two or three people who know current workflows well, such as finance, sales operations and warehouse leads. They answer process questions that shape configuration versus custom module decisions. Confirm their availability in writing, since unanswered questions are a common cause of scope change. Ask DeployOpen and any other provider to price against these named inputs so the quote states the assumptions it depends on.

Frequently asked questions about Odoo cost and editions

Which Odoo plan allows on-premise or Odoo.sh hosting?

Only the Custom plan can be hosted on Odoo.sh or on-premise, according to Odoo's pricing page. The One App Free and Standard plans run on Odoo Online only. Custom is also the only plan that includes multi-company, Odoo Studio, external API access and custom modules, so an on-premise or Odoo.sh design usually starts there. Confirm the current plan contents on the Odoo pricing page before you fix a budget, because plan names and inclusions can change.

Is Odoo Community free to use for production?

The Community edition is open source under LGPL-3.0, so the software itself carries no license fee. Production use still has costs: hosting, administration, backups, patching and any implementation work. Community has no access to the upgrade service, and on-premise use of the upgrade service requires an Enterprise subscription. The Enterprise source code is not publicly available. Ask a partner to model Community and Enterprise side by side against your upgrade plan.

Do Studio and custom modules require the Custom plan?

Yes. According to Odoo's pricing page, Odoo Studio and custom modules are included only in the Custom plan. The One App Free and Standard plans do not list them. Custom modules also need an upgrade path, because each major version change may require porting code. Confirm current inclusions on the pricing page before purchase, and ask your partner to list every custom module and Studio change in the written scope.

How long does each Odoo version receive support?

Standard support covers the first three years after a major release, including security updates and bug fixes, on Odoo Online, Odoo.sh and on-premise. Per Odoo's support documentation, Odoo 19.0 (September 2025) has standard support until September 2028, and Odoo 18.0 (October 2024) until September 2027. Odoo 17.0 standard support ended in September 2026. Extended support is paid, limited to Odoo.sh for select versions and on-premise, and security patches come only during standard support. Plan the upgrade budget around that window.

What drives the total cost of Odoo ownership?

Total cost has four main parts: subscriptions or licenses, hosting, implementation and recurring support. Subscription cost scales with the plan and user count, and Odoo's pricing page lists per-user monthly prices with a yearly discount. Hosting depends on Odoo Online, Odoo.sh or your own infrastructure. Implementation cost rises with process complexity, data migration, integrations and custom code. Upgrades recur, since Odoo Online and Odoo.sh databases must move to a new major version every two years. Your team can build a rough model from the pricing page, but implementation effort is hard to estimate without process mapping.

What should a fixed-scope Odoo quote include and what must we supply?

A fixed-scope quote should list the apps and edition in scope, the hosting model, process mapping, configuration versus custom modules, data migration, integrations, training, testing, go-live support and the upgrade approach, with exclusions stated in writing. Ask for deliverables and acceptance criteria for each item. On your side, supply process owners, access to current systems, sample data for migration, a named decision-maker and time for testing. Confirm the Odoo edition and plan with your team first, because the quote depends on them.

How DeployOpen scopes Odoo cost of ownership work

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted Odoo inside your own cloud accounts, data centers or air-gapped networks. We start by mapping which edition, plan and hosting model your use case actually needs, so the cost of ownership is visible before any build begins.

How we scope

Written scope lists which apps, editions and hosting model are priced, with each assumption stated.
Scope records which Odoo features you need, such as Studio, multi-company or external API access, and which plan they require.
Scope names the recurring items: subscriptions, hosting, upgrade work and support, so you can compare totals over time.

How we build

Deployment follows the edition and hosting decision, with on-premise Enterprise activation or source installation documented step by step.
Custom modules and integrations are tested against a duplicated database with neutralized test copies before anything reaches production.
Each customization is recorded with the effort it will need to port at every major upgrade, so the upgrade cost stays predictable.

How we hand over

Handover includes a cost-of-ownership worksheet covering licenses, hosting, backups, upgrades and third-party module maintenance.
Runbooks describe the upgrade path, test database procedure and how to confirm which support window each version is in.
Documentation names every external dependency, subscription or account your team must keep active after go-live.

How we support

Ongoing support, upgrades and testing are available as a retainer, scoped in writing alongside the initial engagement.
Upgrade planning tracks Odoo's standard support dates for each version, so you know when a move is required.
Before any retainer starts, confirm with Odoo which support and subscription terms apply to your chosen edition and hosting model.