Odoo Online zu Odoo.sh: Braucht die Integration den Wechsel?

11 Min. Lesezeit · 5. November 2026
Zuletzt geprüft 5. November 2026

Dein Lagerprojekt muss Daten mit Odoo austauschen. Im Angebot steht bereits „Wechsel zu Odoo.sh“, obwohl noch niemand gezeigt hat, welcher Teil des Ablaufs in der heutigen Umgebung nicht funktioniert. Der Wechsel kann sinnvoll sein. Es fehlt aber der Nachweis, der ihn mit einer freigegebenen fachlichen Anforderung verbindet.

Wechsle von Odoo Online zu Odoo.sh, wenn eine nachgewiesene Anforderung Fähigkeiten benötigt, die deine aktuelle Umgebung nicht bereitstellt und die das vorgeschlagene Ziel unterstützt. Kläre Versionspfad und Betriebsverantwortung, bevor du die Migration terminierst. Erfüllt die vorhandene Konfiguration oder eine freigegebene externe Integration den Bedarf, bleibt Odoo Online eine mögliche Lösung.

Quellenstand: 5. November 2026. Dieser Entscheidungsleitfaden nutzt offizielle Odoo-20.0-Quellen und die Odoo.sh-FAQ. Das Lagerbeispiel und die zwölf herunterladbaren Fälle sind erfundene Planungshilfen. Wir haben weder eine Datenbank migriert noch ein Modul installiert oder die vorgeschlagenen Abnahmeprüfungen ausgeführt.

Welche Anforderung würde den Wechsel rechtfertigen?

Beschreibe die Geschäftsregel unabhängig von der vorgeschlagenen Technik. Zeige anschließend, welche Fähigkeit fehlt. „Lagerdaten austauschen“ ist zu allgemein, um einen Hosting-Wechsel zu begründen. Lege fest, wer die Aktion ausführen darf, welchen Datensatz sie betrifft und was nach ihrem Abschluss gelten muss.

Als erfundene Anforderung R-17 gilt: Ein Wareneingang darf nur freigegeben werden, wenn das Lieferantenzertifikat der dafür genehmigten Revision entspricht. Die Betriebsverantwortlichen wollen die Regel für die relevanten Benutzer- und Integrationswege durchsetzen. Das Beispiel trifft keine Aussage über ein konkretes Odoo-Modell, ein Feld oder eine installierte Quality-Konfiguration.

Die Klärung kann zu zwei Ergebnissen führen. Das Team zeigt eine vorhandene Konfiguration, die R-17 erfüllt. Oder eine geprüfte Lücke verlangt ein installierbares eigenes Python-Modul. Welcher Fall zutrifft, lässt sich nicht aus diesem Beispiel ableiten. Prüfe die tatsächliche Anwendung und das geforderte Verhalten.

Fragen, die eine Geschäftsanforderung mit der Hosting-Wahl verbinden
Frage	Benötigter Nachweis	Folge für die Entscheidung
Welches Geschäftsergebnis wird verlangt?	Freigegebene Regel sowie typische gültige und ungültige Fälle	Legt das Abnahmeziel fest
Erfüllt die aktuelle Umgebung die Regel?	Demonstration über die relevanten Zugangswege	Hält den Verbleib auf Online offen
Welche Fähigkeit fehlt genau?	Dokumentierte Lücke und geprüfte Konfigurationsalternativen	Grenzt die vorgeschlagene Erweiterung ab
Unterstützt das Ziel diese Erweiterung?	Geprüfte Laufzeit- und Deployment-Anforderungen	Bestimmt einen technisch geeigneten Hosting-Kandidaten
Kann die Datenbank rechtzeitig wechseln?	Genaue Version und unterstützter Migrationsweg	Zeigt Terminbeschränkungen
Wer übernimmt danach den Betrieb?	Benannte Verantwortung und nachgewiesener Zugriff	Macht die dauerhafte Verpflichtung sichtbar

Ein Vorschlag kann die ersten drei Fragen beantworten und trotzdem noch nicht freigabereif sein. Technischer Bedarf, Eignung der Plattform und Betriebsbereitschaft brauchen jeweils Nachweise. Halte offene Punkte sichtbar. Eine erfolgreiche Demonstration beantwortet nicht automatisch alle übrigen Fragen.

Kann die Integration auf Odoo Online bleiben?

Prüfe die erforderlichen unterstützten Operationen und die Konfiguration, bevor du den Host wechselst. Eine externe Komponente, die erlaubte Datensätze liest oder eine geeignete vorhandene Operation aufruft, beweist allein keinen Bedarf an einem eigenen Modul. Kläre Tarifberechtigung, Zugriffsrechte und Operation. Zeige dann das gewünschte Verhalten mit den tatsächlich eingesetzten Versionen.

Die API-Referenz für Odoo 20 ordnet externen API-Zugriff dem Custom-Tarif zu. Eine fehlende Tarifberechtigung ist zunächst kaufmännisch zu klären, bevor sie als Hosting-Grenze gilt.

Eine Lagerstatusanzeige benötigt vielleicht nur einen erlaubten Lesezugriff auf ausgewählte Informationen. Ihr Abnahmenachweis sollte die richtigen Datensätze für die vorgesehene Identität, die benötigten Felder und die verursachte Arbeitslast zeigen. Dafür muss noch kein neues Modul vorausgesetzt werden.

Für ausgehende Ereignisse beschreibt die Automatisierungsdokumentation eine Webhook-Aktion, die ausgewählte Datensatzfelder sendet. Zeige Eignung und Verfügbarkeit in deiner Konfiguration. Eine Funktionsbeschreibung ersetzt keinen Test der vollständigen Übertragung.

Der Leitfaden zu Odoo-API-Integrationsgrenzen behandelt Tarifberechtigung, Transaktionen und Protokolle im Detail. Beziehe diese Grenzen in die Verbindungsprüfung ein. Die Hosting-Entscheidung hält anschließend fest, welche Anforderung noch unerfüllt ist, falls überhaupt eine bleibt.

Wann verändert ein eigenes Modul die Entscheidung?

Ein belegter Bedarf an installierbarem Anwendungscode verändert die möglichen Deployment-Optionen. Benenne zuerst das kleinste fehlende Verhalten und warum die vorhandene Konfiguration es nicht liefert. Prüfe das vorgeschlagene Modul danach als dauerhaft zu wartende Softwareabhängigkeit mit Zuständigkeit und Abnahmekriterien. Erst dann folgt die Hosting-Wahl.

Die Dokumentation zu Odoo Online schließt eigene Module und Module aus dem Apps Store aus. Diese Grenze wird relevant, sobald der Bedarf an einem solchen Modul nachgewiesen ist.

Für R-17 sollte die Umsetzung sowohl ein akzeptiertes passendes Zertifikat als auch eine abgewiesene veraltete Revision zeigen. Prüfe jeden relevanten Zugangsweg, einschließlich der vorgesehenen Integrationsidentität. Eine Warnung auf dem Bildschirm genügt nicht, wenn die genehmigte Regel verlangt, den Wareneingang zu sperren.

Besteht die vorhandene Konfiguration diese Fälle, bewahre die Nachweise auf und prüfe den Modulvorschlag neu. Bleibt die Lücke, dokumentiere Erweiterungspunkt, erlaubte Aktionen und erwartetes Fehlerverhalten. Die Abnahmeprüfung für eigene Odoo-Module bietet ein separates Muster für Code und Verhalten. Sie belegt nicht, dass dieses konkrete Modul benötigt wird.

Halte optionale Komfortänderungen aus der Mindestbegründung für den Hosting-Wechsel heraus. Werden eine erforderliche Kontrolle und unabhängige Oberflächenwünsche vermischt, verschwimmt der Grund für den Wechsel. Erfasse zusätzliche Arbeit separat, damit der Auftraggeber bewusst über ihren Umfang entscheiden kann.

Unterstützt Odoo.sh den gesamten vorgeschlagenen Aufbau?

Prüfe neben dem Odoo-Modul auch dessen Laufzeitumgebung. Liste Hintergrundkomponenten, externe Verbindungen und vorausgesetzte Abhängigkeiten auf. Eine Plattform kann für die Anwendungserweiterung geeignet sein, während eine andere Komponente extern laufen muss. Kläre deren Platzierung, bevor du eine Lösung auf einem einzigen Host zusagst.

Die Odoo.sh-FAQ schließt zusätzliche dauerhaft laufende Prozesse und die beliebige Installation von Systempaketen aus. Vergleiche diese Grenzen mit der vorgesehenen Abhängigkeitsliste.

Angenommen, der Entwurf enthält einen ständig laufenden Listener für das Lager. Kläre, ob diese Komponente als unterstützter externer Dienst arbeiten kann und welches Team sie warten würde. Ein Odoo-Modul auf dem Zielhost gibt nicht automatisch auch die Laufzeit des Listeners frei.

Erstelle ein Deployment-Inventar mit einer Zeile je Komponente. Dokumentiere Zweck, erforderliche Rechte, Speicherbedarf über Neustarts hinweg, Kommunikationsmuster und Zuständigkeit. Bei einem Drittanbietermodul brauchst du Nachweise für die konkrete Revision und ihre Abhängigkeiten. Ein Produktname oder eine Vorführung auf einer anderen Installation belegt nicht die Kompatibilität deines Ziels.

Lässt sich eine notwendige Abhängigkeit nicht innerhalb der unterstützten Architektur betreiben, gehe zurück zur Entwurfsprüfung. Das Ergebnis kann eine verteilte Bereitstellung, eine andere Umsetzung oder ein anderes Hosting sein. Diese Klärung ist nützlich, bevor der Datenbankwechsel zum festen Termin wird.

Kann die Datenbank zum gewünschten Termin wechseln?

Prüfe die genaue Quellversion, bevor du einen Migrationstermin zusagst. Halte Ziel und unterstützten Weg dorthin fest. Trenne die Versionskompatibilität vom Aufwand für Modulanpassung, Verhaltensprüfung und fachliche Abnahme. Jeder dieser Punkte kann den Termin begrenzen, auch wenn die anderen geklärt wirken.

Odoos Anleitung zum Hosting-Wechsel verlangt für Online-Zwischenversionen zunächst das Upgrade auf die nächste Hauptversion. Falls diese noch nicht erschienen ist, muss auf sie gewartet werden.

Die neueste Versionsankündigung ersetzt keine Prüfung deiner Datenbankversion. Der Entscheidungsvermerk benötigt den beobachteten Stand, das Prüfdatum und den bestätigten Übertragungsweg. Ist dieser Weg noch nicht verfügbar, verschiebe die Migration und prüfe, welcher Teil des fachlichen Bedarfs inzwischen erfüllt werden kann.

Eine vorübergehende externe Integration kann infrage kommen, sofern sie die akzeptierte Anforderung erfüllt. Beschreibe sie nicht als gleichwertigen Ersatz, wenn die benötigte Kontrolle weiterhin fehlt. Halte fest, was jetzt geliefert wird und welche Fähigkeit gesperrt bleibt.

Für die spätere Generalprobe helfen die Abgleichsprüfungen für eine Odoo-Migration, die Nachweise am wiederhergestellten Ziel zu bestimmen. Ein versionskompatibler Import ist nur ein Teil der Abnahme. Der Fachbereich benötigt weiterhin korrekte Datensätze und funktionierende Abläufe.

Wer verantwortet das System nach dem Wechsel?

Benenne die Personen, die Codeänderungen genehmigen, Zugriffe verwalten und den Geschäftsablauf wiederherstellen können. Ihre Aufgaben müssen auch bei einem Anbieterwechsel eindeutig bleiben. Zur Hosting-Freigabe gehört deshalb die Betriebsübergabe: Ein neuer Deployment-Weg erzeugt Arbeit, die eine Funktionsvorführung niemandem zuweist.

Die Odoo.sh-Projektanleitung verwendet ein GitHub-Repository, eine Hauptversion und ein passendes Abonnement. Sie warnt, dass ein Import vorhandene Daten des Branches überschreibt.

Vorgeschlagene Übergabenachweise für das tatsächliche Projekt
Verantwortung	Nachweis vor Freigabe	Frage an die zuständige Person
Anwendungscode	Freigegebenes Repository, Revision und Abhängigkeitsinventar	Wer prüft die nächste Änderung und erhält die Kompatibilität?
Projekt und Zugangsdaten	Nachgewiesener Zugriff der verantwortlichen Administratoren	Behält das Unternehmen die Kontrolle, wenn ein Anbieter geht?
Fachliche Abnahme	Genehmigte Fälle und benannte Freigabeverantwortung	Wer entscheidet, ob die Lagerregel erfüllt ist?
Wiederherstellung und Umstellung	Nachweise der Generalprobe und geprüftes Wiederherstellungsverfahren	Wer darf den Wechsel stoppen und spätere Schreibvorgänge abgleichen?
Laufende Integration	Zuständigkeiten für Überwachung, Vorfälle und Änderungen	Wer übernimmt eine fehlgeschlagene Übertragung nach Projektende?

Das sind vorgeschlagene Projektkontrollen, keine zusätzlichen Garantien des Hosting-Anbieters. Prüfe Zugriffe über die tatsächlich unterstützte Kontoeinrichtung. Ein Repository-Name auf dem Papier genügt nicht, wenn das verantwortliche Unternehmen weder den Code abrufen noch die Änderungsberechtigten verwalten kann.

Verlange eine Schätzung, die Migration, Modulwartung und laufenden Betrieb getrennt ausweist. Der Leitfaden zu Umfang und Budget von Enterprise-Upgrades behandelt die vertragliche und kaufmännische Abgrenzung. Die Hostwahl legt nicht fest, welche Wartung ein Anbieter vertraglich übernommen hat.

Welche Nachweise gehören in den Entscheidungsvermerk?

Erfasse Anforderung, beobachtete Bedingung, vorgeschlagene Entscheidung und benötigte Abnahmenachweise. Offene Fälle bleiben offen. Die Vorlage enthält bewusst Gründe für den Verbleib, Gründe für eine Wechselprüfung und Gründe, die Terminplanung bis zur Klärung einer Abhängigkeit anzuhalten.

Zwölf vorgeschlagene Fälle; keiner wurde ausgeführt
Fall	Zu prüfende Bedingung	Vorgeschlagene Reaktion
H01	Unterstützter externer Lesezugriff auf den Status	Verbleib auf Online prüfen
H02	Fehlende Berechtigung für die externe API	Abonnementfrage klären
H03	Ausgehendes Ereignis passt zu einer vorhandenen Webhook-Aktion	Konfiguration demonstrieren
H04	Vorhandene Schreiboperation erzwingt die benötigte Regel	Verbleib mit dokumentierten Abnahmenachweisen prüfen
H05	Geprüfte Lücke benötigt ein eigenes Python-Modul	Odoo.sh und die übrigen Voraussetzungen prüfen
H06	Vorhandene Konfiguration erfüllt R-17	Nachweise der erfolgreichen Konfiguration bewahren
H07	Quellversion lässt sich nicht direkt übertragen	Bis zum unterstützten Übertragungsweg verschieben
H08	Nicht unterstützte Laufzeitabhängigkeit	Komponentenplatzierung oder Architektur prüfen
H09	Code- oder Projektverantwortung ist nicht zugewiesen	Betriebsübergabe anhalten
H10	Backup vorhanden, Wiederherstellung nicht nachgewiesen	Freigegebene Generalprobe abschließen
H11	Kompatibilität des Zielmoduls ungeprüft	Modulnachweise klären
H12	Generalprobe könnte unkontrollierte externe Effekte auslösen	Isolation vor dem Test nachweisen

Lade die Vorlage für Hosting-Entscheidung und Nachweise herunter. Jede Zeile hat den Status NOT_RUN, die Regelgenehmigung PENDING und leere Istnachweise. Die vorgeschlagene Entscheidung ist eine zu prüfende Annahme, weder eine Migrationsfreigabe noch ein natives Kompatibilitätsergebnis.

Ergänze für jeden zutreffenden Fall die beobachtete Konfiguration oder Revision und die Abnahmenachweise. Trifft ein Fall nicht zu, dokumentiere den Grund und die zustimmende Person. Bewahre eine unveränderte Vorlage auf. So können spätere Prüfer vorgeschlagene Kontrollen von tatsächlich erbrachten Nachweisen unterscheiden.

Was würden wir vor der Terminplanung freigeben?

Gib eine konkrete Anforderungslücke, einen unterstützten Zielentwurf und eine personell besetzte Übergabe frei. Versionspfad und Umfang der Generalprobe müssen einen belastbaren Plan erlauben. Erfüllt die heutige Konfiguration den Bedarf bereits, dokumentiere dieses Ergebnis und behalte die kleinere Bereitstellung bei, bis ein weiterer belegter Bedarf die Entscheidung verändert.

Der Leitfaden zur Technologieauswahl unterstützt die allgemeinere Bewertung von Umsetzungsoptionen. Die Twinsoft-AI-Fallstudie liefert getrennten Projektkontext. Sie belegt nicht, dass dieses Lager- oder Hosting-Szenario umgesetzt wurde.

Wavects Technologieberatung macht aus einer Hosting-Empfehlung einen prüfbaren Umfang. Besprich deine Odoo-Hosting-Entscheidung mit dem benötigten Ablauf, der aktuellen Version und der vorgeschlagenen Erweiterung.

Fragen zum Wechsel von Odoo Online zu Odoo.sh

Benötigt ein externer n8n-Workflow automatisch Odoo.sh?

Der Name des Orchestrators begründet noch keine Deployment-Anforderung. Bestimme die benötigten Operationen und prüfe, ob die aktuelle autorisierte Konfiguration sie unterstützt. Verlangt der Entwurf ein neues installierbares Odoo-Modul, untersuche diese Lücke ausdrücklich. Halte Konnektorkompatibilität, Durchsetzung der Geschäftsregel und Betriebsverantwortung im Abnahmenachweis fest, statt sie aus dem Werkzeugnamen abzuleiten.

Ist eine Studio-Änderung dasselbe wie ein eigenes Modul?

Lass dir zeigen, was konfiguriert und was als Anwendungscode installiert werden soll. Beschreibe die konkrete Änderung und ihre Wartungsanforderungen, statt alle Anpassungen in dieselbe Kategorie zu stecken. Die Hosting-Wahl folgt dem erforderlichen Umsetzungsweg, nachdem Alternativen demonstriert wurden. Dokumentiere dabei den Umfang und die Nachweise seiner Kompatibilität.

Kann eine Modulvorführung die Hosting-Entscheidung abschließen?

Sie beantwortet nur die vorgeführten Fälle in der gezeigten Umgebung. Prüfe Zugangswege, abgewiesene Aktionen, Zielabhängigkeiten und Codeversion. Kläre danach Quellversion, Betriebsverantwortung und Generalprobe. Eine erfolgreiche Funktionsvorführung liefert einen nützlichen Nachweis, ersetzt aber nicht die gesonderte Abnahme der produktiven Migration und ihrer laufenden Wartung durch die zuständigen Verantwortlichen.

Genügt ein heruntergeladenes Backup für die Rückfallfreigabe?

Eine Datei zeigt noch nicht, dass Wiederherstellung und fortgesetzter Geschäftsablauf die Anforderung erfüllen. Probe das freigegebene Verfahren in einer kontrollierten Umgebung und lege fest, wie Schreibvorgänge nach der Umstellung behandelt werden. Dokumentiere Entscheidungsverantwortung und Abbruchbedingungen. Dieser Beitrag enthält weder eine ausgeführte Wiederherstellung noch eine gemessene Wiederherstellungsdauer.

Was sollte die Schätzung eines Partners enthalten?

Verlange die nachgewiesene Anforderungslücke, die vorgeschlagene Umsetzung, Versionsannahmen und benannte Abnahmearbeit. Trenne die Hosting-Verpflichtung vom Migrationsaufwand und der späteren Modul- oder Integrationswartung. Markiere unklare Abhängigkeiten und kaufmännische Abdeckung zur Bestätigung. Eine brauchbare Schätzung zeigt die offenen Entscheidungen, statt sie in einer einzigen Migrationsposition zu verstecken.

Darf die Hosting-Wahl während der Klärung offenbleiben?

Ja, wenn die Klärung ein konkretes Ergebnis liefern soll: eine geprüfte Anforderung und Nachweise für mögliche Umsetzungen. Lege Entscheidungspunkt und Zuständigkeit fest. Zeige dann die Konfiguration oder ihre Lücke, bevor du einen Wechsel beauftragst. Vorübergehende Arbeit bleibt innerhalb des genehmigten Umfangs; noch unerfüllte notwendige Anforderungen werden ausdrücklich dokumentiert.