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

La actualización a Odoo 19 Enterprise ofrece mejoras significativas en el rendimiento, la experiencia del usuario y las funciones asistidas por IA. Pero 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 migración a Odoo 19 requiere actualizar una versión principal a la vez (17→18→19 o 17→19 directamente con OpenUpgrade)
• 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.
• Planifique un cronograma total de migración de 3 a 8 semanas, según la complejidad
• 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: (minimum 15 required for Odoo 19)

Paso 2: Clasificar módulos personalizados

Para cada módulo personalizado, determine:

Paso 3: Identificar los cambios importantes de Odoo 19

Cambios clave entre Odoo 17/18 y Odoo 19 que afectan los módulos personalizados:

• OWL 3.x: Los componentes frontend deben migrarse desde los patrones OWL 2.x
• Python 3.12: Es posible que sea necesario ajustar alguna sintaxis de Python 3.10/3.11.
• PostgreSQL 15+: versión mínima requerida; algunos patrones de consulta cambian
• Desuso de API: se eliminaron varios métodos _legacy; verifique _multi → _create_multi
• Motor de informes: se cambió el nombre de algunas variables de informes de QWeb
• Refactorización de movimiento de cuenta: account.move cambios en la estructura de líneas afectan las personalizaciones contables

---

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:

• No maneja módulos personalizados
• 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 y Enterprise.

# Clone OpenUpgrade for Odoo 19
git clone https://github.com/OCA/OpenUpgrade.git -b 19.0

# Install upgrade dependencies
pip install openupgradelib

# Run migration
python odoo-bin --config=upgrade.conf \
    --update=all \
    --load=base,web,openupgrade_framework

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 (semanas 1-2)

Preparación de base de datos:

-- Run on source database before export
-- Identify orphaned records
SELECT id, name FROM res_partner WHERE active = FALSE AND id NOT IN (
    SELECT partner_id FROM sale_order
    UNION SELECT partner_id FROM account_move
    UNION SELECT partner_id FROM stock_picking
);

-- Archive old draft records (reduces migration time)
UPDATE sale_order SET active = FALSE
WHERE state = 'draft' AND date_order < NOW() - INTERVAL '2 years';

-- Verify accounting reconciliation
SELECT COUNT(*) FROM account_move_line
WHERE reconciled = FALSE AND debit != credit;

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 -p 5433 -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

Revisión de código de módulo personalizado:

Para cada módulo personalizado, ejecute una verificación de compatibilidad:

# Check for deprecated patterns
grep -r "execute_kw" custom_modules/   # Still valid in v19
grep -r "browse\(\[" custom_modules/  # Should be browse(ids) not browse([ids])
grep -r "_multi" custom_modules/      # Check for renamed methods
grep -r "account\.move\.line\." custom_modules/  # Account refactoring affected
grep -r "@api\.one" custom_modules/   # Removed in v14, ensure not present
grep -r "@api\.multi" custom_modules/ # Removed in v14, ensure not present

---

Configuración del entorno de migración (semana 2-3)

Configuración de infraestructura:

# Install Odoo 19 Enterprise on migration server
# Requirements: Ubuntu 22.04/24.04, PostgreSQL 15+, Python 3.12

# 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

Restaurar la base de datos de origen en el servidor de migración:

# Create target database
createdb -h localhost -U postgres odoo_migration_test

# Restore backup
pg_restore -h localhost -U postgres -d odoo_migration_test \
    odoo_prod_backup_YYYYMMDD.dump

# Run Odoo upgrade
python3 /opt/odoo19/odoo-bin \
    -d odoo_migration_test \
    -u all \
    --without-demo=all \
    --stop-after-init

---

Migración de módulo personalizado (semanas 3 a 5)

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 compatibilidad con Python:

# Old pattern (deprecated):
@api.multi
def my_method(self):
    for record in self:
        pass

# New pattern:
def my_method(self):
    for record in self:
        pass

3. 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"/>

4. Actualice los componentes de OWL (si hay widgets de interfaz):

OWL 3.x introduce cambios de reactividad. Si sus módulos utilizan widgets de JavaScript personalizados:

// Old OWL 2.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    willStart() { ... }
}

// New OWL 3.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    setup() {
        onWillStart(async () => { ... });
    }
}

5. 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 (semanas 5 a 6)

Validación de datos financieros:

-- Verify balance sheet balances (assets = liabilities + equity)
SELECT
    SUM(CASE WHEN account_type LIKE 'asset%' THEN balance ELSE 0 END) as assets,
    SUM(CASE WHEN account_type LIKE 'liability%' THEN balance ELSE 0 END) as liabilities,
    SUM(CASE WHEN account_type = 'equity' THEN balance ELSE 0 END) as equity
FROM account_account aa
JOIN account_move_line aml ON aml.account_id = aa.id
JOIN account_move am ON aml.move_id = am.id
WHERE am.state = 'posted';

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 (semana 7-8)

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 (< 5 minutos)
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. Con OpenUpgrade, es posible que deba ir 17→18→19 dependiendo de los scripts de migración disponibles. 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. Una instancia estándar de Odoo con personalizaciones mínimas: 2-3 semanas. Moderadamente personalizado (5-10 módulos personalizados): 4-6 semanas. Altamente personalizado con integraciones complejas: 8-16 semanas. 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.

¿Mi licencia de Odoo Enterprise se transferirá a la versión 19?

Sí. Las suscripciones a Odoo Enterprise son independientes de la versión. Su suscripción anual cubre cualquier versión que ejecute. Comuníquese con su socio de Odoo para obtener el código empresarial de Odoo 19 si no accede a él a través del repositorio Git de Odoo con sus credenciales empresariales.

---

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.

ECOSIRE ha migrado con éxito docenas de instancias de Odoo desde las versiones 13, 14, 15, 16, 17 y 18 a Odoo 19 Enterprise. 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 →

Evaluaremos su entorno actual, identificaremos todos los riesgos de migración y le proporcionaremos un plan de migración de alcance fijo para que sepa exactamente qué esperar antes de que se ejecute el primer script de migración.