diff --git a/de/odoo-community-upgrade.html b/de/odoo-community-upgrade.html new file mode 100644 index 0000000..c295cc6 --- /dev/null +++ b/de/odoo-community-upgrade.html @@ -0,0 +1,887 @@ + + + + + + Odoo Community Upgrade — für Sie übernommen | ODOO4projects + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ ODOO4projects + +
+
+
+ + +
+
+ Amsterdam in der Abenddämmerung — eine der sechs Regionen, in denen unsere Server laufen +
+
+

ODOO COMMUNITY UPGRADE

+

Odoo Community Upgrade: Was sich ändert und wie wir es für Sie übernehmen

+

+ Der Sprung auf eine neue Odoo-Hauptversion ist kein Update: Er ist eine Umwandlung Ihrer Datenbank in nur eine Richtung, und nichts, was Sie falsch machen wollen. Hier steht, wie wir das für Sie übernehmen — ein neues System auf unseren eigenen Servern, Ihr bestehendes bleibt unberührt, während wir arbeiten — und darunter die konkreten Befehle, die ein Entwickler ausführen würde. +

+ +
+
+ + +
+
+

Der Unterschied, auf den es ankommt

+

Was ein Odoo Community Upgrade wirklich ist

+
+

+ Odoo benutzt zwei Wörter, die gleich klingen und es nicht sind. Ein Update bringt Ihnen die neueste Fassung der Software, die Sie bereits einsetzen. Ein Upgrade bringt Ihre Datenbank auf eine neue Hauptversion (18 auf 19 oder 19 auf 20) und wandelt die Daten selbst um. Es geht nur in eine Richtung: einen unterstützten Weg zurück gibt es nicht, und es ist keine Lizenzänderung, kein Wechsel der Edition und kein Wechsel des Hosting-Anbieters. +

+

Drei Dinge sollten Sie wissen, bevor jemand Ihr System anfasst.

+

+ Es geht immer nur eine Hauptversion auf einmal. Ein Sprung von 17 auf 20 sind drei Migrationen, nicht eine: 17 → 18, 18 → 19, 19 → 20. Eine Version zu überspringen ist im gesamten Odoo-Ökosystem kein unterstützter Weg. +

+

+ Er wird an einer Kopie gemacht, nie an der laufenden Datenbank. Alle, die darüber geschrieben haben (die eigene Dokumentation von Odoo, das OpenUpgrade-Projekt der OCA und jeder Praktiker, den wir gesehen haben), beginnen mit einem Backup und arbeiten an einer Zweitkopie. Sie erfahren, was kaputtgegangen ist, an der Kopie und nicht vor Ihren Kunden. +

+

+ Ihre eigenen Anpassungen sind der Teil, der Arbeit macht. Ein Modul, das für Ihr Geschäft gebaut wurde, zieht nicht von selbst mit: Sein Code muss auf die Zielversion gebracht werden, und Umbenennungen, die sonst Daten kosten würden, brauchen eigene Migrationsskripte. Die Odoo-Dokumentation sagt es unverblümt: Ein Upgrade ist blockiert, bis es Ihre individuellen Module für die Zielversion gibt. +

+

+ Und dann der Weg selbst. Odoo verkauft einen Upgrade-Pfad für Enterprise; für Odoo Community ist die Open-Source-Antwort das OpenUpgrade-Projekt der OCA. Die OpenUpgrade-Dokumentation stellt fest, dass die Odoo Community Edition Migrationen zwischen Hauptversionen nicht unterstützt, und hält fest, dass OpenUpgrade die Lösung ist, die der Gründer von Odoo selbst dafür empfiehlt. Es ist ein echtes Projekt, gepflegt von der Community-Vereinigung, und es ist der Weg, den ein Entwickler auf einer Community-Datenbank nutzt. +

+
+
+
+ + +
+
+

Der Weg von ODOO4projects

+

Der Weg von ODOO4projects: eine neue Datenbank, und wir erledigen die Arbeit

+
+

+ Nichts davon müssen Sie selbst tun. Wenn Ihr Geschäft auf Odoo Community läuft und Sie die Version wechseln wollen, ohne jemanden einzustellen, der die Reihenfolge auf dieser Seite abarbeitet, machen wir stattdessen Folgendes. +

+

+ Sie eröffnen ein Support-Ticket und sagen uns, was Sie haben. Wir sehen uns zuerst Ihre Datenbank an (ihre Version, ihre Anpassungen, ob wir sie überhaupt bewegen können) und sagen Ihnen, was wir finden. Dann senden wir Ihnen einen Link zu einem sicheren Formular, über das Sie Ihre Datenbank hochladen. Sobald wir sie haben, richten wir Ihnen einen neuen Server auf unserer eigenen Infrastruktur ein und übergeben Ihnen die Zugangsdaten. Ihr bestehendes System läuft die ganze Zeit weiter, weil wir es nicht anfassen: Wir arbeiten an der Datenbank, die Sie uns gesendet haben, und an dem neuen Server, den wir gebaut haben. +

+

+ Wenn Sie lieber erst eine Zahl sehen möchten: Welchen Tarif Sie brauchen, hängt von den Modulen ab, die Sie nutzen, und die Tarife finden Sie hier — Tarife ansehen. Das Upgrade selbst ist auf dieser Seite nicht bepreist; wir melden uns bei Ihnen, nachdem wir Ihre Datenbank angesehen haben. +

+

+ Genau dieser letzte Punkt ist der ganze Grund für diesen Weg. Bei unserem Service migrieren Sie nicht abends nach Ladenschluss Ihre laufende Datenbank. Sie sehen sich ein zweites System an, in einer neuen Version, mit Ihren Daten darin, und können beide vergleichen, bevor Sie irgendetwas entscheiden. +

+

+ Unser Migrationsservice dokumentiert Unterstützung für Datenbanken auf Odoo 17, 18 und 19, nur Hauptreleases; Patch-Releases wie 18.1 oder 17.2 werden nirgends in unserem Service unterstützt. Ist Ihre Datenbank älter als 17, helfen wir Ihnen trotzdem, sie auf ein unterstütztes Release zu bringen, aber erst nach einer Prüfung auf Kompatibilität. Neue Instanzen auf unseren Servern können auf Odoo 19 oder Odoo 20 angelegt werden. Wenn Sie gezielt auf 20 wollen, sagen Sie es im Ticket: Die Version, zu der Sie gehen, zählt mehr als die, auf der Sie sind. +

+

+ Auf der KI-Seite ist hier ein Fall, den wir tatsächlich veröffentlicht haben. Rechnungen von Hand von einer Odoo-Instanz in eine andere zu kopieren ist langsam und leicht falsch, also haben wir es stattdessen mit einem Workflow gemacht: Datensätze aus einem Odoo-19-System in ein neues Odoo-20-System geschrieben, angetrieben von einem Automatisierungs-Workflow und einem MCP-Server, der auf das neue System zeigt. Drei Regeln machten es sicher (Rechnungsnummer und Datum ändern sich nie, der Kontakt wird nachgeschlagen statt geraten, das Produkt wird nachgeschlagen statt geraten) und eine harte Vorgabe: Fehlt ein Kontakt oder ein Produkt, bricht der Lauf laut ab, statt einen Fast-Doppelgänger anzulegen. Bevor wir es auf den Rest losließen, haben wir eine Rechnung von Anfang bis Ende geprüft: Nummer, Datum, Kontakt, Positionen. +

+

+ Eines verwischen wir nicht, denn es ist der Unterschied zwischen uns und einem Verkäufer. Der MCP-Server, den wir in unserer eigenen Verwaltungskonsole mitliefern, macht Hosting-Operationen. Er startet einen Server neu, lädt ein Modul hoch, fügt eine Domain hinzu oder prüft sie, verwaltet Backups und liest eine Logdatei; das ist die veröffentlichte Liste, und sie ist eine echte Erleichterung, wenn Sie einen KI-Assistenten nutzen. Er ist keine Datenmigrations-Engine, und wir beschreiben ihn auch nicht als eine. Die Importarbeit oben wurde mit einem Automatisierungs-Workflow und einem MCP von Drittanbietern erledigt; die KI machte den mühsamen Teil und wurde von einem Menschen geprüft, genau wie es sein soll. +

+

+ Und die ehrliche Grenze, in den Worten des Projekts, das sich damit am besten auskennt. Die OpenUpgrade-Dokumentation nennt die Export-und-Import-Alternative und benennt ihren Preis klar: Sie retten nur einen Teil Ihrer Daten, und insbesondere erhalten Sie nicht die Historie und die Verknüpfungen zwischen den Datensätzen, zum Beispiel die Rechnungen je Kunde. Das ist das Risiko jedes Weges, der Dokumente in ein neues System verschiebt, und deshalb stellen Sie uns, wenn Sie diesen Weg mit uns gehen, vor Ihrer Freigabe eine Frage: Welche Datensätze werden in der neuen Datenbank sein und welche nicht? Wir möchten lieber, dass Sie sie stellen, als dass Sie sie annehmen. +

+
+
+
+ + +
+
+

Der dokumentierte Weg

+

Der Upgrade-Prozess, Schritt für Schritt

+
+

+ Das ist die Reihenfolge, auf die sich die Odoo-Dokumentation, das OpenUpgrade-Projekt und die aufgezeichneten Workshops einig sind. Nichts davon ist unseres und nichts davon ist geheim: Es ist der dokumentierte Weg, in der Reihenfolge, in der er gegangen wird. +

+
+
    +
  1. + Sichern Sie die Datenbank und wissen Sie, wo der Filestore liegt. Vor allem anderen. Die Dokumentation des OpenUpgrade-Projekts sagt, dass Sie unbedingt ein Backup der laufenden Datenbank machen müssen, und jeder Praktiker macht das zuerst. +
  2. +
  3. + Arbeiten Sie an einer Kopie. Spielen Sie das Backup in eine Testdatenbank ein und migrieren Sie diese. Ihr laufendes System bleibt unberührt, bis die Kopie funktioniert. +
  4. +
  5. + Richten Sie zuerst die Zielversion ein. Installieren Sie das neuere Odoo und legen Sie den OpenUpgrade-Code für die Zielversion in dessen Add-ons-Pfad, neben die Module, die Sie bereits nutzen. +
  6. +
  7. + Portieren Sie Ihre individuellen Module. Bringen Sie ihren Code auf die neue Version, bevor die Migration läuft. +
  8. +
  9. + Führen Sie die Migration an der Kopie aus. Ein Modul nach dem anderen, in Abhängigkeitsreihenfolge; jedes führt erst sein Pre-Skript aus, dann lädt es, dann sein Post-Skript. +
  10. +
  11. + Rechnen Sie damit, sie mehr als einmal auszuführen. Das ist iterativ. Im aufgezeichneten Workshop ist die Umgebung (Repositories, Branches, die Modulliste) der Teil, der Zeit kostet; der Migrationslauf selbst ist schnell, sobald die Umgebung steht. Sie setzen zurück und laufen erneut, bis das Log sauber ist. +
  12. +
  13. + Schließen Sie mit einem einfachen Update ab. Das Update noch einmal ohne die Migrationsparameter auszuführen, hebt den Zustand „inkompatibel“ auf und lässt die Datenbank nutzbar zurück. +
  14. +
  15. + Testen Sie anhand der Daten, nicht anhand der Versionsnummer. Öffnen Sie die migrierte Kopie und prüfen Sie, was zählt: einen Kunden, ein Produkt, einen Auftrag, eine Rechnung, eine Zahlung. So überprüfen die Praktiker es am Bildschirm. +
  16. +
  17. + Räumen Sie danach auf. Veraltete Tabellen, Spalten und Views, die eine Migration zurücklässt, kosten Leistung; deshalb werden sie entfernt, wenn das System eine Zeit lang läuft und niemand ein Problem gemeldet hat. +
  18. +
  19. + Dann geht es in den Produktivbetrieb. Spielen Sie die migrierte Datenbank dort ein, wo sie hingehört, oder lassen Sie das Upgrade zu einem Zeitpunkt Ihrer Wahl auf der Produktivdatenbank laufen. +
  20. +
+

+ So sieht es ehrlich aus: Die Vorbereitung ist der lange Teil, die Migration selbst der kurze, und die Kopie ist das, was Sie kaputtmachen dürfen. +

+
+
+ + +
+
+

Für Ihre Entwickler

+

Für Ihre Entwickler: die konkreten Befehle

+
+

+ Wenn Sie Odoo Community selbst betreiben und das lieber im Haus erledigen möchten, statt es uns zu überlassen, sind das die Befehle. Sie sind aus der jeweiligen Dokumentation übernommen, und bei jedem steht, was Sie einsetzen müssen und wovor die Quelle warnt. Nichts davon haben wir gegen Ihre Datenbank ausgeführt, und kein von uns veröffentlichter Befehl läuft auf unseren eigenen Servern: Unser Service beginnt mit einem Support-Ticket, nicht mit einem Terminal. +

+
+ +
+

Odoos Upgrade-Plattform

+

+ Odoo dokumentiert eine Upgrade-Plattform, die für On-Premise-Installationen über die Kommandozeile funktioniert. Die Odoo-Dokumentation stellt fest, dass die Migrationsskripte, die sie ausführt, nicht Open Source sind und zu Enterprise gehören; die Plattform selbst aber bringt eine selbst gehostete Datenbank auf die neue Version. +

+
# upgraded TEST database
+python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t <target version>
+
+# production upgrade
+python <(curl -s https://upgrade.odoo.com/upgrade) production -d <your db name> -t <target version>
+
+# general help
+python <(curl -s https://upgrade.odoo.com/upgrade) --help
+
+

+ Ersetzen: <your db name> ist die Datenbank auf der Maschine, auf der Sie den Befehl ausführen, und <target version> ist die Version, zu der Sie wechseln — 17.0, 18.0 oder 19.0, entsprechend dem Versionsauswahlfeld auf unserer eigenen Tarifseite. +

+

+ Was die Odoo-Dokumentation neben diesen drei Zeilen verlangt, weil davon abhängt, ob sie funktionieren: Das Skript braucht die üblichen Linux-Befehle auf der Maschine; der Systembenutzer, der es ausführt, braucht Zugriff auf Ihre PostgreSQL-Datenbank (die übliche PostgreSQL-Client-Umgebung, etwa .pgpass); und die Maschine muss die Upgrade-Plattform auf TCP 443 und auf einem Port im Bereich 32768-60999 erreichen, ein Firewall kann also eine Ausnahme brauchen. Die Kopie, die Sie hochladen, wird ohne Filestore übermittelt, deshalb muss der Produktiv-Filestore in die aktualisierte Datenbank zusammengeführt werden, bevor Sie sie testen. Der Download enthält dump.sql und einen Filestore-Ordner, und nur wer das Upgrade angefordert hat, kann das Ergebnis herunterladen. +

+
+
+ +
+

Der Community-Weg: OCA OpenUpgrade

+
# 1. OpenUpgrade for the TARGET version (the branch is the target major version)
+git clone --depth 1 --branch <TARGET>.0 https://github.com/OCA/OpenUpgrade.git
+
+# 2. helper library — the line the OpenUpgrade docs use
+pip install "git+https://github.com/OCA/openupgradelib.git@master#egg=openupgradelib"
+
+# 3. put the clone on the add-ons path of the <TARGET> Odoo config
+#    addons_path = <your own addons>,</abs/path>/OpenUpgrade
+
+# 4. migrate the copy of the database
+<odoo-bin> -c /etc/odoo/<TARGET>.conf \
+  -d <DB> \
+  --upgrade-path=/abs/path/OpenUpgrade/openupgrade_scripts/scripts \
+  -u all --stop-after-init \
+  --load=base,web,openupgrade_framework
+
+# 5. finish: a plain update, no migration parameters
+<odoo-bin> -c /etc/odoo/<TARGET>.conf -d <DB> -u all --stop-after-init
+
+

+ Vier Dinge ersetzen: <TARGET> ist die Ziel-Hauptversion (17, 18 oder 19 — nicht die Version, von der Sie kommen); <DB> ist die Kopie, die Sie migrieren, nie die laufende Datenbank; <odoo-bin> ist die Binärdatei der Zielversion, und wie sie heißt, hängt davon ab, wie Sie Odoo installiert haben (odoo-bin, odoo oder das Docker-Äquivalent); und beide absoluten Pfade sind Ihre eigenen — der Add-ons-Pfad und der Ort des OpenUpgrade-Klons. +

+

+ Zwei Details aus der eigenen Dokumentation des Projekts, die man mitnehmen sollte: Der openupgrade_framework-Teil dieses Befehls ist eine Reihe von Patches, die unter anderem verhindern, dass Odoo die Spalten und Tabellen von Feldern löscht, die es nicht mehr gibt — einer der Wege, auf denen eine Migration Daten verliert. Und die Umgebungsvariable OPENUPGRADE_USE_DEMO=yes behält die Demodaten in der migrierten Datenbank, wenn Sie sie wollen. +

+
+
+ +
+

Ihre individuellen Module

+
# Odoo's own code-rewrite command (it runs the scripts in odoo/upgrade_code)
+<odoo-bin> upgrade_code --from <FROM> --to <TO> --dry-run
+
+

+ Ersetzen Sie <FROM> und <TO> durch die beiden Hauptversionen (zum Beispiel 18 und 19). Führen Sie es zuerst mit --dry-run aus. Die eigene Befehlsreferenz von Odoo nennt diesen Befehl ein „Best-Effort“-Werkzeug und warnt, dass er „keine Silberkugeln“ ist: Er schreibt um, was er kann, und hinterlässt Ihnen eine Liste dessen, was ein Mensch noch ändern muss. Das Gegenstück der OpenUpgrade-Community für Modulcode ist odoo-module-migrator, das INFO für automatische Änderungen, WARNING für prüfenswerte Dinge und ERROR für Dinge protokolliert, die gar nicht funktionieren. Beide Werkzeuge berichten; keines denkt. +

+
+
+ +
+

Backups und der Filestore

+
# stop the service while you work (packaged install; the Odoo docs show this pattern)
+sudo service odoo<TARGET> stop
+
+# database dump (PostgreSQL's own tool)
+sudo -u postgres pg_dump -Fc -d <DB> -f /path/backup/<DB>.dump
+
+# restore a dump into a fresh database
+sudo -u postgres createdb -O <DB_OWNER> <DB_NEW>
+sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
+
+# the filestore lives under Odoo's data directory:
+#   default on Unix: $XDG_DATA_HOME or ~/.local/share/Odoo or /var/lib/Odoo
+#   filestore path:  <data_dir>/filestore/<DB>
+
+

+ Ersetzen Sie die Datenbanknamen, den Eigentümer, den Backup-Pfad und das Filestore-Datenverzeichnis durch Ihre eigenen; der Filestore enthält die Anhänge und Dokumente, auf die Ihre Datensätze zeigen, und eine Datenbank, die ohne ihn wiederhergestellt wird, ist eine Datenbank mit fehlenden Dateien. Das sind die dokumentierten Verfahren von PostgreSQL und Odoo, nicht unsere: Wir veröffentlichen keinen Befehl, der auf unseren eigenen Servern läuft, weil unser Service mit einem Ticket beginnt. +

+
+
+
+
+ + + +
+
+

Eigenleistung

+

Was Eigenleistung wirklich kostet

+
+

+ Ein gemieteter Server ist billig. Das ist die kleinste Zahl in dieser Entscheidung. Odoo Community selbst ist kostenlos: Eine Lizenz pro Benutzer werden Sie auf diesem Weg nirgends finden, weil Community keine hat. +

+

+ Was in dieser Zahl nicht steckt, ist der Mensch. Ein Upgrade auf Ihrem eigenen Server heißt: Jemand installiert die neue Version, bringt den Migrationscode auf den richtigen Pfad, portiert die Module, die Ihr Geschäft tatsächlich nutzt, lässt die Migration laufen, bis das Log nicht mehr meckert, prüft, ob Kunden, Aufträge und Rechnungen noch da sind, räumt auf, was die Migration hinterlassen hat, und macht das Ganze dann zu einem passenden Zeitpunkt noch einmal auf der Produktivdatenbank. Die Odoo-Dokumentation sagt, das Update erledigt am besten die Person, die Odoo ursprünglich eingerichtet hat. Auf einem gemieteten Server sind das Sie oder jemand, den Sie pro Stunde bezahlen, und keine dieser Zeilen steht auf der Rechnung. Das ist die Hälfte der Rechnung, die niemand ausdruckt, und die Hälfte, die in Ihren Abenden landet. +

+

+ Wir werden Ihre Stunden nicht beziffern, weil wir sie nicht gemessen haben und eine Marketingzahl schlechter wäre als keine. Was wir sagen, ist der Teil, bei dem es nicht wirklich ums Geld geht: Während Sie diese Arbeit machen, machen Sie nicht die Arbeit, für die man Sie bezahlt, und wenn die Migration falsch ist, erfahren Sie es von einem Kunden. +

+
+
+
+ + +
+
+

Klare Antworten

+

Fragen zum Upgrade

+
+
+ Ist ein Upgrade dasselbe wie ein Update? +
+

+ Nein. Ein Update bringt Ihnen die neueste Fassung der Software, die Sie bereits einsetzen. Ein Upgrade bringt Ihre Datenbank auf eine neue Hauptversion (18 auf 19 oder 19 auf 20) und wandelt die Daten selbst um. Es geht nur in eine Richtung: einen unterstützten Weg zurück gibt es nicht, und es ist keine Lizenzänderung, kein Editionswechsel und kein Hosting-Wechsel. +

+
+
+
+ Können wir direkt von Odoo 14 auf Odoo 20 upgraden? +
+

+ Nein. Es geht immer nur eine Hauptversion auf einmal: 14 auf 15 auf 16 auf 17 auf 18 auf 19 auf 20. Eine Version zu überspringen ist kein unterstützter Weg. Unser eigener Migrationsservice dokumentiert Unterstützung für Datenbanken auf Odoo 17, 18 und 19, nur Hauptreleases, keine Patch-Releases; ältere Datenbanken brauchen zuerst eine Kompatibilitätsprüfung, die mit einem Support-Ticket beginnt. +

+
+
+
+ Was passiert mit meiner Historie: Rechnungen, Zahlungen, Anhänge? +
+

+ Das ist die richtige Frage, und die ehrliche Antwort lautet: Es hängt vom Weg ab. Der OpenUpgrade-Weg — eine Versionsmigration auf Ihrem eigenen Server — nimmt die Datenbank mit und erhält die Historie und die Verknüpfungen zwischen den Datensätzen. Die OpenUpgrade-Dokumentation warnt, dass der andere Weg, Dokumente in ein neues System zu verschieben, nur einen Teil Ihrer Daten rettet und die Historie und die Verknüpfungen zwischen den Datensätzen verliert, zum Beispiel die Rechnungen je Kunde. Unser Service baut Ihnen eine neue Datenbank und bringt Ihre Daten hinein; unser Weg ist also der, nach dem Sie fragen sollten: Bitten Sie uns vor Ihrer Freigabe, genau aufzulisten, welche Datensätze in der neuen Datenbank sein werden und welche nicht. Wir möchten lieber, dass Sie sie stellen, als dass Sie sie annehmen. +

+
+
+
+ Funktionieren meine individuellen Module weiterhin? +
+

+ Nicht von allein. Ein Modul, das für Ihr Geschäft geschrieben wurde, braucht seinen Code auf der Zielversion, und Umbenennungen, die sonst Daten kosten würden, brauchen eigene Migrationsskripte. Die Odoo-Dokumentation ist hier deutlich: Ein Upgrade ist blockiert, bis es eine Version Ihrer individuellen Module für die Zielversion gibt. Module, die mit Odoo ausgeliefert werden, und Module der Community-Vereinigung bringen ihre eigenen Migrationsskripte mit; Ihre nicht, und die muss jemand schreiben. +

+
+
+
+ Was kostet es, und wie lange dauert es? +
+

+ Für den Upgrade-Service veröffentlichen wir weder Preis noch Dauer, und wir erfinden hier auch keine. Was wir veröffentlichen, ist der Anfang: Sie eröffnen ein Support-Ticket, wir prüfen Ihre Datenbank auf Kompatibilität und melden uns bei Ihnen. Wenn Sie es gegen die Eigenleistung abwägen, ist der ehrliche Vergleich nicht die Servermiete, sondern Ihre eigenen Stunden, die auf keiner Rechnung auftauchen. +

+
+
+
+ Brauche ich einen Entwickler? +
+

+ Um die Befehle im technischen Abschnitt auszuführen, ja; oder jemanden, der sich im Terminal mit PostgreSQL auskennt. Damit wir es übernehmen, nein: Genau das ist der Sinn des Service. Sie senden die Datenbank, wir bauen das neue System auf unserer Infrastruktur, und Sie erhalten die Zugangsdaten. +

+
+
+
+ Kann ich das System mit der neuen Version ansehen, bevor es live geht? +
+

+ Ja, und das sollten Sie. Wer die Arbeit macht, migriert zuerst eine Kopie; das ist die erste Regel des ganzen Prozesses, in der Odoo-Dokumentation wie im OpenUpgrade-Projekt. Und die migrierte Kopie ist das, was Sie prüfen, bevor mit dem System, auf dem Ihr Geschäft läuft, irgendetwas passiert. Unser Service folgt demselben Prinzip: Wir bauen das neue System auf unseren eigenen Servern, und Sie vergleichen es mit dem alten. +

+
+
+
+ Wir sind woanders gehostet. Können Sie uns trotzdem upgraden? +
+

+ Ja, genau dafür ist unser Migrationsservice da. Sie eröffnen ein Support-Ticket, wir senden Ihnen ein sicheres Formular zum Hochladen Ihrer Datenbank, richten Ihnen einen neuen Server auf unserer Infrastruktur ein und stellen die Zugangsdaten bereit. Datenbanken auf Odoo 17, 18 und 19, nur Hauptreleases; ältere nach einer Kompatibilitätsprüfung. +

+
+
+
+
+
+ + +
+
+

+ Sie eröffnen ein Support-Ticket, wir prüfen Ihre Datenbank auf Kompatibilität und melden uns bei Ihnen. +

+ +
+
+ + + + + diff --git a/es/odoo-community-upgrade.html b/es/odoo-community-upgrade.html new file mode 100644 index 0000000..a87d650 --- /dev/null +++ b/es/odoo-community-upgrade.html @@ -0,0 +1,887 @@ + + + + + + Odoo Community Upgrade — gestionado para usted | ODOO4projects + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ ODOO4projects + +
+
+
+ + +
+
+ Ámsterdam al atardecer — una de las seis regiones en las que funcionan nuestros servidores +
+
+

ODOO COMMUNITY UPGRADE

+

Odoo Community Upgrade: qué cambia y cómo lo hacemos por usted

+

+ Subir a una nueva versión mayor de Odoo no es una actualización: es un cambio en un solo sentido de su base de datos, y no es algo que quiera hacer mal. Aquí está cómo lo hacemos por usted — un sistema nuevo en nuestros propios servidores, el actual intacto mientras trabajamos — y, debajo, los comandos exactos que ejecutaría un desarrollador. +

+ +
+
+ + +
+
+

La diferencia que importa

+

Qué es realmente un cambio de versión de Odoo Community

+
+

+ Odoo usa dos palabras que suenan igual y no lo son. Una actualización le da la última revisión del software que ya utiliza. Un cambio de versión lleva su base de datos a una nueva versión mayor (18 a 19, o 19 a 20) y transforma los propios datos. Es en un solo sentido: no existe una vuelta atrás con soporte, y no es un cambio de licencia, ni de edición, ni de proveedor de hosting. +

+

Hay tres cosas que conviene saber antes de que alguien toque su sistema.

+

+ Se hace una versión mayor a la vez. Un salto de 17 a 20 son tres migraciones, no una: 17 → 18, 18 → 19, 19 → 20. Saltarse una versión no es un camino con soporte en ningún punto del ecosistema Odoo. +

+

+ Se hace sobre una copia, nunca sobre la base de datos en producción. Todos los que han escrito sobre esto (la propia documentación de Odoo, el proyecto OpenUpgrade de la OCA y cada profesional que hemos visto) empiezan haciendo una copia de seguridad y trabajando sobre un duplicado. Lo que se rompe lo descubre en la copia, no delante de sus clientes. +

+

+ Sus propias personalizaciones son la parte que da trabajo. Un módulo hecho para su negocio no se mueve solo: hay que llevar su código a la versión de destino, y los cambios de nombre que de otro modo perderían datos necesitan sus propios scripts de migración. La documentación de Odoo lo dice sin rodeos: un cambio de versión queda bloqueado hasta que exista una versión de sus módulos personalizados para la versión a la que se muda. +

+

+ Y luego la ruta en sí. Odoo vende una ruta de actualización para Enterprise; para Odoo Community, la respuesta de código abierto es el proyecto OpenUpgrade de la OCA. La documentación de OpenUpgrade afirma que Odoo Community Edition no da soporte a migraciones entre versiones mayores y deja constancia de que OpenUpgrade es la solución que el propio fundador de Odoo recomienda para ello. Es un proyecto real, mantenido por la asociación de la comunidad, y es la ruta que usará un desarrollador sobre una base de datos Community. +

+
+
+
+ + +
+
+

La forma de ODOO4projects

+

La forma de ODOO4projects: una base de datos nueva, y el trabajo lo hacemos nosotros

+
+

+ No tiene que hacer nada de esto usted mismo. Si su negocio funciona con Odoo Community y quiere cambiar de versión sin contratar a alguien que recorra la secuencia de esta página, esto es lo que hacemos nosotros. +

+

+ Usted abre una incidencia de soporte y nos cuenta qué tiene. Primero miramos su base de datos (su versión, sus personalizaciones, si es algo que podemos mover) y le decimos qué encontramos. Luego le enviamos un enlace a un formulario seguro donde sube su base de datos. Cuando la tenemos, le montamos un servidor nuevo en nuestra propia infraestructura y le entregamos las credenciales. Su sistema actual sigue funcionando todo el tiempo, porque no lo tocamos: trabajamos sobre la base de datos que nos envió y sobre el servidor nuevo que montamos. +

+

+ Si prefiere ver antes una cifra: qué plan necesita depende de los módulos que use, y los planes están aquí — Ver los planes. El cambio de versión en sí no tiene precio en esa página; le respondemos después de haber mirado su base de datos. +

+

+ Ese último punto es toda la razón de hacerlo así. Con nuestro servicio no migra su base de datos en producción por la noche, después de cerrar. Está viendo un segundo sistema, en una versión nueva, con sus datos dentro, y puede comparar los dos antes de decidir nada. +

+

+ Nuestro servicio de migración documenta soporte para bases de datos en Odoo 17, 18 y 19, solo versiones principales; las versiones de parche como 18.1 o 17.2 no tienen soporte en ningún punto de nuestro servicio. Si su base de datos es anterior a la 17, también podemos ayudarle a llevarla a una versión con soporte, pero solo tras revisarla para comprobar la compatibilidad. Las instancias nuevas en nuestros servidores pueden crearse en Odoo 19 u Odoo 20, así que si se muda a la 20 en concreto, dígalo en la incidencia: la versión a la que va importa más que la versión en la que está. +

+

+ En el terreno de la IA, aquí hay un caso que hemos publicado de verdad. Copiar facturas a mano de una instancia de Odoo a otra es lento y fácil de hacer mal, así que lo hicimos con un flujo de trabajo: registros escritos desde un sistema Odoo 19 a un sistema Odoo 20 nuevo, impulsados por un flujo de automatización y un servidor MCP apuntando al sistema nuevo. Tres reglas lo hicieron seguro (el número y la fecha de la factura nunca cambian, el contacto se busca en lugar de suponerse, el producto se busca en lugar de suponerse) y una restricción firme: si falta un contacto o un producto, la ejecución falla de forma sonora en lugar de crear un casi duplicado. Antes de soltarlo sobre el resto, revisamos una factura de principio a fin: número, fecha, contacto y líneas de producto. +

+

+ Hay algo que no vamos a difuminar, porque es la diferencia entre nosotros y un vendedor. El servidor MCP que incluimos dentro de nuestra propia consola de gestión hace operaciones de hosting. Reinicia un servidor, sube un módulo, añade o comprueba un dominio, gestiona copias de seguridad y lee un archivo de registro; esa es la lista publicada, y es una comodidad real si usa un asistente de IA. No es un motor de migración de datos y no lo describimos como tal. El trabajo de importación de arriba se hizo con un flujo de automatización y un MCP de terceros; la IA hacía la parte tediosa y un humano la revisaba, justo como debe ser. +

+

+ Y el límite honesto, en palabras del proyecto que mejor lo conoce. La documentación de OpenUpgrade menciona la alternativa de exportar e importar y le pone precio sin rodeos: recupera solo parte de sus datos y, en particular, no obtiene el historial ni los enlaces entre registros, por ejemplo las facturas de cada cliente. Ese es el riesgo de cualquier ruta que traslade documentos a un sistema nuevo, y por eso, si toma esa ruta con nosotros, nos hace una pregunta antes de aprobar nada: qué registros estarán en la nueva base de datos y cuáles no. Preferimos que la haga a que la dé por supuesta. +

+
+
+
+ + +
+
+

La ruta documentada

+

El proceso de cambio de versión, paso a paso

+
+

+ Esta es la secuencia en la que coinciden la documentación de Odoo, el proyecto OpenUpgrade y los talleres grabados. Nada de esto es nuestro ni es secreto: es la ruta documentada, en el orden en que se hace. +

+
+
    +
  1. + Haga una copia de seguridad de la base de datos y sepa dónde está el filestore. Antes que nada. La documentación del proyecto OpenUpgrade dice que debe hacer sin falta una copia de la base de datos en producción, y todo profesional empieza por aquí. +
  2. +
  3. + Trabaje sobre una copia. Restaure la copia en una base de datos de prueba y migre esa. Su sistema en producción queda intacto hasta que la copia funcione. +
  4. +
  5. + Ponga en marcha primero la versión de destino. Instale el Odoo más reciente y coloque el código de OpenUpgrade para la versión de destino en su ruta de add-ons, junto a los módulos que ya utiliza. +
  6. +
  7. + Adapte sus módulos personalizados. Lleve su código a la nueva versión antes de que se ejecute la migración. +
  8. +
  9. + Ejecute la migración sobre la copia. Un módulo a la vez, en orden de dependencias; cada uno ejecuta su pre-script, luego carga y luego su post-script. +
  10. +
  11. + Cuente con ejecutarla más de una vez. Esto es iterativo. En el taller grabado, el entorno (repositorios, ramas, la lista de módulos) es la parte que lleva tiempo; la ejecución de la migración en sí es rápida una vez que existe el entorno, y usted reinicia y vuelve a ejecutar hasta que el registro esté limpio. +
  12. +
  13. + Termine con una actualización simple. Ejecutar la actualización una vez más sin los parámetros de migración es lo que elimina el estado "incompatible" y deja la base de datos utilizable. +
  14. +
  15. + Compruebe por los datos, no por el número de versión. Abra la copia migrada y revise lo que importa: un cliente, un producto, un pedido, una factura, un pago. Así lo verifican los profesionales en pantalla. +
  16. +
  17. + Limpie después. Las tablas, columnas y vistas obsoletas que deja una migración cuestan rendimiento, así que se eliminan una vez que el sistema lleva un tiempo en marcha y nadie ha reportado un problema. +
  18. +
  19. + Después, pase a producción. Restaure la base de datos migrada donde corresponda, o haga que el cambio de versión se ejecute sobre la base de datos en producción en el momento que usted elija. +
  20. +
+

+ Esa es su forma honesta: la preparación es la parte larga, la migración en sí es la corta, y la copia es lo que se le permite romper. +

+
+
+ + +
+
+

Para su desarrollador

+

Para su desarrollador: los comandos reales

+
+

+ Si gestiona Odoo Community usted mismo y prefiere hacerlo en casa en lugar de dejárnoslo, estos son los comandos. Están citados de la documentación de la que proceden, y cada uno indica qué debe sustituir y de qué advierte esa fuente. Nada de lo que sigue lo hemos ejecutado nosotros contra su base de datos, y ningún comando publicado por nosotros se ejecuta en nuestros servidores: nuestro servicio empieza con una incidencia de soporte, no con una terminal. +

+
+ +
+

La plataforma de cambio de versión de Odoo

+

+ Odoo documenta una plataforma de cambio de versión que funciona para instalaciones on-premise desde la línea de comandos. La documentación de Odoo indica que los scripts de migración que ejecuta no son de código abierto y vienen con Enterprise; pero la plataforma en sí sí lleva a una nueva versión una base de datos autoalojada. +

+
# upgraded TEST database
+python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t <target version>
+
+# production upgrade
+python <(curl -s https://upgrade.odoo.com/upgrade) production -d <your db name> -t <target version>
+
+# general help
+python <(curl -s https://upgrade.odoo.com/upgrade) --help
+
+

+ Sustituya: <your db name> es la base de datos de la máquina desde la que ejecuta el comando, y <target version> es la versión a la que se muda — 17.0, 18.0 o 19.0, según el selector de versión de nuestra propia página de planes. +

+

+ Lo que la documentación de Odoo exige junto a esas tres líneas, porque de ello depende que funcionen: el script necesita los comandos Linux habituales presentes en la máquina; el usuario del sistema que lo ejecuta necesita acceso a su base de datos PostgreSQL (el entorno de cliente PostgreSQL estándar, como .pgpass); y la máquina debe alcanzar la plataforma de cambio de versión en TCP 443 y en un puerto del rango 32768-60999, así que puede hacer falta una excepción en el cortafuegos. La copia que sube se envía sin filestore, así que hay que fusionar el filestore de producción en la base de datos actualizada antes de probarla. La descarga contiene dump.sql y una carpeta de filestore, y solo quien solicitó el cambio de versión puede descargar el resultado. +

+
+
+ +
+

La ruta Community: OCA OpenUpgrade

+
# 1. OpenUpgrade for the TARGET version (the branch is the target major version)
+git clone --depth 1 --branch <TARGET>.0 https://github.com/OCA/OpenUpgrade.git
+
+# 2. helper library — the line the OpenUpgrade docs use
+pip install "git+https://github.com/OCA/openupgradelib.git@master#egg=openupgradelib"
+
+# 3. put the clone on the add-ons path of the <TARGET> Odoo config
+#    addons_path = <your own addons>,</abs/path>/OpenUpgrade
+
+# 4. migrate the copy of the database
+<odoo-bin> -c /etc/odoo/<TARGET>.conf \
+  -d <DB> \
+  --upgrade-path=/abs/path/OpenUpgrade/openupgrade_scripts/scripts \
+  -u all --stop-after-init \
+  --load=base,web,openupgrade_framework
+
+# 5. finish: a plain update, no migration parameters
+<odoo-bin> -c /etc/odoo/<TARGET>.conf -d <DB> -u all --stop-after-init
+
+

+ Sustituya cuatro cosas: <TARGET> es la versión mayor de destino (17, 18 o 19 — no la versión de la que viene); <DB> es la copia que migra, nunca la base de datos en producción; <odoo-bin> es el binario de la versión de destino, y cómo se llama depende de cómo instaló Odoo (odoo-bin, odoo o el equivalente de Docker); y ambas rutas absolutas son suyas — la ruta de add-ons y la ubicación del clon de OpenUpgrade. +

+

+ Dos detalles que conviene llevarse de la documentación del propio proyecto: la parte openupgrade_framework de ese comando es un conjunto de parches que, entre otras cosas, impide que Odoo elimine las columnas y tablas de campos que ya no existen — una de las formas en que una migración pierde datos. Y la variable de entorno OPENUPGRADE_USE_DEMO=yes conserva los datos de demostración en la base de datos migrada cuando usted los quiere. +

+
+
+ +
+

Sus módulos personalizados

+
# Odoo's own code-rewrite command (it runs the scripts in odoo/upgrade_code)
+<odoo-bin> upgrade_code --from <FROM> --to <TO> --dry-run
+
+

+ Sustituya <FROM> y <TO> por las dos versiones mayores (18 y 19, por ejemplo). Ejecútelo primero con --dry-run. La propia referencia de comandos de Odoo llama a este comando una herramienta de "mejor esfuerzo" y advierte de que "no son balas de plata": reescribe lo que puede y le deja una lista de lo que un humano todavía tiene que cambiar. El equivalente de la comunidad OpenUpgrade para el código de módulos es odoo-module-migrator, que registra INFO para los cambios automáticos, WARNING para lo que hay que revisar y ERROR para lo que no funcionará en absoluto. Ambas herramientas informan; ninguna piensa. +

+
+
+ +
+

Copias de seguridad y el filestore

+
# stop the service while you work (packaged install; the Odoo docs show this pattern)
+sudo service odoo<TARGET> stop
+
+# database dump (PostgreSQL's own tool)
+sudo -u postgres pg_dump -Fc -d <DB> -f /path/backup/<DB>.dump
+
+# restore a dump into a fresh database
+sudo -u postgres createdb -O <DB_OWNER> <DB_NEW>
+sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
+
+# the filestore lives under Odoo's data directory:
+#   default on Unix: $XDG_DATA_HOME or ~/.local/share/Odoo or /var/lib/Odoo
+#   filestore path:  <data_dir>/filestore/<DB>
+
+

+ Sustituya los nombres de las bases de datos, el propietario, la ruta de copia y el directorio de datos del filestore por los suyos; el filestore es lo que contiene los archivos adjuntos y documentos a los que apuntan sus registros, y una base de datos restaurada sin él es una base de datos a la que le faltan archivos. Son los procedimientos documentados de PostgreSQL y de Odoo, no los nuestros: no publicamos un comando que se ejecute en nuestros servidores, porque nuestro servicio empieza con una incidencia. +

+
+
+
+
+ + + +
+
+

Trabajo propio

+

Lo que de verdad cuesta hacerlo usted mismo

+
+

+ Un servidor alquilado es barato. Esa es la cifra más pequeña de esta decisión. Odoo Community en sí es gratis: no encontrará una licencia por usuario en ninguna parte de esta ruta, porque Community no la tiene. +

+

+ Lo que no está en esa cifra es la persona. Un cambio de versión en su propio servidor significa que alguien instala la versión nueva, coloca el código de migración en la ruta correcta, adapta los módulos que su negocio usa de verdad, ejecuta la migración hasta que el registro deja de quejarse, comprueba que los clientes, los pedidos y las facturas siguen ahí, limpia lo que dejó la migración y luego lo repite en la base de datos en producción en un momento que le venga bien al negocio. La propia documentación de Odoo dice que la actualización la hace mejor quien instaló Odoo en su día. En un servidor alquilado, esa persona es usted o alguien a quien paga por horas, y ninguna de esas líneas aparece en la factura. Esa es la mitad de la cuenta que nadie imprime, y la mitad que acaba en sus noches. +

+

+ No vamos a poner una cifra a sus horas, porque no las hemos medido y una cifra de marketing sería peor que ninguna. Lo que sí diremos es la parte que no va realmente de dinero: mientras hace ese trabajo, no hace el trabajo por el que le pagan, y si la migración está mal, se entera por un cliente. +

+
+
+
+ + +
+
+

Respuestas claras

+

Preguntas sobre el cambio de versión

+
+
+ ¿Es lo mismo un cambio de versión que una actualización? +
+

+ No. Una actualización le da la última revisión del software que ya utiliza. Un cambio de versión lleva su base de datos a una nueva versión mayor (18 a 19, o 19 a 20) y transforma los propios datos. Es en un solo sentido: no existe una vuelta atrás con soporte, y no es un cambio de licencia, ni de edición, ni de hosting. +

+
+
+
+ ¿Podemos pasar directamente de Odoo 14 a Odoo 20? +
+

+ No. Se hace una versión mayor a la vez: 14 a 15 a 16 a 17 a 18 a 19 a 20. Saltarse una versión no es un camino con soporte. Nuestro propio servicio de migración documenta soporte para bases de datos en Odoo 17, 18 y 19, solo versiones principales, sin versiones de parche; las bases más antiguas necesitan antes una revisión de compatibilidad, que empieza con una incidencia de soporte. +

+
+
+
+ ¿Qué pasa con mi historial: las facturas, los pagos, los archivos adjuntos? +
+

+ Esa es la pregunta correcta, y la respuesta honesta es que depende de la ruta. La ruta de OpenUpgrade — una migración de versión ejecutada en su propio servidor — lleva la base de datos consigo y conserva el historial y los enlaces entre registros. La documentación de OpenUpgrade advierte de que la otra ruta, trasladar documentos a un sistema nuevo, recupera solo parte de sus datos y pierde el historial y los enlaces entre registros, por ejemplo las facturas de cada cliente. Nuestro servicio le construye una base de datos nueva y traslada sus datos a ella, así que la nuestra es la ruta por la que preguntar: antes de aprobar nada, pídanos que enumeremos exactamente qué registros estarán en la nueva base de datos y cuáles no. Preferimos que la haga a que la dé por supuesta. +

+
+
+
+ ¿Seguirán funcionando mis módulos personalizados? +
+

+ No por sí solos. Un módulo escrito para su negocio tiene que llevar su código a la versión de destino, y los cambios de nombre que de otro modo perderían datos necesitan sus propios scripts de migración. La documentación de Odoo es tajante al respecto: un cambio de versión queda bloqueado hasta que exista una versión de sus módulos personalizados para la versión a la que se muda. Los módulos que vienen con Odoo y los de la asociación de la comunidad traen sus propios scripts de migración; los suyos no, y alguien tiene que escribirlos. +

+
+
+
+ ¿Cuánto cuesta y cuánto tarda? +
+

+ No publicamos ni precio ni duración para el servicio de cambio de versión, y no vamos a inventarnos ninguno aquí. Lo que sí publicamos es cómo empieza: usted abre una incidencia de soporte, revisamos la compatibilidad de su base de datos y le respondemos. Si lo compara con hacerlo usted mismo, la comparación honesta no es el alquiler del servidor, sino sus propias horas, que nunca aparecen en esa factura. +

+
+
+
+ ¿Necesito un desarrollador? +
+

+ Para ejecutar los comandos de la sección técnica, sí; o alguien que se maneje en una terminal con PostgreSQL. Para que lo hagamos nosotros, no: de eso se trata el servicio. Usted envía la base de datos, nosotros montamos el sistema nuevo en nuestra infraestructura y usted recibe las credenciales. +

+
+
+
+ ¿Puedo ver el sistema con la nueva versión antes de ponerlo en producción? +
+

+ Sí, y debería hacerlo. Quien hace el trabajo migra primero una copia; esa es la primera regla de todo el proceso, tanto en la documentación de Odoo como en el proyecto OpenUpgrade. Y la copia migrada es lo que usted revisa antes de que le ocurra nada al sistema con el que funciona su negocio. Nuestro servicio sigue el mismo principio: montamos el sistema nuevo en nuestros propios servidores y usted lo compara con el antiguo. +

+
+
+
+ Estamos alojados en otro sitio. ¿Pueden cambiar de versión igualmente? +
+

+ Sí, exactamente para eso está nuestro servicio de migración. Usted abre una incidencia de soporte, le enviamos un formulario seguro para subir su base de datos, le montamos un servidor nuevo en nuestra infraestructura y le damos las credenciales. Bases de datos en Odoo 17, 18 y 19, solo versiones principales; las más antiguas, tras una revisión de compatibilidad. +

+
+
+
+
+
+ + +
+
+

+ Usted abre una incidencia de soporte, revisamos la compatibilidad de su base de datos y le respondemos. +

+ +
+
+ + + + + diff --git a/llms.txt b/llms.txt index 873e02a..1e100a4 100644 --- a/llms.txt +++ b/llms.txt @@ -67,11 +67,11 @@ ## Languages - German: https://odoo4projects.com/de/ — the site's pages mirrored under `/de/`: - `/de/`, `/de/odoo-hosting-2027.html`, `/de/support.html`, - `/de/odoo-erp-automation-bootcamp/`. + `/de/`, `/de/odoo-hosting-2027.html`, `/de/odoo-community-upgrade.html`, + `/de/support.html`, `/de/odoo-erp-automation-bootcamp/`. - Spanish: https://odoo4projects.com/es/ — the site's pages mirrored under `/es/`: - `/es/`, `/es/odoo-hosting-2027.html`, `/es/support.html`, - `/es/odoo-erp-automation-bootcamp/`. + `/es/`, `/es/odoo-hosting-2027.html`, `/es/odoo-community-upgrade.html`, + `/es/support.html`, `/es/odoo-erp-automation-bootcamp/`. - Language selection is client-side (`/static/lang.js`): a German- or Spanish-preferring browser is sent to `/de/` or `/es/` once per session. An explicit choice — `?lang=de|es|en` or the EN | DE | ES switcher — is diff --git a/sitemap.xml b/sitemap.xml index 1f7504f..0f3540d 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -198,4 +198,16 @@ monthly 0.9 + + https://odoo4projects.com/de/odoo-community-upgrade.html + 2026-10-27 + monthly + 0.9 + + + https://odoo4projects.com/es/odoo-community-upgrade.html + 2026-10-27 + monthly + 0.9 +