Der erste Satz zu Open-Source-CRM lautet: kostenlos ist keines dieser Systeme.
Kostenlos ist die Lizenz. Server, Einrichtung, die Abbildung der eigenen Prozesse in Feldern und Workflows, die Migration der Altdaten, Updates und Betrieb bleiben Kostenpositionen, sie verschieben sich nur von der Lizenz zu Infrastruktur und Dienstleistung. Wer eine Rechnung streichen will, wird enttäuscht. Wer Kontrolle über System, Daten und Preisentwicklung zurückholen will, bekommt genau das.
Dieser Beitrag vergleicht elf Systeme, die 2026 in einer Auswahl ernsthaft in Frage kommen: Architektur, Lizenz, Kosten über fünf Jahre und Einsatzbereich. Am Ende steht eine Empfehlung für den deutschen Mittelstand, davor stehen vier Fälle, in denen sie nicht gilt.
| Ausgangslage | System | Begründung |
|---|---|---|
| Mittelstand, B2B, gewachsene Prozesse, Daten im EU-Rechtsraum | SuiteCRM | größte funktionale Breite, feingranulare Rechte, Standard-Frameworks, größter Dienstleistermarkt im DACH |
| Entwicklerteam, das das CRM als Teil des eigenen Stacks betreibt | Twenty | Node.js und React, API-First, sauberste Codebasis im Vergleich |
| Softwarehaus, das eine eigene Branchenlösung vermarkten will | Atomic CRM | 15.000 Zeilen Code, MIT-Lizenz, keine Veröffentlichungspflicht |
| Kleines Team ohne IT-Abteilung, Konfiguration statt Entwicklung | EspoCRM | umfangreichstes In-App-Studio, kürzeste Einführungszeit |
| Fertigung, Lager und Buchhaltung im selben System | Odoo | kein CRM, sondern ein ERP mit CRM-Modul |
| Verein, Stiftung, Verband | CiviCRM | Spenden, Beiträge, Mitglieder als Kernfunktionen |
Zwei Entwicklungen haben den Markt neu sortiert, und beide betreffen die Architektur, nicht den Funktionsumfang.
Der Bruch mit dem LAMP-Stack. Die etablierten Systeme stammen aus der Ära von PHP, MySQL, einem selbst entwickelten MVC-Framework und jQuery im Frontend. SuiteCRM, EspoCRM und Vtiger wurzeln dort.
Die technische Schuld dieser Codebasen zwingt die Projekte derzeit zu Re-Architekturen, die unterschiedlich weit gediehen sind. Die jüngere Generation, allen voran Twenty, setzt stattdessen auf Node.js, React und eine API-First-Architektur mit GraphQL. Der Unterschied ist keine Geschmacksfrage, er bestimmt die Kosten für Anpassungen über die Laufzeit des Systems.
Künstliche Intelligenz. Große Sprachmodelle nativ in ein selbst gehostetes CRM zu integrieren, erfordert Infrastruktur, die sich für die meisten Installationen nicht rechnet. Open-Source-Systeme liegen hier hinter kommerziellen SaaS-Plattformen zurück.
Die Antwort der neuen Generation ist nicht das eigene Modell, sondern Lesbarkeit für fremde: Twenty und Atomic CRM legen Manifest-Dateien in die Codebasis, mit denen KI-Agenten den Systemkontext erfassen und Quellcode zuverlässig ändern können. SuiteCRM und Vtiger setzen auf Plugins für Lead-Scoring und Sentiment-Analyse, die überwiegend kostenpflichtig sind.
| System | Stack | Lizenz | Geschlossene kommerzielle Verwertung |
|---|---|---|---|
| SuiteCRM 8 | PHP 8.1, Symfony 6.4 / Angular / MySQL | AGPL-3.0 | nein, starkes Copyleft |
| Twenty | Node.js, Nest.js / React, TypeScript / PostgreSQL | AGPL-3.0 | nein |
| Atomic CRM | Supabase / React, shadcn/ui | MIT | ja |
| EspoCRM | PHP 8, Inhouse-Framework / Handlebars / MySQL | AGPL-3.0 | nein |
| Odoo CE | Python / OWL JS (Inhouse) / PostgreSQL | LGPLv3 | eingeschränkt |
| ERPNext | Python, Frappe / MariaDB | GPL-3.0 | nein |
| Krayin | PHP 8, Laravel / Vue.js / MySQL | MIT | ja |
| OroCRM | PHP 8, Symfony / Backbone.js / PostgreSQL | OSL-3.0 | nein |
| YetiForce | PHP, Vtiger-Fork / MySQL | YetiForce Public License | ja, MIT-basiert |
| Vtiger CE | PHP / MySQL | Vtiger Public License | eingeschränkt |
| CiviCRM | PHP, Drupal/WordPress / MySQL | AGPL-3.0 | nein |
Die Lizenz entscheidet darüber, ob ein Unternehmen seine Anpassungen für sich behalten darf. Sie kommt in Auswahlprozessen selten zur Sprache und wird regelmäßig zum Problem, wenn das Projekt schon läuft.
AGPL-3.0, verwendet von SuiteCRM, Twenty, EspoCRM und CiviCRM, ist die strengste Form des Copyleft. Sie schließt die Lücke der klassischen GPL: Änderungen am Quellcode sind auch dann zu veröffentlichen, wenn die Software ausschließlich über ein Netz bereitgestellt wird, also als Cloud-Dienst ohne Auslieferung einer Kopie.
Für den internen Einsatz im eigenen Unternehmen hat das keine praktische Folge, Anpassungen bleiben unbeschränkt möglich. Relevant wird die Klausel, sobald ein angepasstes System Dritten als Dienst angeboten wird. Für ein SaaS-Produkt auf AGPL-Basis ist eine juristische Prüfung vor der technischen Entscheidung ratsam.
MIT, verwendet von Atomic CRM und Krayin, stellt praktisch keine Bedingungen. Modifikation, Vertrieb und geschlossener Quellcode sind zulässig. Für Agenturen und Softwarehäuser, die eine eigene Branchenlösung vermarkten, ist das der ausschlaggebende Unterschied.
LGPLv3, verwendet von Odoo Community, nimmt eine Mittelstellung ein: dynamisch angebundene eigene Module bleiben proprietär, der Kern bleibt geschützt.
Für den häufigsten Fall, ein Unternehmen betreibt ein CRM für die eigene Belegschaft, spielt die Lizenzwahl keine Rolle. Genau deshalb lohnt die kurze Prüfung, ob dieser Fall vorliegt.
1 · Software und Abonnements. Bei echten Community-Editionen entfällt der Posten. Bei Open-Core-Modellen nicht: Odoo und Vtiger halten Funktionen für die kostenpflichtigen Editionen zurück, Odoo ab rund 7,25 US-Dollar pro Nutzer und Monat, Vtiger ab 12 US-Dollar (Stand 09/2026). Was in der Evaluierung frei aussieht, kann im Projektverlauf zur Preisliste werden.
2 · Infrastruktur. Server, Speicher, Backup, Monitoring und Absicherung. Die Anforderungen sind mit den neuen Versionen gestiegen: SuiteCRM 8 verlangt laut Herstellerdokumentation mindestens 4 GByte RAM, empfohlen sind 8 GByte und SSD-Speicher. SuiteCRM 7 kam mit 2 GByte aus.
3 · Einrichtung und Anpassung. Der größte Posten des ersten Jahres. Erfahrungswerte aus dem DACH-Mittelstand liegen beim Anderthalb- bis Vierfachen dessen, was eine vergleichbare SaaS-Lizenz im selben Zeitraum gekostet hätte. Bei architektonisch aufwendigen Systemen wie Odoo oder OroCRM steigt der Faktor, weil spezialisierte Entwickler nötig und am Markt knapp sind.
4 · Schnittstellen. Anbindungen an ERP, Warenwirtschaft, Shop und Buchhaltung. Fertige Konnektoren zu Cloud-Diensten sind in der Open-Source-Welt die Ausnahme, die Integration läuft meist über die REST-API und erzeugt damit Entwicklungs-, Test- und Wartungsaufwand.
5 · Personal und Einführung. Der Posten, den Kalkulationen am häufigsten unterschätzen. Bei 100 bis 200 Nutzern binden Projekte dieser Größe über 12 bis 18 Monate ein bis zwei Vollzeitäquivalente im Projektmanagement, dazu 30 bis 60 Prozent der Arbeitszeit von vier bis zehn Kernnutzern. Für den laufenden Betrieb ab dem zweiten Jahr sind 0,5 bis 1,5 Vollzeitäquivalente anzusetzen. Der Aufwand fällt niedriger aus, wenn die Administratoren geschult sind, statt sich das System nebenbei zu erschließen.
6 · Support, Wartung, Upgrades. Sicherheitspatches sind Routine, Hauptversionswechsel sind es nicht. Der Wechsel von SuiteCRM 7 auf 8 ist ein eigenes Projekt mit eigener Planung, kein Update.
In den ersten beiden Jahren rechnet sich das Modell in der Regel nicht, die Einführung verbraucht die eingesparte Lizenz.
Ab dem dritten Jahr kehrt sich das Verhältnis um, und zwar aus zwei Richtungen. Die Anfangsinvestition ist abgeschrieben, während SaaS-Verträge marktüblich um drei bis sieben Prozent pro Jahr steigen, über fünf Jahre also 16 bis 40 Prozent Aufschlag erzeugen, ohne dass ein Nutzer hinzugekommen wäre.
Für selbst betriebene Installationen werden langfristig Werte unter 15 US-Dollar pro Nutzer und Monat berichtet, für vergleichbare SaaS-Modelle 60 bis über 100 US-Dollar.
Daraus folgt eine klare Bedingung: Open Source rechnet sich bei langer Nutzungsdauer und hoher Nutzerzahl. Für einen Horizont von 18 Monaten und sechs Nutzer ist ein Abonnement die günstigere Wahl.
SuiteCRM entstand 2014, nachdem SugarCRM seine offene Edition eingestellt hatte, und gilt seither als Referenz für funktionsreiche Open-Source-CRMs.
Das System deckt Vertrieb, Marketing, Service und Projekte ab, bringt eine Workflow-Engine mit und mit der Security Suite ein Rechte- und Rollensystem, das in dieser Granularität außerhalb von Salesforce selten ist. Sichtbarkeit von Datensätzen nach Abteilung, Region und Rolle ist hier Konfiguration und kein Entwicklungsauftrag.
Mit Version 8 hat SalesAgility die Architektur ausgetauscht: Symfony 6.4 LTS im Backend, Angular im Frontend, REST und GraphQL als Schnittstellen. Die Codebasis der Version 7 läuft als Legacy-Schicht unterhalb weiter, damit die über ein Jahrzehnt gewachsenen Erweiterungen nutzbar bleiben. Dieser Kompromiss ist der Grund für die aufwendige Migration und für die gemischte Bewertung der Entwicklerfreundlichkeit.
Stärken: funktionale Breite, Rechtesystem, Ökosystem, Standard-Frameworks. Schwächen: Oberfläche in Teilen veraltet, Performance bei großen Datenmengen und komplexen Subpanels, Migrationsaufwand von 7 auf 8.
Twenty ist die konsequenteste Umsetzung der neuen Generation: Node.js und Nest.js im Backend, React und TypeScript im Frontend, PostgreSQL und Redis als Datenschicht, GraphQL und REST als Schnittstellen. Objekte und Felder werden in der Oberfläche definiert, die passenden API-Endpunkte entstehen daraufhin automatisch.
Im Entwickler-Benchmark von Marmelab führt das System das Feld an. Es ist zudem das erste CRM, das KI-Agenten über Manifest-Dateien den Zugriff auf den eigenen Code erleichtert.
Die Einschränkungen sind operativer Natur. Eine Installationsdatei gibt es nicht, das Deployment setzt Git, Docker-Compose und Erfahrung im Datenbankbetrieb voraus. In der Community-Edition fehlen Teile des Dashboardings, die Listenansichten sind funktional noch begrenzt. Twenty eignet sich für Organisationen, die Software entwickeln, und nur eingeschränkt für Organisationen, die Software einsetzen.
EspoCRM ist schlank, schnell und übersichtlich. Das In-App-Studio erlaubt Administratoren, Datenmodell, Layouts, Rechte und Workflows ohne Quellcode zu ändern, was den Anteil externer Entwicklungsleistung deutlich senkt. Für Teams ohne eigene IT-Abteilung ist das System oft binnen Tagen produktiv.
Unterhalb der Oberfläche liegen die Nachteile: ein eigenes PHP-Framework, ein eigenes ORM und ein Frontend auf Handlebars-Basis. Externe Entwickler können vorhandenes Wissen aus Laravel, Symfony oder React nicht anwenden, die Dokumentation ist lückenhaft und die Testabdeckung gering. Hinzu kommt ein Konzentrationsrisiko: Das Projekt wird wesentlich von einem einzelnen Kernentwickler getragen.
YetiForce ist ein Vtiger-Fork, der von einem polnischen Unternehmen weiterentwickelt wird, und eines der funktionsreichsten Systeme im Vergleich: über 80 Module und rund 90 Konfigurationsbereiche, dazu Werkzeuge für DSGVO-Nachweise und LDAP-Integration.
Der Preis dafür ist Komplexität. Die Oberfläche ist stark datengetrieben, die Konfigurationsmöglichkeiten überfordern kleine Teams, und die Dokumentation setzt für eigene Module ein Studium des Quellcodes voraus.
Vtiger stammt ebenfalls aus der SugarCRM-Linie, weist über fünf Millionen Downloads auf und verfügt über eine der ältesten Communities im Feld. Marketing-Automatisierung und E-Mail-Integration sind solide, das Plugin-Angebot ist groß. Navigation, Oberfläche und mobile Anwendung fallen gegenüber der neueren Konkurrenz deutlich ab.
Odoo ist keine CRM-Software, sondern eine modulare Business-Suite auf Python-Basis. Das CRM-Modul bietet ein visuelles Pipeline-Management, Multi-Channel-Anbindung und eine native mobile App. Der eigentliche Wert entsteht an der Schnittstelle: Aus einer gewonnenen Verkaufschance entstehen Produktionsauftrag und Rechnung ohne Systemwechsel.
Die technischen Kosten sind erheblich. Odoo nutzt mit OWL JS ein eigenes Frontend-Framework, die Codebasis umfasst über 200.000 Commits bei schwankender Codequalität, und Versionswechsel gelten in der Community als fehleranfällig. Anpassungen erfordern auf Odoo spezialisierte Python-Entwickler. Zudem sind Funktionen der Enterprise-Edition vorbehalten.
ERPNext verfolgt denselben Ansatz auf anderer Basis: Python, MariaDB und das hauseigene Frappe-Framework. Das Reporting ist umfassend, die Integration eng, die Workflows sind starr. Für ein reines CRM-Vorhaben ist das System überdimensioniert, die Einarbeitung in Frappe ist für Entwickler ohne Vorerfahrung langwierig.
Atomic CRM von Marmelab umfasst rund 15.000 Zeilen Code und stützt sich fast vollständig auf Standardbibliotheken: React und shadcn/ui im Frontend, Supabase als Backend, SSO und SAML inklusive. Unter MIT-Lizenz ist es die schnellste Basis für eine eigene Branchenlösung. Als fertiges CRM für ein Anwenderunternehmen ist es nicht gedacht.
Krayin kombiniert Laravel im Backend mit Vue.js im Frontend und steht unter MIT-Lizenz. Für Teams, die ohnehin im Laravel-Ökosystem arbeiten, ist der Einstieg entsprechend kurz. Aus Anwendersicht sind die Oberfläche träge, die Informationsdichte in Listen gering und die Filterfunktionen begrenzt.
OroCRM stammt von den Gründern der E-Commerce-Plattform Magento, basiert auf Symfony und ist auf komplexe Kundenhierarchien und Omnichannel-Vertrieb im B2B ausgelegt. Mit rund 1,3 Millionen Zeilen Code und einem Frontend auf jQuery- und Backbone-Basis ist der Einarbeitungsaufwand hoch. Das System lohnt sich nur bei entsprechend spezifischen Anforderungen.
CiviCRM ist kein Vertriebssystem, sondern ein Constituent Relationship Management für Mitglieder, Spenden, Beiträge und ehrenamtliche Arbeit. In Deutschland ist es bei Vereinen und Verbänden verbreitet, unter anderem wegen der Erweiterungen für DSGVO-Nachweise und Verfahrensverzeichnisse.
Vorbemerkung in eigener Sache: Wir arbeiten mit SuiteCRM. Die folgenden Argumente sind entsprechend interessengeleitet und deshalb so formuliert, dass sie überprüfbar sind.
Funktionale Breite auf Standard-Technik. Das ist der im Vergleich am häufigsten übersehene Punkt. EspoCRM, Odoo und ERPNext setzen auf selbst entwickelte Frameworks. Anpassungen erfordern dort Entwickler, die genau dieses Framework beherrschen, und dieser Personenkreis ist klein und teuer. Der vermiedene Lizenz-Lock-in wird durch eine Abhängigkeit vom Personalmarkt ersetzt.
SuiteCRM ist mit dem Wechsel auf Symfony (v. <8) und Angular (v. 8+) den umgekehrten Weg gegangen: Wer Symfony beherrscht, kann an SuiteCRM arbeiten. Das ist keine Frage des Entwicklerkomforts, sondern der Verhandlungsposition gegenüber jedem Dienstleister, uns eingeschlossen.
Vollständige Community-Edition. SuiteCRM hält keine Module für eine kostenpflichtige Edition zurück. Bei Odoo und Vtiger ist das anders, und die Grenze wird meist erst im laufenden Projekt sichtbar.
Rechtemodell für gewachsene Organisationen. Unterschiedliche Sichtbarkeit nach Vertriebsgebiet, Rolle und Hierarchie ist in der Security Suite Konfiguration. In den meisten anderen offenen Systemen ist derselbe Fall ein Entwicklungsauftrag.
AGPL und Selbstbetrieb. Der Betriebsort ist frei wählbar. Für Behörden und regulierte Branchen ist das inzwischen weniger eine Haltung als eine Vergabeanforderung, in der quelloffen und EU-gehostet häufig gemeinsam auftauchen.
Verfügbarkeit von Dienstleistern. Über ein Jahrzehnt Verbreitung bedeutet einen Erweiterungsmarkt, dokumentierte Lösungswege in den Foren und im DACH-Raum genug Anbieter, um den Dienstleister wechseln zu können. Bei Twenty und Atomic CRM ist dieser Markt derzeit klein.
Vier Einschränkungen gehören zur Entscheidungsgrundlage.
Die Entwicklerfreundlichkeit ist bestenfalls durchschnittlich. Im Benchmark von Marmelab erreicht SuiteCRM 8 fünf von zehn Punkten, Twenty neun. Die Dokumentation für das Angular-Frontend ist dünn, die Legacy-Schicht ist ein Kompromiss, und ohne korrekt konfigurierten Opcache reagiert das System träge. Der Befund ist nachvollziehbar.
Version 8 erreicht die funktionale Parität mit Version 7 noch nicht. Das Studio-Modul für visuelle Anpassungen verhält sich bei stark angepassten Installationen inkonsistent, verbreitete Community-Plugins stehen weiterhin nur für Version 7 zur Verfügung. Dass die 7er-Reihe als Long-Term-Support gepflegt wird, ist konsequent.
Der Wechsel von 7 auf 8 ist ein Migrationsprojekt. Er läuft als Neuinstallation der Version 8, in die das alte Systemverzeichnis kopiert wird, gefolgt von Konsolenbefehlen für Datenbank und Metadaten.
Die Dokumentation weist auf wiederkehrende Fehlerbilder hin: fehlerhafte Dateirechte nach Ausführung unter dem falschen Benutzerkonto, ungültige CSRF-Token aus veralteten Cookies und Fehler, die auf einen nicht geleerten Symfony-Cache zurückgehen.
Das System ist nicht für den Selbstbetrieb ohne Vorkenntnisse gedacht. Wer ein CRM sucht, das binnen weniger Tage ohne Begleitung produktiv läuft, ist mit EspoCRM oder einem SaaS-Abonnement besser bedient. SuiteCRM spielt seine Stärken dort aus, wo die Prozesse spezifisch genug sind, dass eine Anpassung des Systems günstiger ist als eine Anpassung der Organisation.
Die Konsequenz aus dem Vergleich lautet daher nicht, SuiteCRM sei für alle die richtige Wahl. Sie lautet: SuiteCRM ist die richtige Wahl für die oben genannten Fälle, und die Einführung sollte begleitet werden, bis das eigene Team den Betrieb übernehmen kann.
Der Vergleich beider Systeme kommt in fast jedem Auswahlprozess vor, obwohl sie unterschiedliche Aufgaben lösen.
Ein CRM verwaltet Beziehungen: Gesprächsverlauf, nächste Schritte, Abschlusswahrscheinlichkeit. Ein ERP verwaltet Ressourcen: Bestand, Fertigung, Zahlungsstatus. Odoo ist ein ERP mit CRM-Modul, SuiteCRM ein CRM ohne ERP-Anspruch.
Die Entscheidung fällt deshalb nicht am Funktionsumfang, sondern an einer Frage: Muss aus einer gewonnenen Verkaufschance automatisch ein Produktionsauftrag, ein Lieferschein oder eine Rechnung entstehen?
Lautet die Antwort ja, ist Odoo die passende Basis. Dann ist allerdings ein ERP-Projekt zu planen, mit spezialisierten Python-Entwicklern und mit dem Aufwand, den Versionswechsel in diesem Umfeld erfahrungsgemäß erzeugen.
Lautet sie nein, weil Buchhaltung und Warenwirtschaft etabliert sind und bleiben sollen, wird kein zweites ERP benötigt, sondern ein CRM mit einer belastbaren Schnittstelle zu ERP und Warenwirtschaft. Das ist der häufigere Fall.
Ein ERP-Projekt zu starten, obwohl der Bedarf ein CRM ist, verlängert die Einführung um Monate und bindet Spezialisten, die am Markt knapp sind.
Für Neueinführungen gibt es 2026 keinen belastbaren Grund mehr, auf der 7er-Linie zu starten. Die Oberfläche der Version 8 ist neu entwickelt, auf mobilen Geräten nutzbar, und die Architektur ist auf mehrere Jahre angelegt.
Für bestehende Installationen gilt das Gegenteil. Die 7er-Reihe wird als Long-Term-Support gepflegt, ein Stichtag für das Ende der Nutzbarkeit existiert nicht. Ein Umstieg ist dann wirtschaftlich, wenn ohnehin ein größeres Vorhaben ansteht: eine neue Schnittstelle, eine Datenbereinigung, ein Relaunch. Als isolierte Maßnahme rechtfertigt er den Aufwand selten.
In beiden Fällen ist dieselbe Frage vorab zu klären: Welche Anpassungen und Plugins laufen unter Version 8? Ein Teil der verbreiteten Erweiterungen ist weiterhin nur für Version 7 verfügbar. Ein Customization-Audit beantwortet das vor der Installation.
Die Lizenz ja, das Projekt nicht. Lizenzgebühren werden gegen Infrastruktur, Einrichtung und Betrieb getauscht. Im ersten Jahr liegt das über den Kosten eines Abonnements, ab etwa dem dritten Jahr darunter. Bei einer geplanten Nutzungsdauer von unter zwei Jahren ist ein Abonnement die rechnerisch bessere Wahl.
Konformität ist keine Eigenschaft einer Software, sondern das Ergebnis von Betrieb und Dokumentation. Offene Systeme erleichtern den Nachweis, weil Hosting-Ort und Verarbeitung nachvollziehbar sind. YetiForce und CiviCRM bringen dafür eigene Werkzeuge mit, SuiteCRM lässt sich entsprechend konfigurieren. Der Unterschied zu einer geschlossenen US-Cloud liegt nicht in der Zusage, sondern in der Prüfbarkeit.
EspoCRM im Vertriebsalltag, Twenty für Anwender, die moderne Weboberflächen gewohnt sind. SuiteCRM gewinnt diesen Vergleichspunkt nicht. Seine Stärke liegt in dem, was folgt, wenn die Anforderung die Möglichkeiten der Oberfläche übersteigt.
Zur kommerziellen Nutzung von AGPL-Systemen siehe den Abschnitt zu den Lizenzen.
Die Auswahl eines Open-Source-CRM ist keine Funktionsentscheidung, sondern eine Architektur- und Betriebsentscheidung. Maßgeblich sind vier Angaben: die Zahl der Nutzer, die anzubindenden Systeme, die zulässigen Speicherorte der Daten und die geplante Nutzungsdauer. Aus ihnen ergibt sich die Vorauswahl weitgehend von selbst, in einem Teil der Fälle gegen SuiteCRM.
Für den deutschen Mittelstand mit gewachsenen B2B-Prozessen, Anforderungen an die Datenhoheit und einem Horizont von mehreren Jahren halten wir SuiteCRM für die tragfähigste Wahl, mit den oben benannten Einschränkungen.
Dreißig Minuten über Nutzerzahl, anzubindende Systeme, Speicherort der Daten und geplante Nutzungsdauer. Danach wissen Sie, welches System für Sie in Frage kommt.
© 2026 • codecouncil
Lassen Sie uns die Dinge ins Rollen bringen
hello@codecouncil.de
Tel +49 6151 50 19172