Migrar Odoo es un proceso largo y complicado, el cual suele ser subestimado en su complejidad. Por lo general, la gente sin experiencia suele subestimarlo. Es como dicen en Estados Unidos "an honest mistake", la subestimación es fruto del desconocimiento y no de un engaño comercial.
Ahora, hay empresas que brindan servicios de migración automatizado. No vamos a hablar de ello aquí debido a que el objetivo es describir los desafíos de un proceso de migración de un Odoo muy customizado (como son la mayoría de las instalaciones que conocemos). Los servicios automatizados de migración lo hacen sobre instalaciones que son a nivel estructural (estructuras de datos y módulos) similares, lo cual las hace pasibles de automatización. En las instalaciones muy customizadas, esto no es posible.
Tenemos tres maneras de migrar Odoo. La primera es la seguida por OpenUpgrade que toma la base de datos original y la migra a la versión destino (previa migración de las customizaciones). No es un enfoque malo teniendo en cuenta los tiempos involucrados en migrar la base de datos (los cuales pueden llegar a ser prohibitivos). Tiene el problema que se debe migrar de versión en versión. Por ejemplo si uno esta trabajando con la versión 11.0 y desea pasar a la versión 16.0, uno debe migrar primero a la versión 12 luego a la 13 luego a la 14 para llegar a la versión 15 para finalmente llegar a la versión 16 (algo bastante común, el año pasado tuve que migrar una instalación de la versión 6 a la versión 15, y otra de la versión 8 a la versión 15 tambien. Con OpenUpgrade hubiese sido una pesadilla).
La segunda forma de migrar (y es la opción más popular) es hacer una migración básica de los datos maestros y saldos. La idea es uno primero migra los datos maestros: clientes, proveedores, empleados, usuarios, cuentas contables (a veces), saldos de cuenta corriente, productos, stocks, cheques en cartera (y alguno agregará cupones de tarjeta de crédito aun no acreditados). Y con eso se arranca en la nueva versión. Se pierde el detalle transaccional de la historia del sistema, por lo cual muchas veces se tiene en línea el sistema anterior. Pero se lo realiza de manera rápida. Por lo general esto tarda entre uno y dos meses, tres quiza.
La tercer manera es migrar Odoo es migrando todos los datos (attachments, mensajes, historia de las transacciones, etc etc). Que es la opción más compleja (y cara) y es la que uno muchas veces encara (principalmente porque perder la historia transaccional no es una opción a nivel negocios).
Migrar la base de datos de Odoo en su totalidad presenta los siguientes desafíos:
- Todas las customizaciones necesitan ser migradas (o asegurarse que funcionan sin problema en la nueva versión). Y esto no es gratis, a modo de ejemplo tengamos en cuenta que migrar la localización argentina de versión a versión consume alrededor de 100 horas. O sea migrar las customizaciones no va a ocurrir de la noche a la mañana. Y esto puede llegar a ser problemático si hablamos de la contabilidad y stock, ya que en Odoo de la versión 13 en adelante la contabilidad varió sustancialmente y el módulo de stock cambia sus estructuras con frecuencia.
- Muchas veces los datos en el sistema origen no son "limpios". O no presentaron problemas cuando se utilizaron en la versión original de Odoo pero ahora son inadmisibles en la nueva versión de Odoo. Esto lleva a la necesidad de involucrar a los usuarios para dar lugar a sus correcciones, y estos tiempos de espera van a dilatar más el proceso de migración
- Esto no es un dato de color, pero de versión en versión la gente de Odoo suele cambiar los nombres de los objetos (por ejemplo cambiaron product.uom a uom.uom) por motivos que son un misterio (y se estima que seguirán siendolo). O por ejemplo se cambiaron nombres de campo (como origin a invoice_origin). Pero a veces cambian la lógica, por ejemplo a partir de la versión 13 desaparecieron los modelos account.invoice y account.invoice.line, siendo refundidos en account.move y account.move.line.
- Se deben migrar no solo datos maestros, sino hacer que las transacciones (por ejemplo ingresar facturas, confirmarlas, ingresar sus respectivos pagos y conciliaciar dichos pagos con las facturas) se ejecuten según la lógica de Odoo. Esto se debe aplicar tambien para compras, ventas e inventarios. Lo cual hace que un proyecto de migración se transforme en un proyecto de interfaces.
- Otro gran inconveniente el de los recursos humanos disponibles para el proyecto. Migrar Odoo requiere la participación de desarrolladores con mucho seniority en Odoo. Por la complejidad en las transacciones detallada en el punto anterior se debe conocer muy bien como extraer las transacciones del sistema origen, pero ademas como actualizar el sistema destino (conociendo detalles como por ejemplo, al crearse un pago automaticamente se crea un movimiento contable). Muchas veces se asigna personal con poca experiencia al proceso de migrar Odoo, y esto se paga
- Culturalmente se subestima las migraciones. Nunca fueron fáciles en ningún sistema (las migraciones de un poderoso sistema ERP suelen tardar mínimo 18 meses) y no van a ser sencillas en Odoo (por más que tengan videos muy bonitos).
- Odoo es un buen sistema pero no es precisamente rápido. Para hacer transacciones puntuales la performance de Odoo es bastante buena. Por ejemplo para permitir el ingreso de una factura, o validar la misma. Ahora, cuando se tienen que procesar miles de registros (el escenario común cuando se necesita migrar decenas de miles de facturas) ya no es tan rápido. En realidad en esas situaciones Odoo es muy lento. El ORM de Odoo es lento de por si. Es sorprendentemente lento y creo que el mismo necesita ser revisado. Igualmente existen herramientas (por ejemplo el método load) o PostgreSQL que aceleran el procesamiento, pero requieren otros skills en el equipo de trabajo y hacen más complejo el trabajo de migración
- Otro punto es la ventana de procesamiento. Muchas veces no se cuenta con el tiempo necesario para no realizar transacciones en el sistema origen mientras esperamos que se actualice el sistema destino. Para ello se requiere otra estrategia, que consiste en migrar primero los datos históricos y luego agregarle las últimas transacciones (un enfoque que puede ser más caro pero es más seguro debido a que es de caracter repetible).
- Muchas veces no es realista la planificación del proyecto de migración. No solo en los tiempos, sino tambien en las tareas de la puesta en marcha, testeo y paralelo. El testeo tiende a ser subestimado (sobre todo el involucramiento de los usuarios finales y los tiempos de espera a los mismos). Tambien se subestiman las tareas necesarias para la puesta en marcha del nuevo Odoo, ya que hay muchas tareas manuales que no son tenidas en cuenta (por ejemplo, configuración de la contabilidad o de las múltiples empresas, o de los e-mail templates)
Por estos motivos creo que uno debe realizar las migraciones siempre y cuando sea necesario (honestamente, creo que todas las empresas tienen desafíos de negocio más importantes que estar ejecutando proyectos riesgosos como la migración de su ERP). Aquí huimos de los procesos de migración de la misma manera que uno huye de la Peste Negra. Las migraciones no solo son caras, sino ademas complejas y riesgosas. Y creemos que hay proyectos en Odoo (independientemente de su versión) que le agregan mayor valor al cliente.