Odoo Online a Odoo.sh: ¿la integración exige migrar?

Volver

Kevin Riedl

13 minutos de lectura · 5 nov 2026
Última revisión 5 de noviembre de 2026

Siguiente

Tu proyecto de almacén necesita intercambiar datos con Odoo. Alguien añade «migrar a Odoo.sh» al presupuesto antes de demostrar qué parte del proceso no funciona en la configuración actual. El cambio puede estar justificado. Falta la evidencia que lo conecte con un requisito de negocio aprobado.

Migra de Odoo Online a Odoo.sh cuando un requisito demostrado necesite capacidades que tu entorno actual no proporciona y que el destino propuesto sí admita. Resuelve la ruta de versiones y la responsabilidad operativa antes de programar el traslado. Si la configuración existente o una integración externa aprobada cumple el requisito, permanecer en Online sigue siendo una opción válida.

Fuentes comprobadas: 5 de noviembre de 2026. Esta guía utiliza fuentes oficiales de Odoo 20.0 y las preguntas frecuentes de Odoo.sh. El ejemplo del almacén y los doce casos descargables son ayudas de diseño ficticias. No migramos una base, no instalamos un módulo y no ejecutamos los controles de aceptación propuestos.

¿Qué requisito justificaría el cambio?

Escribe la regla de negocio sin depender de la tecnología propuesta y demuestra después qué capacidad falta. Pedir un intercambio de información con el almacén es demasiado amplio para determinar el alojamiento. Especifica quién puede realizar la acción, a qué registro afecta y qué debe cumplirse al terminar.

Considera el requisito ficticio R-17: una recepción de almacén solo puede aceptarse cuando el certificado del proveedor coincide con la revisión aprobada para esa recepción. El responsable de operaciones quiere aplicar la regla a las rutas pertinentes de usuario e integración. Es un requisito inventado, no una afirmación sobre un modelo o campo concreto de Odoo ni sobre una configuración instalada de Quality.

La investigación puede producir dos resultados. El equipo podría demostrar una configuración existente que cumple R-17. También podría identificar una carencia revisada que exija un módulo Python personalizado e instalable. No deduzcas cuál es el resultado a partir del ejemplo: inspecciona la aplicación real y el comportamiento solicitado.

Una propuesta puede responder las tres primeras preguntas y seguir sin estar lista para aprobarse. La necesidad técnica, la idoneidad de la plataforma y la preparación operativa requieren evidencias distintas. Conserva visibles sus puntos pendientes; una demostración correcta no responde automáticamente a todas las demás preguntas.

¿Puede la integración permanecer en Odoo Online?

Evalúa las operaciones admitidas y la configuración necesarias antes de cambiar de alojamiento. Un componente externo que lee registros autorizados o invoca una operación existente adecuada no demuestra, por sí solo, que haga falta un módulo propio. Confirma el derecho de acceso, los permisos y la operación real; después demuestra el comportamiento con las versiones desplegadas.

La referencia de API de Odoo 20 sitúa el acceso a la API externa en los planes Custom. La ausencia de ese derecho plantea una cuestión comercial que debes resolver antes de considerarla una limitación del alojamiento.

Una pantalla de estado del almacén podría necesitar únicamente una lectura autorizada de información seleccionada. Su aceptación debe mostrar los registros correctos para la identidad prevista, los campos necesarios y la carga que genera el diseño. Ninguna de esas observaciones exige dar por hecho que existirá un nuevo módulo personalizado.

Para eventos salientes, la documentación de automatizaciones describe una acción de webhook que envía campos seleccionados del registro. Demuestra su disponibilidad e idoneidad en tu configuración. Una descripción de la función no prueba la entrega de extremo a extremo.

La guía de límites de integración de la API de Odoo desarrolla los derechos de acceso, las transacciones y los protocolos. Utiliza esas restricciones para evaluar la conexión. La decisión de alojamiento debe registrar qué requisito sigue sin resolverse después de esa revisión, si queda alguno.

¿Cuándo cambia la decisión un módulo personalizado?

Una necesidad demostrada de instalar código de aplicación cambia las opciones de despliegue elegibles. Identifica primero el comportamiento mínimo que falta y por qué la configuración existente no lo proporciona. Después revisa el módulo propuesto como una dependencia de software que necesita mantenimiento, responsable y criterios de aceptación. La elección de alojamiento viene a continuación.

La documentación de Odoo Online excluye los módulos personalizados y los de Apps Store. Esa restricción importa cuando ya se ha demostrado la necesidad de instalar uno.

Para R-17, pide al implementador que muestre la aceptación de un certificado coincidente y el rechazo de una revisión obsoleta. Incluye cada ruta pertinente, también la identidad que utilizará la integración. Una advertencia en pantalla no basta si el requisito aprobado exige impedir que se acepte la recepción.

Si la configuración nativa supera esos casos, conserva la evidencia y reconsidera la propuesta de módulo. Si la carencia persiste, documenta el punto de extensión, las acciones permitidas y el comportamiento esperado ante fallos. La revisión de aceptación de módulos Odoo ofrece un patrón separado para evaluar código y comportamiento; no demuestra que este módulo concreto sea necesario.

Mantén las mejoras opcionales de comodidad fuera de la justificación mínima del cambio. Mezclar un control obligatorio con deseos independientes de interfaz puede ocultar por qué hace falta migrar y dificultar la aprobación del alcance. Registra ese trabajo adicional por separado para que el comprador decida expresamente.

¿Admite Odoo.sh todo el diseño propuesto?

Revisa el módulo Odoo y su entorno de ejecución. Enumera componentes de fondo, conexiones externas y dependencias asumidas. La plataforma puede ser adecuada para la extensión mientras otro componente necesita ejecutarse fuera. Resuelve esa distribución antes de prometer que todo funcionará en un único alojamiento.

Las preguntas frecuentes de Odoo.sh descartan procesos adicionales de larga duración y la instalación arbitraria de paquetes del sistema. Contrasta esos límites con la lista de dependencias propuesta.

Supón que la integración incluye un proceso que escucha continuamente eventos del almacén. Pregunta si puede funcionar como servicio externo admitido y qué equipo lo mantendría. Alojar el módulo Odoo en el destino no aprueba automáticamente el entorno de ejecución de ese proceso.

Utiliza un inventario de despliegue con una fila por componente. Registra su finalidad, privilegios necesarios, persistencia, patrón de comunicación y responsable. Si un tercero suministra el módulo, pide evidencia de la revisión exacta y las dependencias que utilizarás. Un nombre de producto o una demostración en otra instalación no prueba la compatibilidad de tu destino.

Si una dependencia imprescindible no encaja en la arquitectura admitida, vuelve a revisar el diseño. El resultado puede ser un despliegue dividido, otra implementación u otra opción de alojamiento. Es una conclusión útil antes de comprometer una fecha para trasladar la base.

¿Puede trasladarse la base cuando la necesitas?

Inspecciona la versión exacta de origen antes de acordar una fecha. Registra el destino y la ruta admitida entre ambos. Separa la compatibilidad de versiones del tiempo necesario para adaptar módulos, comprobar comportamientos y obtener aceptación empresarial. Cualquiera de esos puntos puede limitar el calendario aunque los demás parezcan resueltos.

La guía de cambio de alojamiento de Odoo exige que las versiones intermedias de Online pasen primero a la siguiente versión principal, esperando su publicación si fuera necesario.

No sustituyas la versión real de tu base por el anuncio del lanzamiento más reciente. El acta de decisión necesita la versión observada, la fecha y la ruta de traslado confirmada. Si todavía no está disponible, marca la migración como aplazada y revisa qué parte de la necesidad puede atenderse mientras tanto.

Una integración externa temporal puede ser candidata durante la espera si cumple el requisito aceptado. No la presentes como un sustituto equivalente cuando deje sin aplicar el control imprescindible. Explica qué capacidad entregas ahora y cuál sigue bloqueada.

Para el ensayo posterior, utiliza las comprobaciones de conciliación de migraciones Odoo para definir la evidencia del destino restaurado. Una importación compatible con la versión es una parte de la aceptación; el responsable de negocio sigue necesitando registros y procesos correctos.

¿Quién se responsabiliza del sistema después del cambio?

Nombra a quienes pueden aprobar cambios de código, administrar accesos y recuperar el proceso de negocio. Sus responsabilidades deben seguir siendo claras cuando cambie el proveedor. Incluye ese traspaso operativo en la aprobación: una nueva ruta de despliegue genera trabajo que una demostración funcional no asigna a nadie.

La guía de proyectos de Odoo.sh utiliza un repositorio GitHub, una versión principal y una suscripción elegible. Advierte que la importación sobrescribe los datos existentes en la rama.

Son controles de proyecto propuestos, no garantías adicionales del proveedor de alojamiento. Verifica los accesos mediante la configuración de cuentas admitida. Tener un nombre de repositorio en un documento no basta si la empresa responsable no puede recuperar el código ni gestionar quién puede modificarlo.

Pide una estimación que separe migración, mantenimiento de módulos y operación continua. La guía de alcance y presupuesto de actualizaciones Enterprise aborda las diferencias contractuales y presupuestarias. Elegir el alojamiento no determina qué mantenimiento ha aceptado prestar un proveedor.

¿Qué evidencia debe incluir el acta de decisión?

Registra el requisito, la condición observada, la respuesta propuesta y la evidencia necesaria para aceptarla. Conserva los casos sin resolver en ese estado. La plantilla incluye motivos para quedarse, motivos para investigar un traslado y motivos para detener la planificación hasta resolver una dependencia.

Descarga la plantilla de decisión de alojamiento y evidencia. Todas las filas tienen estado NOT_RUN, aprobación de la política PENDING y evidencia real vacía. La respuesta propuesta es una hipótesis que revisar, no una autorización para migrar ni un resultado de compatibilidad nativa.

En cada caso aplicable, adjunta la configuración o revisión observada y las pruebas de aceptación. Si un caso no corresponde, registra por qué y quién lo acordó. Conserva una copia sin modificar de la plantilla para que otro revisor pueda distinguir los controles propuestos de lo que el proyecto demostró.

¿Qué aprobaríamos antes de programar la migración?

Aprueba una carencia concreta, un diseño de destino admitido y un traspaso con responsables disponibles. La ruta de versiones y el alcance del ensayo deben permitir un plan realista. Si la configuración actual ya cumple el requisito, documenta ese resultado y conserva el despliegue menor hasta que otra necesidad demostrada cambie la decisión.

La guía de selección tecnológica ofrece una evaluación más amplia de las opciones de implementación. El caso Twinsoft AI aporta contexto de otro proyecto, no evidencia de que este escenario de almacén o alojamiento se haya implementado.

La consultoría tecnológica de Wavect puede convertir una recomendación de alojamiento en un alcance revisable. Revisa tu decisión de alojamiento Odoo con el proceso requerido, la versión actual y la extensión propuesta.