The first thing to establish about open-source CRM is that none of these systems is free.
The licence is free. Servers, setup, mapping existing processes into fields and workflows, migrating legacy data, updates and operations remain cost items; they shift from licensing to infrastructure and services. Anyone hoping to delete an invoice will be disappointed. Anyone looking to regain control over the system, the data and the price curve gets exactly that.
This article compares eleven systems that merit consideration in 2026: architecture, licensing, five-year cost and area of use. It closes with a recommendation for mid-sized European companies, preceded by four cases in which that recommendation does not apply.
| Situation | System | Reason |
|---|---|---|
| Mid-sized B2B company, established processes, data within the EU | SuiteCRM | broadest feature set, fine-grained permissions, standard frameworks, largest provider market in Europe |
| Engineering team running the CRM as part of its own stack | Twenty | Node.js and React, API-first, cleanest codebase in this comparison |
| Software house selling its own vertical product | Atomic CRM | 15,000 lines of code, MIT licence, no publication obligation |
| Small team without an IT department, configuration instead of development | EspoCRM | most capable in-app studio, shortest time to production |
| Manufacturing, inventory and accounting in one system | Odoo | not a CRM but an ERP with a CRM module |
| Association, foundation, membership body | CiviCRM | donations, contributions and members as core functions |
Two developments have reordered this market, and both concern architecture rather than features.
The break with the LAMP stack. The established systems come from the era of PHP, MySQL, in-house MVC frameworks and jQuery front ends. SuiteCRM, EspoCRM and Vtiger have their roots there.
The technical debt in those codebases is forcing re-architecture work that has progressed to varying degrees. The younger generation, Twenty foremost among them, builds on Node.js, React and an API-first design around GraphQL. The difference is not a matter of taste; it determines what customisation costs across the life of the system.
Artificial intelligence. Running large language models natively inside a self-hosted CRM requires infrastructure that does not pay off for most installations, which is why open-source systems trail commercial SaaS platforms here.
The answer from the newer generation is not a model of their own but legibility for external ones: Twenty and Atomic CRM ship manifest files that let AI agents grasp the system context and modify source code reliably. SuiteCRM and Vtiger rely on plugins for lead scoring and sentiment analysis, most of them commercial.
| System | Stack | Licence | Closed commercial use |
|---|---|---|---|
| SuiteCRM 8 | PHP 8.1, Symfony 6.4 / Angular / MySQL | AGPL-3.0 | no, strong copyleft |
| Twenty | Node.js, Nest.js / React, TypeScript / PostgreSQL | AGPL-3.0 | no |
| Atomic CRM | Supabase / React, shadcn/ui | MIT | yes |
| EspoCRM | PHP 8, in-house framework / Handlebars / MySQL | AGPL-3.0 | no |
| Odoo CE | Python / OWL JS (in-house) / PostgreSQL | LGPLv3 | limited |
| ERPNext | Python, Frappe / MariaDB | GPL-3.0 | no |
| Krayin | PHP 8, Laravel / Vue.js / MySQL | MIT | yes |
| OroCRM | PHP 8, Symfony / Backbone.js / PostgreSQL | OSL-3.0 | no |
| YetiForce | PHP, Vtiger fork / MySQL | YetiForce Public License | yes, MIT-based |
| Vtiger CE | PHP / MySQL | Vtiger Public License | limited |
| CiviCRM | PHP, Drupal/WordPress / MySQL | AGPL-3.0 | no |
The licence determines whether a company may keep its own modifications. It rarely comes up during selection and regularly becomes an issue once the project is under way.
AGPL-3.0, used by SuiteCRM, Twenty, EspoCRM and CiviCRM, is the strictest form of copyleft. It closes the gap left by the classic GPL: modifications must be published even when the software is only made available over a network, that is as a cloud service without a copy ever being distributed.
For internal use within a single company this has no practical effect and customisation remains unrestricted. The clause becomes relevant as soon as a modified system is offered to third parties as a service. For a SaaS product on an AGPL base, legal review should precede the technical decision.
MIT, used by Atomic CRM and Krayin, imposes almost no conditions. Modification, distribution and closed source are all permitted. For agencies and software houses selling a vertical product, this is the decisive difference.
LGPLv3, used by Odoo Community, occupies the middle ground: dynamically linked modules of your own remain proprietary while the core stays protected.
For the most common case, a company running a CRM for its own staff, the choice of licence is immaterial. Which is precisely why it is worth confirming that this is the case.
The licence line disappears; six others do not.
1 · Software and subscriptions. Genuine community editions remove this item. Open-core models do not: Odoo and Vtiger reserve features for their paid editions, Odoo from around USD 7.25 per user per month, Vtiger from USD 12 (as of 09/2026). What looks free during evaluation can become a price list during the project.
2 · Infrastructure. Servers, storage, backup, monitoring and security. Requirements have risen with the newer versions: SuiteCRM 8 requires a minimum of 4 GB RAM according to vendor documentation, with 8 GB and SSD storage recommended. SuiteCRM 7 ran on 2 GB.
3 · Setup and customisation. The largest item in the first year. Reported figures for mid-sized European projects sit at one and a half to four times what a comparable SaaS licence would have cost over the same period. For architecturally demanding systems such as Odoo or OroCRM the multiple rises, because the required specialists are scarce.
4 · Interfaces. Connections to ERP, inventory, shop and accounting systems. Ready-made connectors to cloud services are the exception in open source; integration usually runs through the REST API and therefore carries development, testing and maintenance effort.
5 · People and adoption. The item most frequently underestimated. At 100 to 200 users, projects of this size occupy one to two full-time equivalents in project management over 12 to 18 months, plus 30 to 60 per cent of the working time of four to ten key users. From the second year, ongoing operation requires a further 0.5 to 1.5 full-time equivalents. That figure falls when administrators are trained rather than left to work the system out alongside their day job.
6 · Support, maintenance and upgrades. Security patches are routine; major version changes are not. Moving from SuiteCRM 7 to 8 is a project in its own right rather than an update.
For the first two years the model generally does not pay off; implementation consumes what the licence saved.
From the third year the ratio reverses, from two directions. The initial investment is written off, while SaaS contracts typically rise by three to seven per cent annually, producing a 16 to 40 per cent premium over five years without a single user being added. Long-term figures reported for self-hosted installations fall below USD 15 per user per month, against USD 60 to over 100 for comparable SaaS models.
The condition that follows is clear: open source pays off with long service life and high user counts. For an 18-month horizon and six users, a subscription is the cheaper option.
SuiteCRM was created in 2014 after SugarCRM discontinued its open edition and has since served as the reference for full-featured open-source CRM.
It covers sales, marketing, service and projects, includes a workflow engine, and offers with its Security Suite a permission model whose granularity is rare outside Salesforce. Making records visible by department, region and role is configuration here rather than a development ticket.
With version 8, SalesAgility replaced the architecture: Symfony 6.4 LTS on the back end, Angular on the front, REST and GraphQL as interfaces. The version 7 codebase continues to run underneath as a legacy layer so that a decade of extensions remains usable. That compromise explains both the demanding migration and the mixed assessment of developer experience.
Strengths: feature breadth, permission model, ecosystem, standard frameworks. Weaknesses: parts of the interface are dated, performance degrades with large datasets and complex subpanels, and migrating from 7 to 8 takes effort.
Twenty is the most consistent implementation of the new generation: Node.js and Nest.js on the back end, React and TypeScript on the front, PostgreSQL and Redis for data, GraphQL and REST as interfaces. Objects and fields are defined in the interface, and the corresponding API endpoints are generated automatically.
Marmelab's developer benchmark places the system first in its field. It is also the first CRM to give AI agents structured access to its own code through manifest files.
The limitations are operational. There is no installer; deployment requires Git, Docker Compose and experience with database operations. The community edition lacks parts of the dashboarding, and list views remain functionally limited. Twenty suits organisations that build software and only partly those that merely use it.
EspoCRM is lean, fast and clearly laid out. Its in-app studio lets administrators change the data model, layouts, permissions and workflows without touching source code, which markedly reduces the share of external development. For teams without their own IT department the system is often productive within days.
The drawbacks sit below the surface: a proprietary PHP framework, a proprietary ORM and a Handlebars-based front end. External developers cannot apply existing knowledge of Laravel, Symfony or React, documentation is patchy and test coverage is low. There is also a concentration risk, as the project rests substantially on a single core developer.
YetiForce is a Vtiger fork developed further by a Polish company and one of the most feature-rich systems in this comparison: more than 80 modules and around 90 configuration panels, along with tooling for GDPR record-keeping and LDAP integration.
The price is complexity. The interface is heavily data-driven, the configuration options overwhelm small teams, and the documentation assumes source-code study for custom modules.
Vtiger also descends from the SugarCRM line, records more than five million downloads and maintains one of the oldest communities in the field. Marketing automation and email integration are solid and the plugin catalogue is extensive. Navigation, interface and mobile application fall clearly behind newer competitors.
Odoo is not CRM software but a modular business suite built on Python. The CRM module offers visual pipeline management, multi-channel connectivity and a native mobile app. Its real value appears at the seam: a won opportunity produces a manufacturing order and an invoice without a system change.
The technical cost is substantial. Odoo uses its own OWL JS front-end framework, the codebase spans more than 200,000 commits with varying code quality, and version upgrades have a poor reputation in the community. Customisation requires Python developers specialised in Odoo, and some features are reserved for the enterprise edition.
ERPNext pursues the same approach on a different base: Python, MariaDB and the in-house Frappe framework. Reporting is comprehensive and integration is close, but workflows are rigid. For a pure CRM project the system is oversized, and learning Frappe takes time for developers without prior exposure.
Atomic CRM by Marmelab comprises around 15,000 lines of code and relies almost entirely on standard libraries: React and shadcn/ui on the front end, Supabase as the back end, SSO and SAML included. Under the MIT licence it is the fastest available base for a vertical product. It is not intended as a finished CRM for an end-user organisation.
Krayin combines Laravel on the back end with Vue.js on the front and is published under the MIT licence. For teams already working in the Laravel ecosystem the entry cost is correspondingly low. From a user's perspective the interface is sluggish, list views carry little information and filtering is limited.
OroCRM comes from the founders of the Magento e-commerce platform, builds on Symfony and targets complex customer hierarchies and omnichannel B2B sales. With roughly 1.3 million lines of code and a front end based on jQuery and Backbone, the onboarding effort is high. The system pays off only for correspondingly specific requirements.
CiviCRM is not a sales system but constituent relationship management for members, donations, contributions and volunteer work. It is widely used by European associations, in part because of its extensions for GDPR documentation and processing records.
A note on interest: we work with SuiteCRM. The arguments below are therefore not neutral and are phrased so that they can be verified.
Feature breadth on standard technology. This is the point most often overlooked in comparisons. EspoCRM, Odoo and ERPNext build on frameworks they wrote themselves. Customising those requires developers who know that specific framework, and that group is small and expensive. The licence lock-in that was avoided returns as a dependency on a narrow labour market.
SuiteCRM 8 moved in the opposite direction with Symfony and Angular: anyone who knows Symfony can work on SuiteCRM. That is not a question of developer comfort but of negotiating position with any supplier, including us.
A complete community edition. SuiteCRM holds no modules back for a paid edition. Odoo and Vtiger operate differently, and the boundary usually becomes visible only once the project is running.
A permission model for established organisations. Differentiated visibility by territory, role and hierarchy is configuration in the Security Suite. In most other open systems the same requirement is a development task.
AGPL and self-hosting. The location of operation is freely selectable. For public bodies and regulated industries this has become less a stance than a procurement requirement, in which open source and EU hosting frequently appear together.
Availability of providers. More than a decade of adoption means an extension marketplace, documented solutions in the forums, and enough providers across Europe to make switching supplier realistic. For Twenty and Atomic CRM that market is currently small.
Four limitations belong in the decision.
Developer experience is average at best. Marmelab's benchmark awards SuiteCRM 8 five points out of ten and Twenty nine. Documentation for the Angular front end is thin, the legacy layer is a compromise, and without a correctly configured opcache the system responds slowly. The assessment is reasonable.
Version 8 has not yet reached functional parity with version 7. The Studio module for visual customisation behaves inconsistently on heavily customised installations, and widely used community plugins remain available for version 7 only. Maintaining the 7 series as long-term support is a consistent response to that.
Moving from 7 to 8 is a migration project. It runs as a fresh installation of version 8 into which the old system directory is copied, followed by console commands for the database and metadata. The documentation lists recurring failure modes: incorrect file permissions after running commands under the wrong account, invalid CSRF tokens from stale cookies, and errors traceable to an uncleared Symfony cache.
The system is not intended for unassisted self-operation. Anyone looking for a CRM that runs productively within days without guidance is better served by EspoCRM or a SaaS subscription. SuiteCRM plays to its strengths where processes are specific enough that adapting the system costs less than adapting the organisation.
The conclusion is therefore not that SuiteCRM is the right choice for everyone. It is that SuiteCRM is the right choice for the cases listed above, and that implementation should be supported until the organisation's own team can take over operations.
Both systems appear in almost every selection process, although they solve different problems.
A CRM manages relationships: conversation history, next steps, probability of closing. An ERP manages resources: stock, production, payment status. Odoo is an ERP with a CRM module; SuiteCRM is a CRM with no ERP ambitions.
The decision therefore does not turn on feature counts but on one question: must a won opportunity automatically produce a manufacturing order, a delivery note or an invoice?
If the answer is yes, Odoo is the appropriate base. In that case an ERP project has to be planned, with specialised Python developers and with the effort that version upgrades typically create in this environment.
If the answer is no, because accounting and inventory systems are established and are staying, no second ERP is required, only a CRM with a dependable interface to ERP and inventory systems. This is the more common case.
Starting an ERP project when the requirement is a CRM extends the implementation by months and ties up specialists who are scarce.
For new implementations there is no defensible reason in 2026 to start on the 7 line. The version 8 interface has been rebuilt, works on mobile devices, and the architecture is designed for several years of service.
For existing installations the opposite applies. The 7 series is maintained as long-term support and there is no cut-off date for usability. Migration is economical when a larger initiative is planned in any case: a new interface, a data clean-up, a relaunch. As an isolated measure it rarely justifies the effort.
The same question has to be answered first in both cases: which customisations and plugins run under version 8? Some widely used extensions remain available for version 7 only. A customisation audit answers that before anything is installed.
The licence is; the project is not. Licence fees are exchanged for infrastructure, setup and operations. In the first year this exceeds the cost of a subscription and from roughly the third year falls below it. For a planned service life under two years, a subscription is the better calculation.
Compliance is not a property of software but the result of how a system is operated and documented. Open systems make the evidence easier to produce because hosting location and processing are traceable. YetiForce and CiviCRM ship dedicated tooling; SuiteCRM can be configured accordingly. The difference from a closed US cloud lies not in the assurance but in the ability to verify it.
EspoCRM for daily sales work, Twenty for users accustomed to modern web interfaces. SuiteCRM does not win this comparison point. Its strength lies in what happens when requirements exceed what an interface can express.
On the commercial use of AGPL systems, see the licensing section above.
Selecting an open-source CRM is not a feature decision but an architecture and operations decision. Four figures govern it: the number of users, the systems to be connected, the permitted locations for the data, and the intended service life. They narrow the field almost by themselves, in a number of cases away from SuiteCRM.
For mid-sized European companies with established B2B processes, requirements around data sovereignty and a horizon of several years, we consider SuiteCRM the most durable choice, subject to the limitations set out above.
Thirty minutes on user numbers, systems to connect, where the data may live and how long you intend to keep it. After that you know which system fits.
Let’s Make Things Happen
hello@codecouncil.de
Tel +49 6151 50 19172