Necesito migrar de odoo.sh en Argentina, ¿qué debo hacer?

La pandemia de Covid-19 plantea nuevos desafíos y realidades para las pymes en Argentina. Pero por sobre todo nuevos presupuestos debido a que no van a haber la misma cantidad de clientes que antes de la cuarentena, y los pocos que queden no van a tener la capacidad de gasto que tenían antes de marzo del 2020. Es por ello que los presupuestos disponibles para los gastos de sistemas, no van a ser los mismos que los de meses atras y cuesta pensar que van a ser mayores. 

Es por ello que en las próximas semanas y en lo que queda del año, muchas empresas se van a encontrar con la decisión de renovar las licencias de Odoo.sh por otro año más, o hacer otra cosa. No por odoo.sh como solución (nadie lo pone en duda), sino por el costo de mantener dicho servicio, el cual se va a tornar prohibitivo para muchas pymes argentinas. Es por eso que estamos escribiendo este post, que es para explorar "que otra cosa".

Primero y fundamental, contactar un consultor que conozca Odoo. Sobre todo un consultor que conozca tecnicamente Odoo (aca es fundamental que conozca como funcionan los webservices de factura electrónica) y que cuente con un conocimiento funcional sólido. Debido a dicho profesional va a tener que realizar las siguientes tareas: instalar Odoo Community en un VPS, migrar datos maestros, saldos de clientes/proveedores, saldos contables, stocks, etc. Tambien el consultor deberá resolver la migración de módulos custom si los mismos existiesen. Y si se encuentran usando módulos enterprise, migrar los mismos.

Segundo, se debe planificar la migración en si misma. La primer tarea a realizar es un gap analysis donde se debe definir como cubrir los siguientes gaps entre odoo.sh y la versión community: localización (sobre todo, que hacer con los comprobantes de factura electrónica emitidos), módulos custom desarrollados, módulos enterprise que esten en uso, datos maestros y y que operaciones a migrar (suena lindo migrar todo pero reconozcamos que no vale la pena hacerlo). Este gap analysis brindará el plan del proyecto a seguir para realizar la migración a la nueva plataforma. Hay que tener en cuenta algo, en este punto van a surgir items que no valen la pena migrar y otros que no se van a poder migrar (ya sea por costo o por tiempos disponibles). 

Tercero y por último, llevar adelante la migración. Con respecto a la migración de módulos custom, no queda otra que decir que se debe migrarlos. Si se debe saber muy bien como migrar los datos maestros y las transacciones. Las herramientas de importación/exportación que provee Odoo no son las ideales para migrar transacciones o datos complejos (como por ejemplo clientes/proveedores) o transacciones (por ejemplo, ordenes de compra). Es más, lo mejor es planificar una migración donde los mismos datos se van a tener que actualizar múltiples veces (lo cual es una opción más realista).

El mejor plan de migración es uno en el que tenga en paralelo los dos sistemas. Generará más trabajo por parte de los usuarios y por parte del consultor, pero es el plan de migración que plantea menor cantidad de riesgos. Y por último, planifique la migración con tiempo. Cualquier migración de sistema no es un proyecto que se hace de la noche a la mañana. Es un proyecto que lleva mucho tiempo (tranquilamente puede ser la mitad del tiempo que demoró el proyecto de implementación original de Odoo) y tiene sus riesgos. Y es un proyecto costoso, no es barato migrar. Por eso debe analizar bien el proyecto y compararlo tambien con el costo de odoo.sh (posiblemente sea buena idea seguir con el servicio).