Migrando de Odoo 17/18 a Odoo 19: Guía Completa

La migración es una de las operaciones de mayor riesgo en el ciclo de vida de un ERP: la pérdida de datos, los módulos personalizados rotos y el tiempo de inactividad prolongado son riesgos reales que requieren una planificación y ejecución cuidadosas.

Esta guía proporciona una metodología de migración práctica, paso a paso, para organizaciones que migran de Odoo 17 u Odoo 18 a Odoo 19 Enterprise. Cubre todo, desde la evaluación inicial y el mapeo de datos hasta las actualizaciones de módulos personalizados, los procedimientos de prueba y el plan de transición de puesta en marcha.

Conclusiones clave

• La compatibilidad del módulo personalizado debe verificarse con los cambios de API de Odoo 19
• La migración de datos se realiza a través de la plataforma de actualización oficial de Odoo o OpenUpgrade
• Un entorno de pruebas paralelo es obligatorio antes del corte de producción.
• Los períodos financieros deben cerrarse antes de la transición para evitar problemas de conciliación.
• Todas las integraciones de terceros necesitan una nueva verificación después de la migración.
• El plan de reversión debe documentarse y probarse antes de entrar en funcionamiento.

---

Planificación de la migración: fase de evaluación

Antes de escribir un único guión de migración, invierta tiempo en una evaluación exhaustiva. Las migraciones fracasan con mayor frecuencia debido a una planificación inadecuada, no a una complejidad técnica.

Paso 1: Inventario de su entorno actual

Documente cada componente de su instalación actual de Odoo:

Current Environment Inventory:
- Odoo version: 17.0.x or 18.0.x
- Edition: Community or Enterprise
- Database size: X GB, Y records in sale.order, Z in account.move
- Installed modules: [list all modules]
- Custom modules: [list with developer contact]
- Third-party connectors: [Amazon, Shopify, etc.]
- Active integrations: [API, webhooks, cron jobs]
- Customized reports: [list]
- Custom fields (Studio or code): [list]
- Server specs: RAM, CPU, disk
- PostgreSQL version:

Paso 2: Clasificar módulos personalizados

Para cada módulo personalizado, determine:

---

Elegir su ruta migratoria

Ruta 1: Servicio de actualización oficial de Odoo

Odoo SA proporciona un servicio de actualización automatizado en upgrade.odoo.com. Usted envía su base de datos, ellos ejecutan scripts de migración desarrollados y mantenidos por Odoo SA y usted recibe una base de datos actualizada.

Ventajas:

• Soporte oficial y pruebas por parte de Odoo SA.
• Maneja los cambios en el esquema de la base de datos automáticamente.
• Adecuado para Odoo estándar con personalizaciones mínimas

Contras:

• Requiere enviar datos de producción a los servidores de Odoo.
• Control limitado sobre el proceso de migración.
• La migración de módulos personalizados es su responsabilidad

Ruta 2: OpenUpgrade (herramienta comunitaria)

OpenUpgrade es un proyecto de código abierto que proporciona scripts de migración para Community.

Ruta 3: Instalación nueva con importación de datos

Para instancias muy personalizadas o versiones muy antiguas:

1. Configure una nueva instancia de Odoo 19 Enterprise
2. Reconfigure todos los módulos y configuraciones.
3. Exportar datos críticos del sistema antiguo.
4. Importe mediante la herramienta de importación de Odoo o scripts de migración personalizados
5. Vuelva a ingresar manualmente los saldos iniciales para la contabilidad.

Este camino es más lento pero proporciona el punto de partida más limpio.

Recomendado para la mayoría de las migraciones de Odoo 17/18 → 19: Ruta 1 o 2 combinada con un esfuerzo de redesarrollo de módulo personalizado paralelo.

---

Preparación previa a la migración

Cierre de períodos financieros:

Antes de la migración:

1. Bloquear todos los períodos anteriores al mes actual en Odoo Accounting
2. Ejecute los informes de cuentas por cobrar y por pagar antiguos y concilie las diferencias.
3. Conciliar todos los extractos bancarios hasta la fecha de migración.
4. Publique todos los borradores de facturas que deben incluirse en los datos históricos.

Haga una copia de seguridad de todo:

# PostgreSQL backup
pg_dump -h localhost -U odoo_user -Fc odoo_production > \
    odoo_prod_backup_$(date +%Y%m%d_%H%M%S).dump

# Filestore backup (attachments, images)
tar -czf odoo_filestore_$(date +%Y%m%d).tar.gz \
    /var/lib/odoo/.local/share/Odoo/filestore/

# Configuration backup
cp /etc/odoo/odoo.conf odoo_conf_backup_$(date +%Y%m%d).conf

---

Configuración del entorno de migración

Configuración de infraestructura:

# Install Odoo 19 Enterprise on migration server

# Install PostgreSQL 15+
sudo apt install postgresql-15 postgresql-contrib

# Install Python 3.12 and dependencies
sudo apt install python3.12 python3.12-dev python3.12-venv \
    libxml2-dev libxslt1-dev libldap2-dev libsasl2-dev \
    libtiff5-dev libjpeg8-dev libopenjp2-7-dev zlib1g-dev \
    libfreetype6-dev liblcms2-dev libwebp-dev libharfbuzz-dev \
    libfribidi-dev libxcb1-dev

# Clone Odoo 19 Enterprise
git clone https://github.com/odoo/odoo.git -b 19.0 /opt/odoo19
git clone https://github.com/odoo/enterprise.git -b 19.0 /opt/odoo19-enterprise

# Install Python dependencies
pip3.12 install -r /opt/odoo19/requirements.txt

---

Migración de módulo personalizado

Esta fase es la que requiere más tiempo. Cada módulo personalizado requiere:

1. Actualizar la versión del manifiesto:

# Change from:
'version': '17.0.1.0.0',
# To:
'version': '19.0.1.0.0',

2. Actualizar la sintaxis de la vista:

<!-- Old (v16 and earlier): -->
<field name="state" attrs="{'invisible': [('active', '=', False)]}"/>

<!-- New (v17+): -->
<field name="state" invisible="not active"/>

3. Pruebe cada módulo de forma independiente:

# Install and test each custom module
python3 odoo-bin -d test_db -i my_custom_module --stop-after-init
python3 odoo-bin -d test_db --test-enable -u my_custom_module

---

Validación y prueba de datos

Validación del recuento de registros:

Compare los recuentos de registros entre la base de datos de origen y la migrada:

# Run on both source and target to compare
models_to_check = [
    'res.partner', 'product.template', 'product.product',
    'sale.order', 'purchase.order', 'account.move',
    'stock.quant', 'mrp.production', 'hr.employee'
]

for model in models_to_check:
    count = env[model].search_count([])
    print(f"{model}: {count}")

Lista de verificación de pruebas de aceptación del usuario:

• [] Todos los menús y elementos de navegación accesibles
• [] Flujos de trabajo clave: orden de venta → entrega → factura → pago
• Contabilidad: asientos de diario, conciliaciones bancarias, informes
• Inventario: recibos, entregas, valoración de stock.
• Fabricación: BOM, órdenes de trabajo, controles de calidad (si corresponde)
• RRHH: empleados, gestión de bajas, nómina (si aplica)
• [] Funcionalidad del módulo personalizado verificada por usuarios empresariales
• [] Los informes se generan correctamente y coinciden con los resultados previos a la migración.
• [] Integraciones externas (API, webhooks) probadas en puesta en escena

---

Plan de transición de entrada en funcionamiento

Planificación de ventana de transición:

Elija una ventana de transición con un impacto empresarial mínimo:

• Fin de semana (del sábado por la tarde al domingo por la mañana para la mayoría de las empresas)
• Fin de mes fiscal (simplifica el ingreso del saldo inicial)
• Después del último día hábil antes de un día festivo (tiempo de reserva adicional)

Lista de verificación para la transición:

T-48 hours:
[ ] Final communication to all users about downtime window
[ ] Freeze all non-critical transactions in old system
[ ] Verify migration server is ready
[ ] Complete last data validation run

T-0 (Cutover Start):
[ ] Put old system in maintenance mode (disable user access)
[ ] Create final backup of production database
[ ] Run final migration on this backup
[ ] Verify record counts and financial balances
[ ] Test all critical workflows
[ ] DNS/URL cutover to new system
[ ] Smoke test from user devices (desktop, mobile)

T+2 hours (Go-Live Verification):
[ ] All users can log in
[ ] Create test sale order, confirm, ship, invoice
[ ] Verify email sending works
[ ] Check integrations are receiving/sending data
[ ] Monitor error logs for first 30 minutes

Plan de reversión:

Si se encuentran problemas críticos durante la transición:

1. Vuelva a cambiar el DNS al servidor anterior
2. Vuelva a habilitar el sistema antiguo para los usuarios.
3. Documente todos los problemas encontrados
4. Programe una ventana de migración de seguimiento

---

Preguntas frecuentes

¿Puedo pasar de Odoo 17 directamente a Odoo 19, o debo pasar por 18?

Usando el servicio de actualización oficial de Odoo, normalmente puedes pasar directamente de 17 a 19. Los scripts de migración de Odoo SA manejan saltos de múltiples versiones. Consulte siempre el repositorio de OpenUpgrade para conocer las versiones específicas que necesita.

¿Cuánto tiempo lleva una migración típica de Odoo?

La línea de tiempo depende en gran medida del nivel de personalización. La migración en sí (actualización de la base de datos) lleva horas; el momento está en pruebas, actualizaciones de módulos y validación.

¿Qué sucede con las personalizaciones de Studio durante la migración?

Las personalizaciones de Studio se almacenan como datos estándar de Odoo (vistas, campos, automatizaciones) y se migran a través del proceso de actualización de la base de datos estándar. Sin embargo, algunas personalizaciones de vistas pueden necesitar una revisión manual si Odoo 19 cambió la estructura del formulario subyacente. Pruebe siempre todas las personalizaciones de Studio después de la migración.

¿Necesito volver a ingresar los saldos iniciales después de la migración?

No, si migras la base de datos directamente. Todos los asientos de diario históricos y los saldos se transfieren con la base de datos. Si elige la ruta de "instalación nueva con importación de datos", deberá ingresar los saldos iniciales a partir de la fecha de corte, lo que requiere una coordinación cuidadosa con su equipo de contabilidad.

---

Próximos pasos

Las migraciones de Odoo son proyectos de alto riesgo que impactan directamente la continuidad del negocio. La diferencia entre una migración fluida y otra dolorosa se reduce a la preparación, la experiencia y una metodología de prueba rigurosa.

Nuestra metodología de migración cubre una evaluación completa, actualizaciones de módulos personalizados, pruebas paralelas y un plan de transición documentado con procedimientos de reversión.

Solicitar una evaluación de migración de Odoo a ECOSIRE →