Which open-source ERP support window fits your upgrade calendar
A team that must keep a self-hosted ERP patched while protecting finance close and audit periods needs to know how often the platform forces a version change. The support window sets that upgrade rhythm, and whether the platform offers long-term support decides how much of the upgrade work can be scheduled months ahead instead of reacted to. Odoo fits teams that can absorb a major upgrade roughly every three years. Odoo gives standard support with security updates for three years after a major release, and security updates stop when standard support ends, so an on-premise deployment that falls behind loses patches. Confirm whether your Odoo edition and hosting model qualify for the paid extended support the vendor describes for on-premise use, and budget for the Enterprise upgrade service if you plan to use it.
Tryton fits teams that want a long-term stability line but are willing to move through series more often. Per the Tryton download page, each series is supported for one year, releases come every six months, and each new major series gets five years of long-term support. That means a team on an LTS series can stay put for years, while a team on an interim series must move within a year. Before committing, confirm with the Tryton project which series will carry LTS status when your planned go-live falls, and check that your customizations and third-party modules are tested against that series. iDempiere fits teams that value its LTS line and a Java stack. The project published iDempiere 13 "Orion" as an LTS release in March 2026, and the repository keeps release branches for each major version. Ask your implementation partner to confirm the end-of-support date for the LTS branch you choose, and plan your Java and PostgreSQL or Oracle upgrades alongside it.
Which support model suits which upgrade situation
This table matches common upgrade situations to the support model that fits each one, based on the published support windows for Odoo, Tryton, ERPNext and iDempiere. Read each row against your own release cadence and in-house capacity, and treat the open questions on iDempiere and Dolibarr support durations as items to confirm before you commit.
| Scenario | Best fit | Why |
|---|---|---|
| Fewer major upgrades | Odoo on-premise Enterprise or Odoo.sh Custom, or a long-lived LTS line | Odoo standard support runs three years after each major release, so a major version can serve about three years before you must move. Confirm the exact paid extended support terms with Odoo before relying on them. |
| Patch quickly and often | Tryton on the current series, or ERPNext on a supported v16 or v15 line | Tryton publishes a new series every six months and supports each for one year, so you apply security fixes by staying within the current series. Odoo security updates stop at the end of standard support, so plan to upgrade before then. |
| Managed SaaS or Odoo.sh schedule | Odoo Online or Odoo.sh with the vendor's upgrade cadence | Odoo SaaS versions ship every two to three months and cannot use extended support, and major upgrades are mandatory every two years on Odoo Online and Odoo.sh. Budget for recurring test cycles on the upgraded test database. |
| In-house developers who can absorb frequent series | Tryton, with one upgrade per series managed by your own team | Tryton's six-month series cadence means frequent but smaller changes, which suits a team that tests and ships its own modules. Factor in the internal time for regression testing on each series. |
| Long-lived LTS line | iDempiere 13 Orion LTS, or Tryton LTS releases for teams that want five-year windows | Tryton publishes five-year LTS releases, and iDempiere 13 Orion is announced as LTS. Confirm iDempiere's support duration with the project, and confirm the Tryton LTS dates on the download page for the release you choose. |
| Dolibarr or iDempiere support duration unknown | Decide only after confirming published support windows | The supplied facts show current Dolibarr releases and maintenance on older lines, but no fixed support duration. Ask the Dolibarr Association and the iDempiere project for written support periods before you plan upgrade budgets. |
How long each open-source ERP version stays supported
Support windows decide how often you must upgrade, and each upgrade costs testing time and budget. The five platforms here use different models: fixed standard support windows, short series with long-term releases, and version lines that keep receiving maintenance releases. Check each window against your own upgrade calendar before you commit.
Odoo support window and license
Odoo Community is licensed under LGPL-3.0, while Odoo Enterprise is proprietary and not open source. It requires a valid Enterprise subscription that matches your user count. Standard support covers three years after each major release, with security updates and bug fixes only during that period. Paid extended support is limited to on-premise and selected Odoo.sh versions, so plan a major upgrade roughly every three years. Confirm which extended support terms apply to your hosting model before you sign.
Tryton series and LTS releases
Tryton releases a new series every six months, and each series is supported for one year. Each new major series also receives long-term support for five years, which gives a slower upgrade path than the bi-annual series. The server, trytond, is licensed GPL-3.0-or-later. The latest announced release in the supplied facts is 8.2, announced October 6, 2026. Choose the LTS series for stable production, and confirm the exact LTS series and its end date on the download page before planning.
iDempiere LTS release 13
iDempiere is licensed under GPL-2.0 and is community-driven, so support depends on the project and its implementers. Release 13 "Orion" is documented as a long-term support release, announced March 12, 2026. The repository keeps release branches from release-9 through release-13. Confirm with the project how long release 13 will receive fixes, and whether your implementation partner will maintain it after that date. Budget for the upgrade path before the window closes.
ERPNext supported version lines
ERPNext is licensed under GPL-3.0 and runs on the Frappe Framework. Version 16 was released January 12, 2026, and receives releases through 16.51.1 on October 15, 2026. The v15 line, first released October 20, 2023, still received v15.123.0 on October 14, 2026. Both lines remain in active maintenance, but the project does not publish end-of-life dates in the supplied facts. Ask the project or your partner for the end-of-life policy before choosing a line, and factor in the Frappe Framework v16 requirements such as Python 3.14 and Node.js 24.
Dolibarr maintained release lines
Dolibarr is GPL-3.0 licensed and backed by the Dolibarr Association. Version 24.0.0 was released August 20, 2026, and 24.0.1 followed on September 7, 2026. Older lines such as 23.0 and 22.0 still received maintenance releases in 2026. The supplied facts do not give end-of-life dates for these lines, so ask the association which lines it will maintain and for how long. Plan upgrades on the newest line when your modules allow, since add-on modules from the DoliStore marketplace may lag behind core releases.
Support window, LTS and upgrade terms across the options
This table sets out each option's license, release or support cadence, long-term support offer, upgrade service access and the database and runtime floors stated in its documentation. Cells marked to confirm are open questions for the vendor or community before you size an upgrade budget. The main takeaway: Odoo and Tryton state their windows most clearly, so confirm equivalent terms for the other options before committing an upgrade budget.
| Option | License and release cadence | LTS and support window | Upgrade service and runtime requirements |
|---|---|---|---|
| Odoo Community | LGPL-3.0. Major versions: 18 (October 2024), 19 (September 2025), 20 (September 2026). | No LTS track. Three years of standard support with security fixes only during it. Paid extended support is for on-premise. | No access to the upgrade service. Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or later. |
| Odoo Enterprise (proprietary) | Proprietary Odoo Enterprise Edition License v1.0. Subscription must match user count. | No LTS track. Same three-year standard support as Community. Paid extended support is for on-premise. | Upgrade service for on-premise use requires an Enterprise subscription. Same Odoo 19 Python and PostgreSQL floors. |
| Tryton | trytond under GPL-3.0-or-later. New series every six months, each supported for one year. | Each new major series receives five-year LTS. Confirm which series carries LTS at adoption. | Confirm upgrade assistance with the project. Requires Python 3.10 or later; PostgreSQL or SQLite. |
| iDempiere | GPL-2.0. Release branches kept for each major version, from release-9 through release-13. | iDempiere 13 'Orion' is an LTS release, announced March 12, 2026. Confirm its support length. | Confirm upgrade path and service with the community. Runs on PostgreSQL or Oracle; confirm the Java version. |
| ERPNext on Frappe | ERPNext under GPL-3.0; Frappe Framework under MIT. v16.0.0 January 2026, v16.51.1 October 2026. | No LTS label in the sources reviewed. The v15 line still received v15.123.0 in October 2026. Confirm the published window. | Frappe Cloud handles upgrades; confirm self-hosted upgrade steps. v16 needs MariaDB 11.8, Redis or Valkey 6 or later, Python 3.14, Node.js 24. |
| Dolibarr | GPL-3.0. Releases 24.0.0 (August 2026) and 24.0.1 (September 2026). | No LTS label in the sources reviewed. Lines 23.0 and 22.0 still got maintenance releases in 2026. Confirm policy. | Confirm upgrade assistance with the project before planning. Runs on MySQL, MariaDB or PostgreSQL. |
What open-source ERP support windows mean for upgrade budgets
The support window sets how often you pay for upgrades, and each upgrade has costs that sit with different parties. Internal engineers spend time on release notes, test plans and sign-off. The implementation partner, if you use one, is paid for scoped upgrade work such as rebuilding custom modules and running regression tests. The hosting provider or your own infrastructure team carries the cost of the upgraded test environment and the production cutover. One-time costs include standing up a test environment, migrating data to the new schema, reworking custom modules and integrations, and building a regression suite you can reuse. Recurring costs are each major or series upgrade and the patch testing that runs between them.
A shorter window means more recurring upgrade work, while a longer window concentrates it into fewer events. Odoo's standard support runs three years after a major release, and its security updates stop at the end of that window, so an Odoo on-premise deployment faces a major upgrade roughly every three years to stay patched. Tryton's six-month series is supported for one year, so the upgrade question is more frequent, but its five-year LTS releases give a longer planning horizon. Confirm the exact LTS and series dates with each vendor before you commit to a plan. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database, but on-premise use requires an Enterprise subscription, and the Community edition has no access to that service. Ask whether your upgrade path depends on that subscription before you choose Community.
The size of each upgrade depends on your custom modules and integrations, not on the vendor's release calendar alone. Every custom module, report, workflow and interface to banking, payroll or manufacturing equipment must be retested against the new version, and the work grows with each one you add. Ask any implementation partner for a quote that separates the base platform upgrade, custom module rework, integration retesting and data migration, and that states which items it assumes you have already done. Keep the custom code list current, document each integration owner, and budget for at least one full regression pass per major upgrade. For how these platforms differ on licensing and editions, see the sibling comparison on open-source ERP compared.
How the upgrade path differs for each platform
On Odoo Online and Odoo.sh, the hosting model sets the schedule. Major version upgrades are mandatory every two years, so the upgrade calendar is a recurring operating cost, not a one-time project. Standard support covers three years after each major release, and security updates are only provided during that window. Odoo 19 remains in standard support until September 2028, according to the Odoo support policy.
- Mandatory cadence: Odoo Online and Odoo.sh require a major upgrade every two years, so schedule a test cycle in each two-year period.
- Upgrade service: The upgrade service moves a database to a newer supported version using an upgraded test database. The Community edition has no access to this service, and on-premise use requires an Enterprise subscription.
- Testing before production: Test the upgraded database before cutover, covering custom modules, integrations, reports and the month-end accounting close.
- Standard support window: Security updates stop when standard support ends, so an on-premise instance left on an older major version carries exposure.
- Extended support: Paid extended support is limited to on-premise and select Odoo.sh versions. Ask Odoo which versions qualify and what the terms cost.
Before you commit to a hosting model, confirm the support tier, the upgrade entitlement and the version your custom modules were built against.
Tryton releases a new series every six months, and each series is supported for one year. Each new major series also receives long-term support of five years. The upgrade burden is therefore steady and predictable, but it arrives twice a year, so your team must decide which series to run and when to move. Tryton 8.2 was announced on October 6, 2026, and the project's download page lists the current series and its supported releases.
- Six-month series: A new series arrives every six months, and each one is supported for one year. Plan an upgrade decision at each release, not only at the end of support.
- Five-year LTS line: Each new major series gets five years of long-term support. Confirm which series carries LTS at your planning date and build your standard around it.
- Security cadence: On October 5, 2026, Tryton published security releases for issues 15032 and 15035, so patch windows must follow the release cadence.
- Install method: Tryton can be installed from a Docker image, OS packages, pip or source. Upgrade with the same method you deployed with, for example
python3 -m pip install trytond, and confirm that each installed module matches the target series. - Client testing: Test the desktop client, scripting library and REST client against the new series before users move over.
Confirm with the Tryton project which series is the LTS line when you plan, and write the upgrade rule into your runbook.
iDempiere 13 "Orion" is a long-term support release, announced on the project's website in a post dated March 12, 2026. The supplied facts show that the repository keeps release branches from release-9 through release-13, but they do not state the length of the LTS window or the end-of-life date for older lines. Those are the first items to confirm with the project, through the iDempiere website or its community channels.
- LTS line: iDempiere 13 "Orion" is an LTS release announced March 12, 2026. Confirm its support period and end-of-life date before you standardize on it.
- Branch model: Release branches from release-9 through release-13 remain in the repository. Confirm which older branches still receive fixes before you keep any of them.
- Stack to retest: Java, the ZK web framework, OSGi and the database (PostgreSQL or Oracle) all affect the test surface. Check each OSGi plugin against the target release.
- No fixed cycle supplied: The facts do not give a major upgrade interval. Ask the project whether a fixed cycle exists.
- Vendor support: Development is community-driven. Ask implementers or support providers whether they will carry upgrade responsibility under a written scope.
Confirm the LTS window, the fix policy for older branches and the upgrade path for your plugins before you fix a schedule.
ERPNext can be run in two ways that change who carries the upgrade work. Frappe Cloud is the vendor's managed hosting, which handles installation, upgrades, monitoring and support. Self-hosting with Frappe Docker keeps those tasks with your own team. The release history shows frequent patch releases: v16.0.0 arrived on January 12, 2026, and v16.51.1 on October 15, 2026. The v15 line, first released on October 20, 2023, still received v15.123.0 on October 14, 2026, according to the ERPNext releases page.
- Two hosting paths: Frappe Cloud takes on installation, upgrades and monitoring. Self-hosting through Frappe Docker keeps those tasks with your team.
- Frequent point releases: Frequent patch releases mean a standing patch window is needed, not an annual upgrade project.
- Older lines: Confirm with the project when the v15 line reaches end of support before you choose it for a new deployment.
- Runtime changes: Frappe Framework v16 requires MariaDB 11.8, Redis or Valkey 6 or later, Python 3.14 and Node.js 24, so a version jump can include a runtime upgrade.
- Restore and test: Restore a copy of production, run the migration and check custom apps before cutover.
If you self-host, confirm the target version's runtime requirements in the Frappe installation documentation before you schedule the upgrade.
Dolibarr's release line moves quickly. Version 24.0.0 was released on August 20, 2026, and 24.0.1 on September 7, 2026. Older lines such as 23.0 and 22.0 still received maintenance releases in 2026, according to the Dolibarr releases page. The supplied facts do not state an end-of-life date or a support window for each line, so the upgrade schedule depends on what you confirm with the Dolibarr Association.
- Release line: 24.0.0 arrived on August 20, 2026 and 24.0.1 on September 7, 2026. Confirm the planned support window for each line.
- Older lines: 23.0 and 22.0 still received maintenance in 2026. Ask the Dolibarr Association when they stop receiving fixes.
- Module compatibility: Modules from the DoliStore marketplace and modules built with the Module Builder need retesting on the target version, since the module set usually breaks first.
- Database layer: Dolibarr runs on MySQL, MariaDB or PostgreSQL. Confirm the supported database versions for the target release before upgrading.
- Upgrade method: Test on a copy of the database and files, then cut over, keeping the rollback copy until reports and accounting entries are verified.
Before you choose a version, confirm the support window and the module compatibility list in writing.
How to pilot an upgrade before you commit to a version line
This sequence tests a candidate version on your own data and workflows before you commit to a support window, so the upgrade budget reflects what your custom code actually costs to move. Each step closes with a record your next planning cycle can use.
Inventory custom modules and integrations
List every custom module, add-on, report, scheduled job, API consumer and interface to banks, payroll, shop floor or tax systems. Your internal IT team can do this with the people who built each piece, and it usually takes the longest in the sequence because much of this knowledge lives in individual heads. Mark each item as standard, configured, or custom code, since custom code drives most upgrade effort. The check that closes this step is a signed-off inventory with an owner named for every item.
Confirm the support window from the source
Read the support policy for the exact version you are considering, using the vendor documentation or the project's release page, not a summary from a third party. Note the end of standard support, whether extended support exists for your deployment type, and whether security updates stop before bug fixes. Ask the vendor or community to confirm anything your deployment model depends on, such as hosting type or edition. The closing check is a dated note in your change record showing the source you read and the date you read it.
Build a test database from production
Copy production data into an isolated test environment, and handle personal data under your own retention and masking policy before anyone logs in. Remove or replace customer, employee and payment details where test work does not need them, and restrict access to the test system. Your security or data protection lead should approve the masking rules, and your platform team builds the copy. The check is written approval of the masking approach and a confirmed restore into an environment with no outbound connections to live systems.
Run the upgrade on the test environment
Apply the vendor's upgrade path or the project's migration steps to the test copy, and record every error, warning and manual fix. Keep the upgrade script and each change under version control so the production run repeats the same steps. Your platform engineers can do this with the vendor documentation, but a partner with prior migrations often shortens the diagnosis of custom code failures. The closing check is a clean run log, plus a list of issues that still need a fix before production.
Test finance and manufacturing workflows
Run scripted scenarios that match your month-end close, invoicing, tax calculations, bills of materials, routings and inventory moves, and compare the results with figures from the current production system. Finance and operations staff should own the test cases and sign off the results, since they know which numbers must match exactly. Include integration messages and report outputs in the comparison. The check is a signed test report where every variance is either explained or fixed.
Record the effort for the next cycle
Log the hours spent on each step, the number of custom items that needed changes, and which tasks depended on a single person. This record becomes the basis for the next upgrade budget and shows whether the work can stay in-house. Store it with the inventory and the test report so the next team starts from evidence. The check is a one-page effort record reviewed by the budget owner.
Set a review date before the window closes
Decide whether to commit to the version line, stay on the current line, or move to a later release, and set a review date ahead of the end of the support window you confirmed in step two. Use the effort record and the test report as inputs, and confirm the date against the vendor or repository calendar, not a memory. If the team cannot finish a full cycle before that date, bring in an implementation partner early for the remaining work. The check is a documented decision with the review date in the calendar and an owner named.
How licensing and paid editions change who can keep upgrading
The license on an ERP package does not decide how long you get patches, but the edition and subscription you buy often decide whether you can keep upgrading at all. Odoo Community Edition is licensed under LGPL-3.0, while Odoo Enterprise Edition falls under the proprietary Odoo Enterprise Edition License v1.0, which requires a valid Enterprise subscription matching your user count. The Odoo support policy also states that security updates are only provided during standard support, so a Community or lapsed Enterprise deployment that has moved past that window has no vendor patch path. Odoo's upgrade service is available only with an Enterprise subscription for on-premise use, and the Community edition has no access to it, so the cost of a major move falls to your own team or partner.
Tryton and iDempiere take a different approach. The trytond server is licensed GPL-3.0-or-later, and iDempiere's repository is licensed GPL-2.0. ERPNext is GPL-3.0 and runs on the Frappe Framework, which is MIT-licensed. None of these licenses sets a support window. Tryton's window comes from its release cadence and the series support rules in its download documentation, and iDempiere's comes from its release branches and LTS designation, while ERPNext's comes from the versions the project maintains. Because these licenses are permissive about use, the practical question is whether a vendor, foundation or partner will still ship fixes for the version you run. Ask for that answer in writing and map it against your own upgrade calendar.
Editions and subscriptions also decide which managed services you can buy. On Odoo, only the Custom plan can be hosted on Odoo.sh or on-premise according to Odoo's pricing page, and extended support after standard support is limited to on-premise and select Odoo.sh versions. ERPNext can be run on Frappe Cloud, which handles upgrades and monitoring for you. Confirm with each vendor which hosting tier includes upgrades, which includes extended support, and what is excluded. Ask for these terms in writing before you sign, and have your legal and procurement teams review the license text and current support policy yourself, since terms change between releases.
Questions buyers ask about open-source ERP support and upgrades
How much does an open-source ERP upgrade cost?
No supplied fact gives a price for an ERP upgrade, so the cost depends on what you ask the implementation partner to do. The main cost components are the upgrade assessment, the custom module and integration work that must be retested or rewritten, test environment setup, data migration checks, user acceptance testing and the cutover. Your internal staff time is a cost too, even when no invoice arrives. Costs rise with the number of custom modules, integrations, customizations and sites. Ask for a written quote that lists each of these as a separate line, with the fixed scope, the deliverables and the testing you expect before production.
How long does an ERP upgrade take?
The duration depends on the size of the database, how much custom code you run, how many integrations depend on the platform and how much testing your business requires. Odoo's upgrade service works through an upgraded test database that you should test before moving production, so the test cycle is usually the longest phase. No supplied fact gives a duration, so ask the partner for a timeline tied to the written scope and ask which steps assume your team's availability for testing and sign-off.
What does an ERP upgrade need from our internal team?
Your team needs to own the business decisions: which processes must keep working, who signs off on test results and when a cutover is acceptable. Technical staff need access to the environments, the ability to review configuration and custom code changes and someone who understands the integrations with banking, payroll or other systems. Ask the partner to name the roles it expects from your side in the quote, and to state how many test cycles it plans, so you can schedule staff time before the work starts.
Can our team run ERP upgrades without an outside partner?
Yes, a team with database administration, Python or PHP and Java skills as needed for the platform, and a disciplined test process can run upgrades in-house. The risk grows with heavy customization, many integrations and compliance evidence requirements, because someone must document changes, test results and rollback steps. For Odoo, on-premise upgrades depend on an Enterprise subscription and the Community edition has no access to the upgrade service, so confirm that entitlement before you plan. Decide based on the skills you actually have and the evidence your auditors will ask for.
What happens when an ERP version leaves its support window?
When support ends, the vendor stops providing fixes for that version, so you carry the security and operational risk yourself or move to a supported version. Odoo's standard support covers three years after a major release, security updates are only provided during standard support and paid extended support for on-premise use is limited to selected cases. Tryton supports each series for one year, and each new major series gets five years of long-term support. ERPNext and Dolibarr publish maintenance releases for several lines, so check which lines are current before you commit. Ask the vendor or partner for the end-of-support date in writing.
How often must Odoo Online and Odoo.sh customers upgrade?
Odoo's upgrade documentation states that major version upgrades are mandatory every two years on Odoo Online and Odoo.sh. That schedule means the budget for upgrades recurs, not a single event. On-premise deployments follow the support windows instead, so your plan should show when each major version reaches the end of standard support and when your next upgrade falls due. Build the upgrade calendar into your budget and ask the partner whether a retainer for ongoing upgrades fits your cadence better than separate projects.
Can a test copy of our ERP database be used before an upgrade?
Yes, a test environment is the foundation of any safe upgrade. Odoo documents database duplication with neutralization for test copies, which keeps production data out of test systems and stops test environments from sending live messages or payments. Ask the partner how it will refresh test data, who can access it, and how it will record test results. Those records are often the evidence that a compliance reviewer requests during an assessment.
How DeployOpen scopes an ERP upgrade or platform selection
DeployOpen plans, implements, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For support windows and LTS planning, we start from the version calendar your chosen ERP publishes and turn it into a written upgrade plan that fits your environment.
How we scope
- We confirm which ERP versions and editions you run, and the date each one leaves standard support.
- We record which modules, add-ons and integrations would need retesting at each upgrade step.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We build an upgrade test environment from a copy of production data, with personal data neutralized where the platform supports it.
- We test customizations, integrations and backup restores against the target version before any production change.
- We check identity, permissions and hosting settings so the upgraded platform matches your security baseline.
How we hand over
- We document the version decision, upgrade steps, rollback path and known issues in a handover pack.
- We deliver runbooks for backup, restore and the next scheduled upgrade, sized to your team's skills.
- We walk your engineers and business owners through the test results and open risks before sign-off.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
- A retainer can cover the next version cycle, so upgrades follow the vendor calendar without rushed work.
- Confirm with the vendor which support tier applies to your edition before relying on any support window.
