ODOO COMMUNITY UPGRADE
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
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
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
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.
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
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.
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.
# 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.
# 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.
# 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
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
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.
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.
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.
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.
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.
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.
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.
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.