Odoo or Dolibarr: when each one fits a small or mid-sized business
Odoo fits broad, multi-department operations that may need paid Enterprise apps, while Dolibarr fits leaner invoicing, stock and CRM needs on a light PHP stack. If your business runs sales, purchasing, accounting, HR, manufacturing and eCommerce as connected processes, Odoo's app catalog is built for that breadth. If the core need is issuing invoices, tracking stock and managing customer relationships, Dolibarr lets you switch on only the modules you use and runs on the MySQL, MariaDB or PostgreSQL databases most hosting providers already offer. Three questions settle most of the decision. First, module depth: list the processes that must work on day one and check whether each is covered by the free edition of the product you are considering. Second, whether you need paid features: Odoo's Studio, Documents, Sign, Payroll, Quality and mobile apps are listed as Enterprise only, and on-premise use requires an Enterprise subscription, so price that recurring cost against the features you will actually use. Third, hosting: Odoo's pricing page limits on-premise and Odoo.sh hosting to its Custom plan, while Dolibarr can run on your own servers, with Docker, or through DoliCloud's published plans. The last question is how much custom work your team can maintain. Odoo's upgrade service requires an Enterprise subscription, and its standard support window for each major release is three years, so plan an upgrade cadence and budget for testing custom modules against each new version. Dolibarr's Module Builder and DoliStore add-ons lower the cost of small changes, but confirm with your implementer which extensions your processes need and who will maintain them after go-live. Ask any partner for a fixed-scope written quote that covers installation, data migration, testing and upgrades separately.
Which platform fits which scenario
This table maps common Odoo vs Dolibarr scenarios to the platform that fits better and the condition that makes it so. Read each row as a starting point, then check the named condition against your own user count, edition needs and hosting preference.
| Scenario | Better fit | Condition that decides it | Where the other platform still works |
|---|---|---|---|
| Services firm needing project tracking and invoicing | Odoo | Fits when project work must connect to sales, purchasing and HR in one database, and when you need Enterprise apps such as Timesheets and Sign in the same suite. | Dolibarr covers projects, invoicing and timesheets-style modules for a smaller firm that wants fewer apps to administer. |
| Manufacturer needing shop floor and quality tools | Odoo | Fits when you need Quality, PLM and Field Service style tooling, which the Odoo editions page lists as Enterprise only. Confirm which of these your floor requires before choosing. | Dolibarr offers manufacturing (MRP) as a module, which suits a lighter production process without Enterprise quality or PLM workflows. |
| Small team of a few dozen users needing only invoicing and stock | Dolibarr | Fits when the scope is limited to invoicing and stock, you want to enable only those modules, and you prefer a self-hosted PHP application with no per-user subscription to manage. | Odoo remains viable if the team expects to grow into CRM, accounting or HR apps without a second migration later. |
| Company needing multi-company accounts | Odoo | Fits when several legal entities must share one database with inter-company records. Odoo lists multi-company only on the Custom plan, so confirm plan eligibility for on-premise or Odoo.sh. | Dolibarr can serve separate entities as separate installations, which suits groups that want strict separation over shared records. |
| Team wanting SaaS with no servers to run | Dolibarr | Fits when you want a hosted option with published plans, such as DoliCloud's Basic and Premium tiers, and do not need Odoo's Custom plan features. | Odoo Online fits teams that accept standard apps without custom code, but Odoo's SaaS releases every two to three months leave less time to plan changes. |
| Team needing mobile apps and official upgrade service | Odoo | Fits when Android and iOS apps and the upgrade service matter, both of which the editions page lists for Enterprise only. Plan for an Enterprise subscription matching your user count. | Dolibarr fits teams that can manage their own upgrades and do not need vendor mobile apps. |
| Organization preferring a PHP stack on existing hosting | Dolibarr | Fits when your team already runs PHP with MySQL, MariaDB or PostgreSQL on Apache, Nginx or IIS, and the prerequisites page's versions match your environment. | Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or later, so it suits teams already operating Python and PostgreSQL. |
| Organization requiring a long, predictable support window | Odoo | Fits when standard support of three years after each major release matters, and you can plan upgrades within that window. Confirm extended support eligibility for your version and hosting model. | Dolibarr fits teams that can track its release lines, such as 24.0 and 23.0, and choose their own upgrade schedule. |
How Odoo and Dolibarr are built and deployed
Odoo and Dolibarr differ in language, database requirements, licensing model and how their modules are packaged. The cards below cover what each stack needs from your infrastructure and what that means for the people who run it day to day.
Odoo's Python and PostgreSQL stack
Odoo is built on Python and PostgreSQL. For Odoo 19, the source installation requires Python 3.10 or later and PostgreSQL 13 or later, so your Python and database versions must match the release you deploy. Community is licensed under LGPL-3.0. Enterprise is proprietary and requires a subscription matching your user count. Confirm which apps your team needs before you choose the edition, because the license terms follow the edition, not the app.
Dolibarr's PHP application stack
Dolibarr is a modular PHP application licensed under GPL-3.0. It runs on MySQL 5.7.7 or newer, MariaDB 10.3 or newer, or PostgreSQL 9.1.0 or newer, with experimental Microsoft SQL Server support. Any web server that runs PHP, such as Apache, Nginx, Lighttpd or IIS, can host it. Your PHP version and database version should be checked against the prerequisites page for the release you plan to run, since the minimums are set per release line.
Deployment options on each side
Dolibarr can run on premises, on virtual or dedicated machines, with Docker, or as SaaS through cloud providers and partners. Odoo's self-hosted routes are packaged installers, a source install and Docker, but Odoo.sh and on-premise hosting for Odoo's own managed service require the Custom plan. Confirm which route your security team approves, whether your hosting provider supports it, and who patches the operating system underneath each option.
Database administration effort
Both products keep business data in a relational database that your team must back up, tune and restore. Odoo leans on PostgreSQL, so your DBA skills need to cover that engine. Dolibarr accepts MySQL, MariaDB or PostgreSQL, so an existing MySQL estate may be the simpler fit. Odoo's documentation covers database duplication with neutralization for test copies, which is useful for staging. Ask who owns backups, restore tests and capacity planning before you commit.
Version upgrades and maintenance
Odoo standard support covers three years after a major release, with security updates only during that window. Odoo Online and Odoo.sh require major upgrades every two years, and the upgrade service that moves a database forward is for Enterprise subscribers on-premise. Dolibarr publishes maintenance releases on several lines. Plan an upgrade test environment, custom module compatibility checks and a rollback path for both products before you go live.
Side-by-side: licensing, support, extensibility and identity
This table compares how Odoo and Dolibarr differ on license, support windows, release lines, extensibility, identity integration, API access and upgrade tooling. Read each row against your own edition plan, because Odoo's paid tiers change what is available. The main takeaway is that Odoo's support and extension paths depend heavily on the edition and plan you choose, while Dolibarr is GPL-3.0 throughout but needs its identity and API options confirmed.
| Area | Odoo | Dolibarr |
|---|---|---|
| License | Community edition under LGPL-3.0. Enterprise edition under a proprietary license that requires a valid subscription matching your user count. | Free open source under GPL-3.0, with no separate paid edition described in the supplied facts. |
| Editions and paid features | Studio, Documents, Sign, Payroll, PLM, Quality, Field Service, Approvals, Knowledge, mobile apps, version upgrades and unlimited functional support are Enterprise only. | All enabled modules are part of the free product. Confirm with the vendor or DoliCloud which hosted plan features differ from self-hosted. |
| Release lines and support | Odoo 20 released September 2026 with standard support planned until September 2029. Odoo 19 supported until September 2028. Odoo 18 supported until September 2027. | Dolibarr 24.0.1 released September 7, 2026. Maintenance releases still issued for 23.0 and 22.0. Confirm the support window for each line in the Dolibarr release notes. |
| Extensibility | Modules from the Odoo apps catalog. Studio and custom modules require the Custom plan for Odoo.sh or on-premise use, according to the pricing page. | Enable only the modules you need. Extend through the DoliStore add-on marketplace and the low-code Module Builder. |
| Identity integration | LDAP authentication is documented for Odoo 19. Confirm SSO options such as SAML or OIDC for your edition and version. | Confirm directory and single sign-on options (LDAP, SAML, OIDC) in the Dolibarr documentation or with the vendor before you rely on them. |
| API access | External API access is included in the Custom plan, according to the pricing page. Confirm which endpoints your use case needs. | Confirm the REST or API capabilities and authentication methods in the Dolibarr documentation for your version. |
| Upgrade tooling | Upgrade service available to Enterprise subscribers. Community edition has no access to it. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. | No vendor upgrade service is described in the supplied facts. Plan and test upgrades with your own staging database and custom modules. |
What is free and what is paid on each platform
Odoo Community is the free edition, licensed under LGPL-3.0 and published on GitHub. You can install it yourself, read the source and change it. The license does not cover the paid apps or the services Odoo sells alongside Enterprise, so the cost of a Community deployment is the infrastructure, implementation and support you arrange yourself.
- Included: the open source core suite, covering apps such as CRM, accounting, inventory, HR and manufacturing, under LGPL-3.0.
- Excluded: Studio, Documents, Sign, Payroll, PLM, Quality, Field Service, Approvals, Knowledge and the Android and iOS mobile apps, all listed by Odoo as Enterprise only.
- No upgrade service: Community has no access to Odoo's upgrade service, so major version moves are planned, tested and carried out by your team or a partner.
- No Enterprise support: unlimited functional support is an Enterprise item, so day-to-day help comes from your own staff, a partner or the community.
Confirm which Community features your processes depend on, and list any Enterprise-only capability you would need to build or source another way before you commit.
Odoo Enterprise is a proprietary edition under the Odoo Enterprise Edition License v1.0, and its source code is not publicly available. Use requires a valid Enterprise subscription that matches your user count, obtained through a subscription or partner access. The Odoo editions page lists the services and apps that come with it.
- User-matched license: the subscription must match the number of users, so headcount growth changes the license cost.
- Enterprise apps: Studio, Documents, Sign, Payroll, PLM, Quality, Field Service, Approvals and Knowledge, plus the Android and iOS mobile apps.
- Upgrades: version upgrades are an Enterprise item, and on-premise use of the upgrade service requires an Enterprise subscription.
- Support: unlimited functional support is included, and standard support covers the first three years after a major release with security updates and bug fixes.
- Activation: on-premise Enterprise databases are activated by entering the subscription code, so the subscription should be in place before go-live.
Ask for the user count the subscription covers, which apps appear in the quote, and how support and upgrades are priced for your hosting model.
Odoo's pricing page lists three plans: One App Free, Standard and Custom. The paid plans carry per-user monthly prices with a yearly discount, and the plan you choose also decides where you can host. One App Free and Standard are limited to Odoo Online, so on-premise and Odoo.sh both require the Custom plan.
- One App Free: one app, unlimited users, Odoo Online only.
- Standard: all apps, Odoo Online only, with no on-premise or Odoo.sh option.
- Custom: the only plan that can be hosted on Odoo.sh or on-premise, and the only one that includes multi-company, Studio, external API access and custom modules.
- Price basis: per-user monthly prices with a yearly discount. Figures change, so take current amounts from the pricing page and confirm them in your written quote.
Confirm the plan, the hosting target and the module list in writing before you compare totals, because a self-hosted Odoo deployment needs the Custom plan.
Dolibarr is free open source software licensed GPL-3.0 and supported by the Dolibarr Association, which was founded in 2009. On the self-hosted route there is no per-user license fee for the application. You can run it on premises, on virtual or dedicated machines or with Docker, and you enable only the modules you need, so your cost follows the infrastructure and services you add around it.
- License: GPL-3.0, with no per-user subscription for the self-hosted application.
- Optional modules: CRM and sales, HR, invoicing, stock, manufacturing (MRP), point of sale and projects are switched on as your processes require.
- Database and web server: MySQL 5.7.7 or newer, MariaDB 10.3 or newer, or PostgreSQL 9.1.0 or newer, on any PHP web server such as Apache, Nginx, Lighttpd or IIS.
- Extensions: add-ons come from the DoliStore marketplace, and the low-code Module Builder supports custom modules. Confirm add-on prices and license terms with each publisher.
Check which modules and DoliStore add-ons your processes need, and treat hosting, backups and administration as recurring costs of the self-hosted route.
DoliCloud describes itself as the official Dolibarr preferred partner and hosts Dolibarr as SaaS. Its published plans are Basic at 14 euros per user per month and Premium from 45 euros per month, each with a 30-day free trial. Hosting moves server work to the provider, but the subscription recurs for as long as you use the service.
- Basic: 14 euros per user per month, so the cost scales with headcount.
- Premium: from 45 euros per month. Confirm what the Premium tier includes in the current plan terms before you compare tiers.
- Trial: each plan has a 30-day free trial, which is a useful window to test your data model and modules before you commit.
- Scope: the published prices do not cover implementation or customization work, so ask for those as separate items in a written scope.
Compare the Basic per-user total with the Premium starting price at your headcount, then add any implementation partner fees that apply to your scope.
What drives the running cost of each platform
The software fee is the smallest part of the comparison for many teams, and the two platforms bill it in very different ways. Odoo's paid tier is a per-user subscription, and on-premise or Odoo.sh hosting requires the Custom plan, so the recurring line item depends on your user count, the apps you need, and whether you run the Enterprise edition at all. Dolibarr is free open source software under GPL-3.0, so its license cost is zero, but you still pay for servers, administration, add-on modules purchased through the DoliStore marketplace, and any managed hosting you choose, such as DoliCloud's published plans. Ask Odoo's sales team to confirm in writing which plan, user count and app set your quote assumes, and ask any Dolibarr partner to itemize hosting, backups and module fees separately.
Infrastructure and administration costs recur on both sides. Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or later, and Dolibarr runs on MySQL, MariaDB or PostgreSQL behind any PHP-capable web server, with the prerequisites page citing MySQL 5.7.7 or newer and MariaDB 10.3 or newer. Your internal team or external provider will patch the database, web server, runtime and backups on each stack, so the skills you already have in PostgreSQL, MySQL or PHP shift the cost materially. Ask for the expected sizing of CPU, memory and storage for your user count, and for the backup and restore procedure you will be billed to maintain. Both platforms also need a test environment, and the Odoo on-premise documentation covers database duplication with neutralization for test copies, which is a useful reference when you price that work.
Upgrade effort is where the two cost curves diverge most. Odoo standard support covers three years after a major release, security patches stop when standard support ends, and on Odoo Online and Odoo.sh major upgrades are mandatory every two years. Odoo's upgrade service requires an Enterprise subscription for on-premise use, so a Community deployment must budget for its own migration work. Dolibarr releases follow their own lines, with 24.0.0 released on August 20, 2026 and 24.0.1 on September 7, 2026, and older lines still receiving maintenance releases. Ask any implementer to quote upgrades separately from initial implementation, to name the custom modules and DoliStore add-ons that will need retesting on each release, and to state who owns the test database used to validate each upgrade.
How to move from Dolibarr to Odoo, or back
This sequence turns a migration idea into a tested, signed-off cutover, with each step producing a record your finance and operations leads can check. It applies in either direction, though the vendor confirmations differ, so confirm the target platform's import and export paths before you commit.
Inventory data, customizations and integrations
Your internal IT or operations lead lists every data set in the current system: customers, suppliers, products, open orders, invoices, stock levels, chart of accounts, documents and attachments. Alongside the data, list every custom field, Module Builder or add-on module, report, scheduled job, API integration and user role. The output is a written inventory with an owner and a keep, rebuild or retire decision for each line, which becomes the scope document for the rest of the migration.
Map Dolibarr modules to Odoo apps
Take the inventory and match each Dolibarr module to an Odoo app, such as proposals and orders to Sales, invoicing to Accounting, stock to Inventory, and projects or HR to their equivalents. Mark where a module has no direct counterpart, where the Odoo app sits in the Community or Enterprise edition, and where the Odoo version you choose changes the behavior. The output is a signed mapping table that shows which Odoo apps you must license before any data moves.
Decide between Odoo Community and Enterprise
Using the mapping table, decide which edition you need, because on-premise Enterprise use requires a subscription that matches your user count and Community has no access to Odoo's upgrade service. Confirm with Odoo which apps your mapping needs are available in each edition and what the subscription costs for your user count. The output is a documented edition decision, with the supporting vendor confirmation attached to the project record.
Build a test database from a duplicate
Set up the target environment on the hosting model you chose, then load your extracted data into a test database. Where you are moving data between Odoo databases, use Odoo's database duplication with neutralization to create test copies, so that outgoing emails and payment integrations do not fire against live contacts. The output is a test environment that the team can reset and rerun as the mapping changes.
Migrate master data and documents first
Load customers, suppliers, products, contacts and attached documents into the test database, starting with master data and checking field-level mapping at each batch. Expect that master data and documents transfer most cleanly, with the exact result depending on how closely the fields line up. Record every field that fails to map, every duplicate and every dropped attachment. The output is a reconciliation log that shows counts from source and target for each object type.
Validate accounting and stock records
Have the finance lead and the warehouse lead reconcile the test database against the source system. For accounting, compare trial balances, open receivables and payables, and tax totals by period. For stock, compare on-hand quantities by location and valuation method. Check that open orders and invoices carry their status correctly. The output is a signed reconciliation for each ledger and stock location, with every difference explained or corrected before the team moves on.
Rebuild workflows, reports, permissions and integrations
Rebuild the items that do not transfer cleanly: approval workflows, custom fields, reports, scheduled jobs, API integrations and user roles. Test each rebuilt item with a sample transaction and a user from each role. Confirm with the vendor or your implementation partner how the target version handles these items, since behavior differs between Dolibarr modules and Odoo apps. The output is a test script that covers each rebuilt item and records the result.
Run parallel checks and cut over
Run the old and new systems side by side for a set period agreed in your plan, entering the same sample transactions into both and comparing results. Once the reconciliations match and the test script passes, freeze the source system, run a final incremental load, repeat the reconciliation and switch users over. The output is a signed cutover record and a retained, read-only copy of the Dolibarr data for audit and rollback.
Where Odoo and Dolibarr implementation projects usually run long
Most delays on either platform come from scope that was never pinned down, not from the software itself. On Odoo, the biggest source of effort is configuration across apps that depend on each other: sales, inventory, accounting and manufacturing all draw on the same product, partner and chart of accounts records. A multi-company setup adds decisions about the chart of accounts per legal entity, intercompany flows and access rules before a single transaction is posted. Teams should also decide early whether they need Enterprise apps such as Studio or Documents, because the Enterprise subscription must match the user count and changing it mid-project moves the budget. Finally, pick the environment (Odoo Online, Odoo.sh or self-hosted) before configuring, since it determines what custom code is possible and how upgrades are delivered. Every major version then needs an upgraded test database to be checked before production, so plan that test cycle into the timeline from the start.
Dolibarr projects tend to run long in different places. Module selection is quick to start but easy to over-expand, because enabling a module such as projects, manufacturing or HR touches several other records and permissions. Data import is usually the largest unplanned task: customer, supplier and product lists from spreadsheets or an older system need cleaning and mapping before they load cleanly. Where a required workflow is missing, custom work with the Module Builder or an add-on from the DoliStore marketplace needs an agreed review, and customizations that nobody approved tend to be rebuilt during testing. Hosting setup for a PHP stack on MySQL, MariaDB or PostgreSQL, including the web server, backups and the update routine, is also a real line item. In all cases, staff training is the delay most often underestimated. DeployOpen plans and implements on fixed scope agreed in writing before work starts, so ask any implementation partner to name the scope, the data cleanup owner and the approval step for customizations in the quote.
Questions buyers ask before choosing Odoo or Dolibarr
How much does an Odoo or Dolibarr implementation cost?
No single figure applies because the cost depends on scope, data volume and integrations. For Dolibarr, the software is free under the GPL, so the spend is labor, hosting, and any DoliStore add-ons or DoliCloud subscription. DoliCloud publishes a Basic plan at 14 euros per user per month and a Premium plan from 45 euros per month, each with a 30-day free trial. For Odoo, the Community edition is free, but on-premise or Odoo.sh hosting requires the Custom plan, and Enterprise apps require a subscription matching your user count. Implementation fees, paid by you to an implementer, cover analysis, configuration, data migration, testing and training. Ask any implementer for a fixed-scope written quote that lists each deliverable and the license line items separately.
How long does a Dolibarr or Odoo rollout take?
Timeline is set by the number of modules in scope, how many processes change, the quality of your existing data, and how many approvals the project needs. A Dolibarr rollout limited to invoicing and a few modules usually moves faster than a multi-module Odoo project that adds accounting, inventory, manufacturing and Enterprise apps, because each added app brings its own configuration and testing. Odoo's release cadence also matters: SaaS versions ship every two to three months, and the on-premise upgrade path must be tested before production. Ask for a timeline tied to named phases, with a testing window that you control, rather than one that assumes data is clean on day one.
Can our team self-implement Dolibarr or Odoo Community without outside help?
A technically strong team can install and configure either product. Dolibarr runs on MySQL, MariaDB or PostgreSQL on any web server that runs PHP, and its prerequisites page lists minimum versions. Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or later, and its source installation path is more involved than Dolibarr's. The harder work is process design, data migration, access control, backups, security hardening and upgrades, which need someone accountable beyond the first install. Decide early who owns each of those tasks after go-live, and whether your staff have time for them alongside daily operations.
What does the business need to provide during an ERP project?
The business must supply named process owners who can make decisions on invoicing, stock, purchasing and reporting, plus people who can sign off test results. Data is usually the constraint: customer, supplier, product and opening balance records need cleanup and mapping before migration. Testing time also needs to be planned on the calendar, with real transactions run through the system before go-live. Expect to fund training for each user group. Projects tend to slow down when these roles are unfilled, so confirm the time commitment in writing before the scope is signed.
Which platform is cheaper to upgrade and run over time?
Dolibarr is generally simpler to run because it is a single PHP application with modules you enable only as needed, and the Dolibarr GitHub releases show maintenance continuing on older lines. Odoo upgrades depend on your edition. Odoo's upgrade service is available with an Enterprise subscription for on-premise use, and the Community edition has no access to it. On Odoo Online and Odoo.sh, major versions are mandatory every two years. Odoo standard support covers three years after a major release, and paid extended support is limited to on-premise and select Odoo.sh versions. Custom modules add testing effort in both products. Ask each vendor for its upgrade terms in writing and budget for at least one test upgrade cycle.
What does DeployOpen do on a Dolibarr or Odoo project?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Share your module list, data sources, user counts and hosting constraints to receive a scoped proposal.
What security and compliance work does an ERP rollout need?
An ERP holds financial, customer and employee data, so access control, backups, patching and audit logging need explicit owners. Odoo's LDAP authentication documentation covers directory-based sign-in for Odoo, and Dolibarr access depends on its user and permission model and your web server configuration. Plan encryption, database backup restore tests and a patch process for the web server, PHP or Python runtime and database. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Ask your auditor which evidence they need before the design is frozen.
How DeployOpen helps choose, implement or migrate
DeployOpen works on Odoo vs Dolibarr as a planning and delivery partner for self-hosted deployments inside your own infrastructure. The work starts with a written scope that fits your edition choice, module needs and hosting route, then moves through build, testing, documentation and handover.
How we scope
- Written scope covers the modules, editions, hosting target and data you need to move before any work starts.
- We map which Odoo apps would need an Enterprise subscription and which Dolibarr modules you would enable.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing up front.
- Scope documents which extensions, custom modules or integrations are in and out of the agreed work.
How we build
- Installation runs in your cloud accounts, data centers or air-gapped network, not in a DeployOpen-hosted environment.
- Configuration covers users, roles, LDAP or other identity links where the chosen platform supports them, with items confirmed first.
- Customization and integration work is tested on a copy of your data before anything reaches production.
- Hardening and backup routines are built and tested as part of the delivery scope, documented for your team.
How we hand over
- Handover includes configuration records, runbooks, backup and restore procedures and admin documentation.
- Upgrade steps for your chosen version path are written down, including test database checks before production changes.
- We document the controls and evidence your compliance team needs, while auditors and certification bodies issue any formal findings.
- Your team receives training on the admin tasks it will own after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades, patch application and periodic review of extensions and backups.
- Ask us to confirm which support windows and upgrade tools apply to your edition before you commit to a retainer.
- Security testing of the deployed system can be scoped separately from the implementation work.
