Cómo migrar un ERP on-premise a la nube: estrategia, herramientas e IA

Cambiar de ERP no es un proyecto de informática: es un proyecto de negocio que se ejecuta con medios informáticos. Por eso las migraciones que salen mal casi nunca fallan por la tecnología. Fallan porque nadie decidió a tiempo qué procesos se conservaban tal cual, quién validaba los datos maestros y qué ocurría el lunes siguiente al cutover cuando el almacén tiene que servir pedidos con un sistema que aprendió la semana pasada.

La buena noticia es que en 2026 el terreno está mucho más despejado que hace cinco años. Los ERP cloud han madurado, las APIs REST son la norma y no la excepción, y la IA se ha comido la parte más tediosa y más arriesgada del proyecto: el inventario del sistema antiguo, la escritura de los scripts de transformación y la validación registro a registro. La mala noticia es que el calendario ya no lo marcas tú: entre 2026 y 2030 caducan los soportes de buena parte de los ERP que siguen corriendo en servidores locales, y cuando un fabricante retira el soporte lo que se acaba no son las funcionalidades, sino los parches de seguridad.

Esta guía recorre el proceso completo: qué opciones reales hay, qué fechas te obligan a moverte, cómo se estructura la migración en seis fases, dónde entra la IA, cuánto cuesta de verdad y qué errores repiten las empresas que acaban con un proyecto de doce semanas convertido en uno de nueve meses.

El dilema del ERP on-premise en 2026

Muchas empresas medianas siguen ejecutando su ERP en servidores locales: instalaciones de SAP Business One, Microsoft Dynamics NAV, o soluciones propias desarrolladas hace años. El problema no es solo el coste de mantener hardware y licencias — es la limitación operativa. Sin acceso remoto fiable, sin integraciones modernas, sin escalabilidad y con actualizaciones que son proyectos en sí mismas.

La migración a la nube no es un capricho tecnológico: es una necesidad competitiva. Y con las herramientas de IA actuales, el proceso es más asequible y menos arriesgado que nunca.

Opciones de ERP en la nube

Odoo se ha convertido en la referencia open source para ERP cloud. Modular, con cientos de aplicaciones oficiales incluidas en el mismo precio por usuario y miles de módulos adicionales de la comunidad. En Keliam lo recomendamos para empresas que quieren control sobre su ERP sin los costes de licencia de soluciones enterprise.

ERPNext es otra alternativa open source con fuerte presencia en manufactura y distribución. Basado en Python/Frappe, muy extensible.

SAP S/4HANA Cloud para empresas que ya están en el ecosistema SAP y necesitan migrar de versiones on-premise a la nube.

Microsoft Dynamics 365 para entornos Microsoft que ya usan Azure y Microsoft 365.

Calendario de fin de soporte: las fechas que ya no negocias

Antes de discutir plataformas conviene mirar el calendario, porque en muchos casos la decisión de cuándo ya está tomada por el fabricante. Estas son las fechas que afectan a la mayoría de ERP on-premise que seguimos encontrando en empresas medianas españolas.

SAP. El mantenimiento estándar de SAP ERP con los Enhancement Packages 6, 7 y 8 llega hasta el 31 de diciembre de 2027. A partir de ahí hay mantenimiento extendido de pago hasta el 31 de diciembre de 2030, con un recargo sobre la cuota de mantenimiento. Hay además un hito intermedio que se cuela en muchas hojas de ruta: el periodo de transición de los Compatibility Packs para clientes de S/4HANA on-premise vencía originalmente el 31 de diciembre de 2025 y SAP lo movió al 31 de mayo de 2026. Si tu proyecto dependía de ese margen, ya no existe.

Microsoft Dynamics. La familia NAV se apaga por versiones: NAV 2016 terminó soporte el 14 de abril de 2026, NAV 2017 lo hace el 11 de enero de 2027 y NAV 2018 el 11 de enero de 2028. Dynamics GP tiene fecha de cierre anunciada para el 31 de diciembre de 2029. En la práctica esto significa que cualquier instalación de Navision viva hoy tiene un horizonte de dos años largos como máximo antes de quedarse sin parches.

Odoo. Aquí el modelo es distinto: cada versión mayor tiene tres años de soporte estándar y solo conviven tres versiones vivas a la vez. Odoo 20 se presenta el 24 de septiembre de 2026 en la keynote de apertura del Odoo Experience de Bruselas, que se celebra del 24 al 26 de septiembre. Con esa salida, Odoo 19 queda soportado hasta septiembre de 2028, Odoo 18 hasta septiembre de 2027 y Odoo 17 cierra su ventana estándar justo ahora, en septiembre de 2026. Migrar a Odoo implica aceptar un ciclo de actualización regular: no es un sistema que instalas y olvidas durante una década.

La conclusión práctica de este calendario es sencilla. Un proyecto de migración de ERP bien hecho ocupa entre tres y nueve meses según el tamaño, y hay que sumarle el periodo de marcha en paralelo. Si tu fecha límite es diciembre de 2027, el momento de empezar el assessment no es 2027: es ahora.

Qué cuesta cada opción y cómo elegir

La comparativa de licencias suele ser lo primero que pide dirección y lo que peor se explica. Los precios de lista públicos de Odoo a día de hoy son 24,90 $ por usuario y mes en el plan Standard con facturación anual (31,10 $ sin descuento) y 49,00 $ por usuario y mes en el plan Custom (61,00 $ sin descuento), con todas las aplicaciones incluidas en ambos casos. El plan Custom es el que añade multiempresa, Odoo Studio y acceso a la API externa, y es el único que permite desplegar en Odoo.sh o en tu propia infraestructura; también existe un plan gratuito limitado a una sola aplicación. Conviene tomar estas cifras como lo que son: precio de licencia, no coste del proyecto.

Esa distinción es la que se suele perder. En una implantación típica de pyme, la licencia rara vez pasa del 15-25% del coste del primer año. El resto es análisis, configuración, desarrollo de lo que no viene de serie, migración de datos, integraciones y formación. Lo desglosamos con números concretos en la guía de Odoo para pymes: módulos, coste e implantación.

Para elegir plataforma, tres criterios ordenan casi cualquier decisión:

1. Dónde está la complejidad de tu negocio. Si está en producción y trazabilidad, mira ERPNext y Odoo con módulo de manufactura. Si está en contabilidad multipaís y consolidación, el ecosistema SAP o Dynamics 365 te ahorrará desarrollo. Si está en comercial y postventa, quizá lo que necesitas no es un ERP nuevo sino ordenar el CRM primero: la comparativa de SuiteCRM, Odoo y Pipedrive ayuda a separar ambas decisiones.

2. Cuánto vas a personalizar. Cada desarrollo a medida es deuda que pagas en cada actualización. En sistemas con ciclo anual como Odoo, un módulo propio mal planteado convierte cada salto de versión en un miniproyecto. La regla que aplicamos: personaliza solo lo que te diferencia de tu competencia; para todo lo demás, adapta el proceso al estándar.

3. Qué exigen tus clientes en materia de seguridad. Si vendes a la administración pública o a grandes cuentas, el ERP entra dentro del alcance de las auditorías. Conviene saber de antemano qué te van a pedir: nuestra guía de certificación ISO 27001 y la del Esquema Nacional de Seguridad explican qué controles acaban afectando a la elección de proveedor cloud y a la ubicación de los datos.

Fases de la migración de ERP

Fase 1 – Assessment: Antes de migrar, hay que entender qué procesos de negocio cubre el ERP actual, qué personalizaciones se han hecho, qué integraciones existen y qué datos necesitan migrarse. Con Claude analizamos la documentación existente y generamos un mapa completo del sistema actual.

Fase 2 – Rediseño de procesos: La migración es la oportunidad de repensar procesos. No tiene sentido replicar en la nube los mismos flujos ineficientes que tienes on-premise. La IA ayuda a detectar cuellos de botella y proponer optimizaciones basadas en mejores prácticas del sector.

Fase 3 – Configuración del ERP destino: Configurar módulos, flujos de aprobación, roles, permisos, informes. En Odoo, por ejemplo, esto incluye configurar contabilidad, inventario, compras, ventas, manufactura y HR según las necesidades específicas.

Fase 4 – Migración de datos: La parte más técnica. Maestros (clientes, proveedores, productos, plan contable) y transaccionales (facturas, pedidos, movimientos de stock). Scripts ETL asistidos por Claude Code para transformar y validar datos.

Fase 5 – Integraciones: Conectar el nuevo ERP con el resto del ecosistema: CRM, e-commerce, pasarelas de pago, logística, contabilidad externa. APIs REST modernas facilitan lo que antes requería middleware costoso.

Fase 6 – Formación y go-live: Sesiones de formación por perfil de usuario, período de marcha en paralelo (ERP viejo y nuevo funcionando simultáneamente) y cutover final.

Cómo la IA reduce el riesgo de migración

Análisis de datos pre-migración: La IA detecta inconsistencias, duplicados y datos corruptos antes de migrar. Migrar datos limpios es la diferencia entre un go-live suave y semanas de incidencias.

Generación de scripts de migración: En lugar de escribir cada transformación manualmente, describimos la regla de negocio y la IA genera el script. «Si el código de producto empieza por OLD_, mapearlo al nuevo formato NEW-XXXX preservando los últimos 4 dígitos.»

Validación automatizada: Agentes IA que comparan registros entre origen y destino, verificando que los saldos cuadran, que las relaciones se mantienen y que no se ha perdido información.

Documentación automática: Cada decisión de mapeo, cada transformación, cada excepción queda documentada automáticamente. La documentación funcional generada con IA asegura trazabilidad completa.

Caso: de ERP propietario a Odoo Cloud

Un cliente del sector distribución llevaba 12 años con un ERP desarrollado internamente en .NET/SQL Server. 3 almacenes, 200 usuarios, 150.000 referencias. El sistema no tenía API, el proveedor original ya no existía y el mantenimiento lo hacía un solo freelance.

La migración a Odoo Enterprise Cloud se completó en 12 semanas. Los scripts de migración generados con IA procesaron 2 millones de registros con una tasa de error del 0.02% (corregido en validación). El cliente ahora opera desde cualquier lugar, con app móvil para almacén y con integraciones directas con su SuiteCRM y su tienda WooCommerce.

Cuánto cuesta realmente migrar un ERP

Un presupuesto de migración de ERP que solo contempla licencias y horas de consultoría está incompleto. Estas son las partidas que aparecen sí o sí, aunque no siempre en la oferta inicial.

Limpieza de datos. Es la partida más subestimada y la que más varía. Un maestro de artículos de 150.000 referencias acumuladas durante doce años contiene duplicados, referencias obsoletas que nadie se atreve a borrar y campos usados para cosas distintas a las que decía su nombre. Aquí la IA cambia el orden de magnitud: lo que era un trabajo manual de semanas pasa a ser una revisión asistida de días, pero alguien de negocio sigue teniendo que decidir qué se conserva.

Integraciones. Cada sistema conectado al ERP viejo hay que reconectarlo: tienda online, CRM, transportistas, bancos, gestoría. Si ya trabajas con APIs REST el coste es asumible; si el sistema antiguo se integraba por ficheros planos depositados en una carpeta compartida a las tres de la mañana, el rehacer completo es inevitable. Explicamos los patrones habituales en el artículo sobre integraciones API entre ecommerce, ERP, logística y pasarelas de pago, y para orquestar flujos entre sistemas sin escribir middleware desde cero, en cómo sincronizar CRM y ERP con n8n.

Marcha en paralelo. Durante unas semanas el equipo introduce la información dos veces, en el sistema viejo y en el nuevo. Es tiempo de tus empleados, no de tu proveedor, y por eso casi nunca aparece en el presupuesto; pero es real y hay que planificarlo con el calendario de negocio en la mano. Nadie hace un cutover en plena campaña de Navidad.

Formación y caída de productividad. Los dos primeros meses tras el go-live la organización rinde por debajo de su nivel habitual. Es normal y es temporal, pero si nadie lo ha anticipado se interpreta como que la migración ha salido mal y se toman decisiones apresuradas.

Informes. El ERP nuevo trae informes estándar que no son los que tenía tu director financiero en una hoja de cálculo conectada por ODBC al sistema anterior. Reconstruir el cuadro de mando es un proyecto propio y conviene abordarlo después del go-live, no durante: en Business Intelligence para pymes detallamos cómo hacerlo sin disparar el presupuesto.

Cinco errores que descarrilan una migración de ERP

1. Migrar el histórico completo «por si acaso». Es la decisión que más alarga un proyecto. Doce años de asientos contables en el sistema nuevo multiplican el volumen a transformar, a validar y a corregir. En la mayoría de casos basta con migrar saldos de apertura, maestros y un par de ejercicios cerrados, y dejar el sistema antiguo en modo consulta para el resto. Es más barato mantener una máquina virtual apagada que se enciende dos veces al año que migrar una década de movimientos.

2. No nombrar un responsable funcional con capacidad de decidir. Si cada duda de mapeo tiene que subir a un comité que se reúne cada quince días, el proyecto se detiene. Hace falta una persona de negocio, con autoridad, disponible durante el proyecto. No es un rol a tiempo parcial disfrazado.

3. Replicar los procesos ineficientes del sistema antiguo. Ya está dicho en la fase 2, pero merece repetirse porque es el error más caro a medio plazo: cada excepción que arrastras se convierte en un desarrollo a medida, y cada desarrollo a medida en un obstáculo en la próxima actualización.

4. Tratar la seguridad como un tema posterior. El ERP en la nube concentra datos de clientes, proveedores, nóminas y facturación en un sistema accesible desde internet. Los controles de acceso, la política de copias, el cifrado y la segmentación se diseñan durante la migración, no después: las medidas de protección de comunicaciones, aplicaciones e información del ENS son una buena lista de comprobación aunque no tengas obligación de certificarte.

5. Dar por terminado el proyecto el día del go-live. El go-live es el principio de la fase en la que aparecen los casos que nadie probó. Hay que presupuestar soporte reforzado durante las primeras semanas y una revisión a los tres meses. Un contrato de mantenimiento de software con horas de evolución reservadas evita que las mejoras obvias se queden esperando un presupuesto nuevo.

Preguntas frecuentes sobre migrar el ERP a la nube

¿Cuánto dura una migración de ERP? Entre 3 y 6 meses en una pyme con procesos estándar, y entre 9 y 18 meses en empresas con varias sociedades, producción compleja o muchas integraciones. El caso que contamos más arriba se cerró en 12 semanas, pero partía de un alcance acotado y de una dirección que tomó decisiones rápido.

¿Se puede migrar por fases en lugar de todo de golpe? Sí, y en empresas grandes suele ser lo razonable: primero finanzas y compras, después almacén y producción, al final los módulos comerciales. El precio de hacerlo por fases es convivir con dos sistemas e integrarlos temporalmente, lo que añade trabajo. Por debajo de cierto tamaño, el big bang con marcha en paralelo sale más barato.

¿Qué pasa con los desarrollos a medida del ERP antiguo? Se revisan uno a uno. La experiencia dice que una parte considerable resuelve problemas que el ERP nuevo ya cubre de serie, otra parte responde a necesidades que dejaron de existir, y solo un tercio suele merecer reimplementación. Un inventario honesto de personalizaciones en la fase de assessment ahorra muchas horas después.

¿Es seguro tener el ERP en la nube? Normalmente más que tenerlo en un servidor bajo una mesa con copias a un disco USB. Lo que cambia es el reparto de responsabilidades: el proveedor cloud responde de la infraestructura, pero la gestión de usuarios, permisos, contraseñas y accesos de terceros sigue siendo tuya, y ahí es donde ocurren la mayoría de incidentes.

¿Y si mi ERP actual todavía tiene soporte? Entonces tienes la ventaja de poder planificar en lugar de reaccionar. Aprovecha para hacer el assessment con calma, limpiar los datos maestros y documentar los procesos: es trabajo que se aprovecha íntegro cuando llegue el momento, y de paso mejora el sistema que ya tienes. Una auditoría técnica previa suele ser la forma más barata de saber en qué punto estás.

Conclusión

Migrar el ERP a la nube dejó de ser una decisión técnica discutible para convertirse en una cuestión de calendario: entre 2026 y 2030 caducan los soportes de la mayoría de sistemas on-premise instalados en empresas medianas, y quedarse sin parches de seguridad en el sistema que contiene tu facturación no es una opción defendible ante un cliente, un auditor o una aseguradora.

La parte buena es que el proyecto es hoy más predecible que nunca. Las seis fases están bien establecidas, las plataformas cloud han madurado y la IA ha absorbido el trabajo que más errores generaba: el inventario del sistema antiguo, los scripts de transformación y la validación registro a registro. Lo que sigue siendo humano, y lo que decide si el proyecto sale bien, es lo de siempre: decidir qué procesos merecen conservarse, quién valida los datos y quién responde cuando hay que elegir entre dos opciones imperfectas.

Si estás valorando el salto, el primer paso no es pedir presupuestos de licencias: es hacer el assessment y saber exactamente qué tienes. Con ese mapa encima de la mesa, las tres ofertas que recibas serán comparables entre sí y tu proyecto tendrá un alcance que no se mueve cada semana.