Saltar al contenido principal

Migrar desde otro host de Odoo

Mover una base de datos Odoo existente a Skysize se reduce a tres cosas: una copia de seguridad limpia de la instancia antigua, un proyecto en Skysize con el mismo código personalizado, y el cambio de tu dominio. Esta guía recorre todo el camino, con las comprobaciones que evitan los fallos de importación más habituales.

Sirve para cualquier origen: otro host de Odoo, un servidor que gestionas tú mismo, o una instancia local. Las notas para hosts concretos están al final.

:::tip ¿Migras varias bases de datos? Cada base de datos Odoo se convierte en su propio proyecto de Skysize. Sigue esta guía una vez por base de datos, y ensaya primero con la más pequeña. :::

1. Haz inventario de la instancia antigua​

Antes de exportar nada, anota:

  • Versión y edición de Odoo, por ejemplo 17.0 Enterprise. La importación restaura la base de datos en la versión con la que se creó. Actualizar a una versión más reciente es un paso aparte, después de la migración.
  • Módulos personalizados y de terceros: todo lo instalado que no forma parte del Odoo estándar, y dónde está su código fuente. Abre Aplicaciones, quita el filtro Aplicaciones y filtra por Instalado para listarlos. Necesitarás el código en un repositorio Git.
  • Dependencias de Python que requieren esos módulos.
  • Tamaño de la base de datos y del filestore, para saber si la copia cabe en el límite de subida por navegador del hosting gestionado (ver Importar una copia de seguridad de Odoo existente).
  • Usuarios de PostgreSQL adicionales que se conectan directamente a la base de datos: herramientas de BI como Power BI o Metabase, usuarios de replicación, scripts de informes, o un usuario técnico creado en una migración anterior. La importación se encarga del rastro que dejan en el volcado (ver paso 3). Lo que tienes que planificar es otra forma de que lleguen a los datos tras el traslado.
  • Dominio, correo saliente e integraciones: el dominio en el que inician sesión los usuarios, el servidor SMTP, los sistemas externos que llaman a tu Odoo (proveedores de pago, webhooks, EDI), y los que Odoo llama y que solo admiten direcciones IP conocidas.

2. Prepara el proyecto en Skysize​

  1. Sube los módulos personalizados a un repositorio Git con las carpetas de los módulos en la raíz. Si están en subcarpetas, ver Organizar módulos en directorios anidados. Añade un requirements.txt para los paquetes de Python, ver Instalar paquetes de Python. Si la base de datos no tiene código personalizado, crea un proyecto sin repositorio.
  2. Crea el proyecto y configura la versión y la edición de Odoo para que coincidan con la instancia antigua. Una base de datos Enterprise necesita una rama Enterprise.
  3. Deja que termine el primer despliegue. La base de datos vacía que crea se reemplaza con la importación. Lo importante es que el build tenga éxito, lo que demuestra que los módulos y paquetes de Python se instalan correctamente en la plataforma.

3. Exporta una copia de seguridad limpia​

La importación toma la copia .zip nativa de Odoo: dump.sql, una carpeta filestore/ y manifest.json. Ver Importar una copia de seguridad de Odoo existente para el formato y el límite de tamaño.

De dónde sale la copia​

  • El gestor de bases de datos de Odoo (/web/database/manager, luego Backup en formato zip) es la fuente más sencilla cuando está habilitado en el host antiguo.

  • La función de copias de tu host suele producir la misma estructura de zip. Comprueba que el archivo contiene dump.sql en su raíz antes de subirlo.

  • Un pg_dump manual si tienes acceso shell al servidor antiguo. Estas opciones evitan cualquier referencia a los roles de tu servidor antiguo en el volcado, aunque la importación también tolera volcados hechos sin ellas:

    pg_dump --no-owner --no-privileges --format=p tu_base_de_datos > dump.sql

    Después copia la carpeta filestore de esa base de datos (<data_dir>/filestore/<nombre de la base> según el odoo.conf antiguo) al lado, con el nombre filestore/.

Instrucciones de propiedad y privilegios​

Un volcado hecho sin --no-owner o --no-privileges contiene instrucciones ALTER ... OWNER TO, GRANT, REVOKE y ALTER DEFAULT PRIVILEGES que nombran roles de PostgreSQL de tu servidor antiguo, por ejemplo un lector de Power BI o un usuario técnico de una migración anterior. El gestor de bases de datos de Odoo pasa --no-owner pero no --no-privileges, así que sus copias conservan las líneas GRANT siempre que usuarios adicionales tuvieran acceso a la base de datos.

No necesitas limpiar nada. La importación elimina las instrucciones de propiedad y privilegios sobre la marcha durante la restauración, así que una copia de cualquier host se importa tal cual. Tras la importación la base de datos pertenece al rol propio de la rama y no existe ningún otro rol, no se pierde nada. El log de restauración muestra cuántas líneas se omitieron.

4. Ensaya en una rama de staging​

Importa primero la copia en una rama de staging, siguiendo Importar una copia de seguridad de Odoo existente. Una restauración en una rama de staging se neutraliza automáticamente: los servidores de correo saliente y las acciones planificadas quedan desactivados, así que el ensayo no puede enviar correos ni llamar a integraciones en producción.

Después comprueba:

  • Los usuarios pueden iniciar sesión y la lista de Aplicaciones muestra los mismos módulos instalados que la instancia antigua.
  • El log de ejecución no tiene avisos de missing module ni module not found, ver Ver logs.
  • Los adjuntos, las imágenes de productos y los informes PDF se abren, lo que demuestra que el filestore llegó bien.
  • Tus flujos personalizados se comportan como antes.

Corrige ahora cualquier problema de módulos o dependencias en el repositorio y vuelve a desplegar. Repite la importación hasta que el ensayo esté limpio.

5. Cambia a producción​

  1. Baja el TTL del registro DNS de tu dominio un día antes, para que el cambio se propague rápido.
  2. Anuncia una ventana de mantenimiento. La instancia antigua sigue sirviendo hasta entonces.
  3. Detén las escrituras en la instancia antigua: para el servicio de Odoo, o bloquea los inicios de sesión.
  4. Haz una copia final como en el paso 3.
  5. Impórtala en la rama de producción. Una restauración en producción no se neutraliza, la base de datos vuelve exactamente como se exportó.
  6. Repasa las comprobaciones posteriores a la importación de abajo.
  7. Apunta tu dominio a Skysize, ver Añadir un dominio personalizado.
  8. Mantén la instancia antigua detenida pero intacta unos días antes de retirarla.

6. Después de la importación​

  • URL base: Odoo actualiza el parámetro del sistema web.base.url en el siguiente inicio de sesión de un administrador, salvo que web.base.url.freeze esté definido. Compruébalo en Ajustes → Técnico → Parámetros del sistema, si no, los enlaces en los correos seguirán apuntando al host antiguo.
  • Correo saliente: el puerto 25 está bloqueado, usa un relay SMTP cifrado en el puerto 587 o 465, ver Configurar el correo saliente (SMTP).
  • Listas de IP permitidas: la dirección desde la que se conecta tu Odoo ha cambiado. Actualiza cualquier banco, proveedor de pago o API que filtre por IP de origen.
  • Integraciones entrantes: los webhooks, las URL de retorno de los proveedores de pago y las URL de callback de SSO u OAuth deben apuntar al nuevo dominio.
  • Acceso directo a la base de datos para herramientas de BI: en el hosting gestionado no hay conexión directa a PostgreSQL. Usa la API XML-RPC o JSON-RPC de Odoo, o un conector para tu herramienta de BI. En proyectos Bring Your Own Server, ver Acceso directo a la base de datos (solo lectura).
  • Acciones planificadas: en una importación a producción están activas en cuanto arranca Odoo. Asegúrate de que nada se ejecute dos veces contra un sistema externo mientras la instancia antigua siga encendida.
  • Copias de seguridad: las copias automáticas empiezan la primera noche. Revisa la pestaña Copias de seguridad al día siguiente, ver Gestionar copias de seguridad.

Notas según el origen​

CloudPepper​

CloudPepper ejecuta Odoo en un servidor de tu propiedad, así que puedes usar el gestor de bases de datos de Odoo o ejecutar pg_dump tú mismo como en el paso 3. Las bases de datos de estas instalaciones suelen tener usuarios de PostgreSQL adicionales (un usuario de Power BI o de informes, un usuario técnico creado para una migración anterior). Sus copias contienen instrucciones GRANT para esos usuarios, que la importación elimina automáticamente, así que la copia se importa tal cual. Lo que esas herramientas necesitan es una nueva vía de acceso tras el traslado, ver paso 6.

Odoo.sh​

La pestaña Backups de tu proyecto de Odoo.sh ofrece una descarga que incluye el filestore. Es el formato zip nativo de Odoo, así que se importa directamente. Tu código personalizado ya está en el repositorio de GitHub conectado a Odoo.sh: conecta el mismo repositorio a Skysize. Si usa submódulos, ver Incluir un repositorio externo (submódulos).

Odoo Online​

Descarga una copia desde el gestor de bases de datos en odoo.com (Mis bases de datos, luego Descargar). Las bases de datos de Odoo Online funcionan con la edición Enterprise sin código personalizado, así que basta con un proyecto sin repositorio con una rama Enterprise.

Servidor autogestionado o instancia local​

Usa el gestor de bases de datos si está habilitado, o pg_dump con las opciones del paso 3 más la carpeta filestore del directorio de datos.