Un pedido que se registró dos veces en el depósito. Una factura que no se generó bien y nadie lo detecta hasta que el cliente reclama. Un módulo personalizado que alguien armó hace dos años y que ya ningún empleado se anima a tocar, "por si se rompe algo". Si alguna de estas situaciones te resulta conocida, probablemente tu empresa ya llegó al punto en que Odoo deja de ser "el sistema que se implementó" y pasa a ser una herramienta que necesita alguien a cargo todos los días, no solo cuando algo explota.

A ese acompañamiento recurrente, cuyo alcance se acuerda con el proveedor, se le llama soporte Odoo continuo. Este artículo explica qué incluye en serio (y qué no), qué señales indican que ya lo necesitás, en qué se diferencia de una migración de versión, y cuándo puede no hacerte falta todavía.

Implementación y soporte continuo: dos servicios distintos

Una implementación de Odoo es un proyecto: tiene alcance, cronograma y un día de salida a producción. El soporte continuo es otra cosa: empieza el día después de ese lanzamiento y acompaña al sistema mientras la empresa sigue operando con él, sin el cierre acotado de un proyecto (aunque el acuerdo que lo regula tenga su propia vigencia).

  • En la implementación, el objetivo es que el sistema arranque funcionando como se definió.
  • En el soporte continuo, el objetivo es que el sistema siga funcionando a medida que cambian los procesos, el equipo, el volumen de datos y las versiones del propio Odoo.

Confundir ambas lógicas es uno de los motivos más comunes por los que una empresa termina con un Odoo que "funcionaba bien al principio" y después se volvió un problema. El pedido duplicado del inicio de este artículo puede tener distintos orígenes —una configuración puntual, un módulo personalizado, una integración con otro sistema o el propio Odoo base— y determinar cuál de ellos es requiere un diagnóstico, no una suposición: es justamente el tipo de revisión que suele quedar en el aire cuando el proyecto de implementación "ya se cerró" y nadie sigue de cerca el sistema.

Qué incluye un servicio de soporte Odoo continuo (y qué depende del acuerdo)

Un soporte continuo completo típicamente cubre:

  • Resolución de incidencias, con un canal definido para reportarlas.
  • Evaluación de actualizaciones de versión, antes de decidir si y cuándo aplicarlas (no la migración completa en sí; ver más abajo).
  • Mantenimiento de las personalizaciones: módulos a medida, integraciones con otros sistemas (facturación, pagos, logística) y automatizaciones agregadas sobre el Odoo base.
  • Monitoreo del funcionamiento del sistema, para detectar una caída de performance o un error recurrente antes de que lo note un usuario.
  • Soporte de infraestructura y soporte funcional: el primero resuelve que el servidor y el entorno estén arriba; el segundo, que el sistema resuelva bien los procesos de negocio. Un servicio completo cubre los dos.
  • Acompañamiento al equipo interno para pedidos chicos: un reporte nuevo, un ajuste de permisos, una mejora menor de proceso.
  • Copias de seguridad y continuidad, verificando que los respaldos existen, se prueban y permiten restaurar el sistema si algo sale mal.

Lo que diferencia a un soporte bien armado de uno improvisado no es esta lista (que en el papel suele ser parecida entre proveedores), sino los límites que la acompañan, porque sin límites claros la lista es una promesa vacía:

  • Qué depende del plan contratado. No todos los acuerdos de soporte cubren lo mismo: horas incluidas por mes, cantidad de incidencias, si el monitoreo es activo o solo a pedido. Esto se define en el acuerdo, no se asume.
  • Horarios de atención. Un soporte continuo define en qué franja horaria se atienden incidencias (por ejemplo, horario comercial) y si existe o no una vía para urgencias fuera de ese horario. Sin esto definido, "soporte continuo" puede significar cosas muy distintas para el proveedor y para el cliente.
  • Tiempo de respuesta vs. tiempo de resolución. Son dos cosas distintas y conviene no confundirlas: el tiempo de respuesta es cuánto tarda alguien en tomar el reclamo y empezar a trabajarlo; el tiempo de resolución es cuánto tarda en quedar efectivamente resuelto. Un acuerdo serio define ambos con claridad, aunque el tiempo de resolución pueda estirarse cuando depende de un tercero (el propio Odoo, una integración externa, un proveedor de hosting): una respuesta rápida sin ningún compromiso sobre la resolución deja el problema a mitad de camino.
  • Qué es una "mejora chica" y qué no. Un ajuste de un reporte, un cambio de permisos o un campo nuevo en un formulario suele entrar dentro del soporte continuo. Un módulo nuevo completo, una integración con un sistema que antes no existía, o un cambio que afecta a varios procesos a la vez, ya no es una mejora chica: es un desarrollo con alcance propio, que se cotiza y planifica aparte (aunque lo ejecute el mismo equipo que da el soporte).

Señales de que tu empresa necesita soporte Odoo continuo

Algunas señales típicas de que un Odoo quedó sin un soporte adecuado:

  • Las actualizaciones de versión se postergan año tras año "porque da miedo que algo se rompa".
  • Cada incidencia la resuelve una persona distinta, sin un criterio común ni un registro de qué se hizo.
  • Los módulos personalizados fueron hechos por proveedores distintos a lo largo del tiempo y nadie tiene una visión completa de cómo interactúan entre sí.
  • Cuando alguien del equipo interno que "sabía manejarse" con Odoo se va de la empresa, el conocimiento se va con esa persona.
  • Los pedidos de mejora chicos se acumulan en una lista que nunca se atiende, porque no hay un servicio dedicado a resolverlos.

Si alguna de estas situaciones te resulta familiar, probablemente el costo de no tener soporte continuo ya se esté pagando, aunque no aparezca en una factura puntual: horas del equipo dedicadas a resolver problemas a las apuradas, decisiones postergadas por miedo a romper algo, y una dependencia cada vez mayor de quien conoce el sistema "de memoria".

Mantenimiento y migración de versión: dos alcances distintos

Odoo publica una versión mayor nueva de forma regular, con mejoras funcionales y cambios técnicos que pueden afectar a los módulos personalizados existentes. Esto conviene separarlo en dos decisiones distintas, que suelen mezclarse por error:

  1. Evaluar cuándo conviene migrar sí puede ser parte del acompañamiento continuo: quien da soporte sigue de cerca el calendario de versiones de Odoo y recomienda, con criterio técnico, cuándo actualizar y cuándo esperar un ciclo más.
  2. Ejecutar la migración completa es otro trabajo: adaptar los módulos personalizados a la versión nueva, probar que todo sigue funcionando y hacer un ensayo previo en un entorno de prueba antes de aplicar el cambio en producción, siguiendo el camino que recomienda la propia documentación de Odoo para actualizaciones mayores. Suele presupuestarse aparte, salvo que el acuerdo de soporte la contemple expresamente.

Sobre el fin del soporte de una versión, conviene matizar una idea que suele repetirse de forma imprecisa: Odoo diferencia un período de soporte estándar por versión de la posibilidad, bajo condiciones específicas, de contratar un soporte extendido de pago. Que termine el soporte estándar de la versión que usa tu empresa no significa automáticamente que te quedás sin ningún tipo de asistencia de un día para el otro: significa que hay una decisión a tomar —actualizar en un plazo razonable, evaluar si el soporte extendido aplica a tu caso, o migrar— y que esa decisión conviene tomarla con tiempo, no empujada por una emergencia.

Cuándo conviene contratar soporte Odoo continuo (y cuándo no)

Conviene cuando pasa algo de esto:

  • Odoo sostiene procesos críticos del negocio (ventas, stock, facturación, producción) y una falla ahí tiene costo real, no solo molestia.
  • Hay personalizaciones o integraciones propias que nadie del equipo interno domina por completo.
  • El equipo interno ya está ocupado con su trabajo del día a día y no tiene tiempo ni perfil técnico para hacerse cargo de actualizaciones, incidencias de configuración o monitoreo.
  • Depender de una sola persona (interna o externa) para que el sistema siga funcionando es un riesgo que la empresa no quiere correr.

No hace falta, o puede bastar otra modalidad, cuando:

  • La empresa tiene un equipo interno con capacidad técnica real para resolver incidencias de configuración, dar seguimiento a actualizaciones y mantener las integraciones existentes: en ese caso puede no hacer falta un proveedor externo, aunque el sistema sigue necesitando ese mantenimiento, lo dé quien lo dé.
  • El uso de Odoo es acotado (pocos usuarios, procesos simples, sin personalizaciones críticas) y las necesidades de ajuste son puntuales y esporádicas, no constantes.
  • La empresa recién migró y todavía está dentro del período de garantía o acompañamiento post-implementación del proyecto: conviene revisar qué cubre exactamente ese período, porque no siempre incluye monitoreo activo o mejoras, solo la resolución de fallas del propio proyecto recién entregado.

En estos últimos casos puede alcanzar con soporte puntual por incidente, en vez de un acuerdo de soporte continuo. La diferencia depende de cuánto dependen los procesos del día a día de que Odoo funcione sin interrupciones, y de si hay alguien, adentro o afuera de la empresa, responsable de que eso pase.

Cómo trabajamos el soporte continuo de Odoo en DCisGlobal

En la práctica, esto es lo que hacemos:

  • Cuando recibimos una instalación heredada —un Odoo que implementó otro proveedor, o el propio equipo interno— arrancamos con un relevamiento del estado real: qué módulos personalizados tiene, qué integraciones están activas, qué versión corre y qué tan alejada está del soporte estándar vigente. Evitamos tocar producción hasta tener ese mapa completo, salvo que una urgencia real exija intervenir antes: en ese caso, igual seguimos relevando en paralelo.
  • Registramos las decisiones, no solo las incidencias resueltas: por qué se postergó una actualización, por qué se descartó un cambio, qué alternativa se evaluó y no se usó. Eso evita que, un año después, alguien repita una discusión que ya se tuvo, o repita un error que ya se conocía.
  • Probamos los cambios antes de aplicarlos en producción, en un entorno separado, especialmente antes de una actualización de versión o un cambio sobre un módulo personalizado. La regla es simple: ningún cambio que pueda afectar un proceso crítico se aplica primero en el sistema que la empresa usa todos los días.
  • Evitamos que el conocimiento quede en una sola cabeza. Documentamos cómo está armada cada instalación (configuración, personalizaciones, integraciones) para que el soporte no dependa de que una persona puntual "se acuerde cómo es" el sistema de un cliente. Si esa persona no está disponible un día, otra puede seguir resolviendo.

Imaginemos una pyme que implementó Odoo hace dos años con un freelance que ya no trabaja con ellos (es un ejemplo hipotético, no un cliente real de DCisGlobal). Nadie documentó las tres personalizaciones que tiene el sistema de facturación. Cada vez que Odoo saca una versión nueva, la empresa posterga la actualización "por las dudas", y ya acumula dos versiones de atraso. En un caso así, lo primero que hacemos no es actualizar: es relevar qué hace cada personalización, documentarla, y recién con ese mapa evaluar un camino de actualización por etapas, probado en un entorno de prueba antes de tocar producción.

Este servicio se enmarca dentro de nuestro servicio de sistemas open source, donde implementamos y damos soporte continuo a Odoo (y a otros sistemas open-source) con este mismo criterio. Si tu empresa ya usa Odoo y no tenés del todo claro en qué estado está esa instalación —qué tan al día está la versión, qué tan documentadas quedaron las personalizaciones, quién responde cuando algo falla—, podés empezar con nuestro autodiagnóstico o agendar directamente un diagnóstico con el equipo. Sirve para evaluar tu caso puntual y definir qué tipo de acompañamiento tiene sentido para tu empresa.

Dino Cisterna — DCisGlobal