Odoo Hosting im Vergleich: Odoo Online, Odoo.sh oder Eigenhosting

Die drei Varianten in einem Satz

Odoo Online ist die SaaS-Variante direkt bei Odoo: Sie melden sich an, bekommen eine gehostete Datenbank und nutzen den Standard plus Studio. Odoo.sh ist die Entwicklungs- und Betriebsplattform von Odoo: gleiche Infrastruktur, aber mit Git-Anbindung, eigenen Modulen, Staging-Zweigen und Shell-Zugriff. Eigenhosting (On-Premise)bedeutet, dass Sie Odoo auf eigenem Server oder bei einem Hoster Ihrer Wahl betreiben, mit voller Kontrolle und voller Verantwortung.

Die Editionsfrage (Community oder Enterprise) ist davon getrennt zu betrachten, hängt aber zusammen: Odoo Online und Odoo.sh setzen Enterprise voraus. Details dazu stehen im Preisvergleich Community vs. Enterprise.

Odoo Online: schnell, aber eng

Odoo Online ist der bequemste Einstieg. Hosting, Updates und Backups sind im Lizenzpreis enthalten, es gibt nichts zu administrieren. Der Preis dafür ist die Grenze bei Anpassungen: eigener Python-Code und fremde Module lassen sich nicht installieren. Was Studio, Automatisierungen und Server-Actions abdecken, geht. Alles darüber hinaus nicht.

In der Praxis funktioniert das gut für Handels- und Dienstleistungsbetriebe mit klaren Standardprozessen. Sobald eine Schnittstelle zu einem Branchensystem, ein eigener Beleg-Workflow oder eine spezielle Preisfindung dazukommt, wird es eng, und ein Wechsel auf Odoo.sh steht an. Der Wechsel ist möglich, kostet aber ein Migrationsprojekt.

Das größte Risiko: erzwungene automatische Upgrades

Der Punkt, über den vor der Entscheidung selten gesprochen wird: Bei Odoo Online bestimmen nicht Sie, wann Ihre Version wechselt. Odoo hält die SaaS-Umgebungen auf aktuellen Ständen und hebt Datenbanken nach eigenem Zeitplan an. Sie bekommen eine Ankündigung und ein Zeitfenster, kein Vetorecht. Auf Odoo.sh und On-Premise legen Sie den Termin selbst fest, testen das Upgrade vorher in einem Staging und gehen live, wenn Ihr Team bereit ist.

Seit Odoo häufiger veröffentlicht, betrifft das nicht mehr nur die jährliche Major-Version. Zwischen den großen Sprüngen (19 auf 20) stehen Minor-Releases wie 19.1, 19.2 oder 19.4, und die sind nicht rein kosmetisch. Funktionen werden umgebaut, in andere Apps verschoben oder ganz entfernt. Ein konkretes Beispiel: Die Außendienst-Funktionalität, mit der Teams in 19.1 gearbeitet haben, wurde mit 19.2 umgeräumt. Eingespielte Abläufe lagen plötzlich an anderer Stelle und verhielten sich anders. Technisch war nichts kaputt, aber die tägliche Arbeitsweise hatte sich über Nacht geändert.

Die praktischen Folgen bei Odoo Online: kein Testlauf auf einer Kopie Ihrer Daten, keine Möglichkeit, bis nach dem Monatsabschluss oder der Jahresprüfung zu verschieben, Schulungsunterlagen und Prozessdokumentation, die ohne Vorwarnung veralten, sowie Studio-Anpassungen und Automatisierungen, die gegen geänderte Ansichten und Felder nachgezogen werden müssen. Wenn eine Änderung eine Gewohnheit bricht und nicht die Software, wird der Support zu Recht antworten, dass alles wie vorgesehen funktioniert.

So gehen Sie damit um: Halten Sie Ihre kritischen Prozesse und Studio-Änderungen schriftlich fest, verfolgen Sie die Release Notes der Apps, von denen Sie wirklich abhängen, und prüfen Sie nach jedem Upgrade die Auswertungen und Exporte nach, die für DATEV und GoBD relevant sind. Wer eine ungeplante Änderung in einem geschäftskritischen Prozess nicht verkraftet, gehört auf Odoo.sh oder On-Premise, wo das Upgrade ein Projekt mit Termin, Testlauf und Rückweg ist und keine Benachrichtigung.

Odoo.sh: der Standardfall für den Mittelstand

Odoo.sh kombiniert Cloud-Komfort mit Entwicklerfreiheit. Jeder Git-Branch bekommt eine eigene Umgebung, Produktion, Staging und Entwicklung sind sauber getrennt, Backups laufen automatisch und lassen sich per Klick in ein Staging zurückspielen. Genau dieser Punkt macht Testläufe vor einem Versionsupgrade oder vor größeren Änderungen erst realistisch.

Abgerechnet wird nach Workern (parallele Verarbeitungskapazität), Speicher und Staging-Zweigen, zusätzlich zu den Nutzerlizenzen. Für ein typisches KMU mit 10 bis 25 Nutzern reicht lange ein kleines Setup. Wächst die Last, skaliert man Worker nach oben, ohne die Plattform zu wechseln.

Der wichtigste nicht-technische Vorteil: Ihr Partner arbeitet nachvollziehbar über Git. Sie sehen, welche Änderung wann von wem kam, und sind bei einem Partnerwechsel nicht auf gutes Zureden angewiesen. Wie wir bestehende Systeme übernehmen, beschreibt die Methodik zur Projektübernahme.

On-Premise: Kontrolle gegen Aufwand

Eigenhosting heißt: Sie wählen Hoster und Serverstandort frei, kontrollieren die Datenbank vollständig und können jede Erweiterung installieren. Dafür verantworten Sie Betriebssystem, PostgreSQL, Sicherheitsupdates, Reverse Proxy, Zertifikate, Monitoring und vor allem ein Backup- und Wiederherstellungskonzept, das regelmäßig getestet wird.

Der Serverpreis ist selten das Problem, ein passender Root-Server liegt oft im niedrigen dreistelligen Bereich pro Monat. Der Aufwand steckt in der Betreuung. Ohne interne IT oder einen Dienstleister mit klarem SLA wird On-Premise schnell zum Risiko, besonders bei Versionsupgrades, die hier vollständig in Ihrer Verantwortung liegen.

DSGVO, GoBD und Serverstandort

Alle drei Varianten lassen sich rechtskonform betreiben. Odoo bietet europäische Rechenzentren und einen Auftragsverarbeitungsvertrag an, damit ist die DSGVO-Frage für Online und Odoo.sh in der Regel abgedeckt. Wer vertraglich einen deutschen Serverstandort zusichern muss, landet bei On-Premise oder einem deutschen Hoster.

Für die GoBD ist die Hosting-Variante zweitrangig. Entscheidend sind Unveränderbarkeit, Sperrdaten, Protokollierung und eine Verfahrensdokumentation, in der auch Backup und Wiederherstellung beschrieben sind. Mehr dazu im GoBD-Artikel und beim DATEV-Export.

Entscheidungshilfe

• Keine eigenen Module geplant, kleines Team, schneller Start: Odoo Online.
• Schnittstellen, eigene Module oder ein Partner, der entwickelt: Odoo.sh.
• Vorgabe zum Serverstandort, eigene IT-Abteilung oder sehr viele Nutzer: On-Premise.
• Unsicher? Starten Sie auf Odoo.sh. Der Weg von dort nach On-Premise ist deutlich einfacher als der Weg aus Odoo Online heraus.

Wechsel zwischen den Varianten

Technisch ist jede Richtung möglich, praktisch unterscheidet sich der Aufwand deutlich. Von Odoo Online nach Odoo.sh ist ein Datenbank-Dump plus Aufbau der Umgebung, überschaubar. Von Odoo.sh nach On-Premise brauchen Sie zusätzlich die komplette Betriebsinfrastruktur. Der Weg zurück in Odoo Online funktioniert nur, wenn Sie sämtliche Anpassungen entfernen, deshalb lohnt es sich, die Frage einmal richtig zu entscheiden statt zweimal halb.