Modernizar un ERP legacy: cuándo conviene migrar y cuándo no

Hay dos tipos de ERP legacy. Uno es el sistema viejo que va, factura, no da problemas y al que nadie quiere tocar. El otro es el viejo que sí da problemas, todos los conocen, y la duda es cuándo modernizarlo.

Lo que sigue no es para el primero. Si tu ERP es estable, cubre lo que necesitas y no tienes funcionalidades nuevas en cola, mantenlo. Hablamos del segundo: cuándo la deuda técnica empieza a costar más que arreglarla, qué señales objetivas mirar antes de decidir, y qué estrategias existen más allá del falso dilema de “tirar todo o aguantar”.

Las 7 señales de que tu ERP se ha quedado pequeño

Estas decisiones suelen arrancar con una intuición vaga: “esto va lento, hay cosas que no podemos hacer”. Antes de meter dinero en consultoría, conviene traducir esa intuición a algo medible. Las señales que se repiten en las auditorías que hacemos:

1. Hay un Excel paralelo para cada módulo del ERP. Si el sistema no genera el reporte que necesita la operativa o no permite la corrección que pide negocio, el equipo se va a Excel. Cada Excel paralelo es un agujero de datos sin sincronizar.

2. Cualquier modificación pasa por el proveedor original. Y el proveedor tarda semanas, cobra por hora o, peor, ya no existe. Lo que debería ser un cambio operativo se convierte en un proyecto.

3. Las integraciones modernas no son posibles. Facturación electrónica, bancos por API, fichaje digital, e-commerce. Si cada conexión nueva se resuelve con un volcado CSV nocturno, la deuda crece sola.

4. Los datos se leen, ya no se escriben. El ERP guarda el histórico, pero las decisiones del día a día se toman fuera. Señal clara de que el sistema dejó de ser el sistema de récord.

5. Onboarding eterno. Aprender un ERP propietario sin documentación moderna toma meses. Cuando alguien nuevo tarda en ser productivo lo que debería costar semanas, hay un coste de oportunidad real.

6. Solo una persona sabe cómo funciona por dentro. Y normalmente está a tres años de la jubilación. El bus factor es 1.

7. Negocio pide funcionalidades y “no se pueden hacer”. El sistema decide qué es viable. Cuando la limitación técnica dicta la estrategia comercial, el ERP dirige a la empresa en lugar de servirla.

Si te encuentras con tres o más, la modernización ya no es opción: es una urgencia silenciosa. Silenciosa porque el sistema sigue funcionando. El coste se acumula en la curva de ineficiencia, no en un fallo visible.

Las 4 estrategias reales de modernización

El falso dilema más repetido es “lo tiramos todo o aguantamos”. Hay cuatro opciones reales, y cada una tiene su escenario donde gana.

Estrategia 1: Rewrite total (big bang)

Reescribir el sistema entero en paralelo y hacer cutover en una fecha concreta.

Gana cuando: el sistema es pequeño (menos de 5 módulos, menos de 20 usuarios), el modelo de datos está documentado, el dominio de negocio es estable, o hay una fecha regulatoria que obliga (un nuevo RD, facturación electrónica con formato impuesto, etc.).

Pierde cuando: el sistema es grande y arrastra años de reglas no documentadas. El rewrite las “redescubre” a base de bugs en producción. También pierde si la empresa no puede permitirse de 6 a 18 meses sin funcionalidades nuevas.

Estrategia 2: Strangler Fig

Patrón de Martin Fowler. Se envuelve el sistema antiguo con una capa moderna (API gateway, fachada web) y se migran módulos de uno en uno. El sistema viejo muere despacio; el nuevo va asumiendo responsabilidades.

Gana cuando: la PYME tiene un sistema mediano (5-10 módulos), quiere validar arquitectura nueva sin comprometerse del todo, o tiene un equipo pequeño que no puede mantener dos sistemas en paralelo total.

Pierde cuando: el modelo de datos es tan centralizado que no se puede trocear por módulos. O cuando negocio exige todo migrado ya, sin convivencia.

Estrategia 3: Side-by-Side

Antiguo y nuevo conviven con sincronización bidireccional. Los usuarios usan el que les conviene. El viejo se apaga cuando todo el flujo crítico ha pasado al nuevo.

Gana cuando: la migración tiene riesgo cero permitido de pérdida de datos, el sistema es crítico y un fallo no puede parar la operativa, o el cliente quiere validar al proveedor nuevo en producción antes de comprometerse.

Pierde cuando: te puede salir caro. Estás manteniendo dos sistemas durante meses o años, y el equipo se duplica. La sincronización bidireccional añade complejidad: cualquier inconsistencia se replica al otro lado.

Estrategia 4: Extender, no migrar

A veces la respuesta correcta es no migrar. El ERP antiguo funciona, lo que le falta es apertura. Se construye encima, sin tocar el core: API REST sobre el modelo de datos legacy, web y móvil consumiendo esa API, integraciones modernas que el sistema antiguo nunca iba a tener nativamente.

Gana cuando: el ERP cubre el 80% de lo que necesitas y solo falta la capa moderna (web, móvil, integraciones), el coste de migrar excede claramente el ROI, o el proveedor sigue dando soporte al sistema base.

Pierde cuando: el sistema antiguo es una caja negra sin acceso al modelo de datos. O cuando la tecnología es tan vieja que no hay forma estable de meterle una API encima.

En la práctica, la mayoría de PYMES que se modernizan bien van por la estrategia 2 (strangler) o la 4 (extender). El rewrite total tiene su sitio, pero es minoritario.

Cómo decidir: la matriz del coste mensual

La decisión rara vez es técnica; es financiera. Y la pregunta correcta no es “¿cuánto cuesta modernizar?”, sino esta otra: “¿cuánto me está costando al mes no hacerlo?”.

Coste mensual de no modernizar (estimación honesta, sin maquillaje):

• Horas perdidas en Excel paralelos × salario medio del equipo
• Horas del equipo IT en parches manuales
• Errores de transcripción que detectas (los que no detectas son peores)
• Funcionalidades de negocio que no se pueden lanzar (lucro cesante)
• Riesgo de bus factor: probabilidad × impacto si la persona clave desaparece
• Trabajo manual por falta de integraciones: envíos, conciliaciones, validaciones cruzadas

Coste mensual de modernizar (amortizado a 5 años):

• Inversión total ÷ 60 meses
• Mantenimiento del sistema nuevo
• Curva de aprendizaje del equipo

Si el primero supera al segundo, la decisión es aritmética. Si está cerca, hay que ponderar riesgo regulatorio, fuga de talento y momento estratégico. Variables que no van en una hoja de cálculo pero que pesan igual.

El factor que casi nadie evalúa: el estado de los datos

En las auditorías que hacemos antes de empezar una modernización, lo que más subestima el cliente no es la complejidad técnica del sistema nuevo. Es el estado de los datos del antiguo. Y eso es lo que suele triplicar plazos.

Preguntas que hay que responder antes de tocar código:

• ¿Hay duplicados en clientes, proveedores o productos?
• ¿Los códigos de cuenta contable están alineados con la realidad fiscal de hoy, o con la de hace ocho años?
• ¿Cuántos años de histórico hay que migrar de verdad y cuántos pueden quedar en modo consulta?
• ¿Existen catálogos huérfanos, registros sin referencia cruzada, NIFs mal formados?
• ¿La operativa usa campos libres como si fueran estructurados? (Spoiler: sí, casi siempre.)

Cada punto es un mini-proyecto. Una modernización seria arranca con una auditoría de datos de 2-3 semanas antes de tocar nada.

¿Y el compliance durante la migración?

Si el sistema antiguo cubre obligaciones regulatorias (registro horario por el RD-Ley 8/2019, facturación electrónica, RGPD, conservación fiscal de 4 años, etc.), la modernización no puede romper ese cumplimiento durante la transición. Side-by-side y strangler facilitan que ambos sistemas sigan generando registros legalmente válidos. Un big bang mal planificado deja a la empresa con períodos no documentados, expuesta a sanciones.

Cuando hay obligación de fichaje o retención de datos durante la migración, lo que recomendamos:

1. Mantén el sistema viejo como sistema de récord legal hasta que el nuevo esté validado.
2. Genera los registros en ambos durante el solapamiento. Es trabajo extra, sí; lo es menos que defender ante Inspección que faltan tres meses.
3. Apaga el antiguo solo cuando hayas superado la fase crítica (3 a 6 meses) sin incidencias en el nuevo.

Build vs Buy: ¿a medida o SaaS?

La pregunta paralela es legítima: ya que vamos a gastar, ¿por qué no compramos un SaaS estándar y nos olvidamos? Lo desarrollamos a fondo en Software a medida vs SaaS: cuándo elegir cada uno. El resumen: si tu ERP heredado existe precisamente porque tus procesos no encajan en un SaaS estándar, la respuesta sigue siendo a medida. Si los procesos se han estandarizado con los años y un SaaS sectorial cubre el 90%, ahí sí cambia la decisión.

Cómo trabajamos nosotros una modernización

Los pasos que aplicamos cuando un cliente nos pide modernizar un ERP heredado:

1. Auditoría inicial (2-3 semanas). Revisión de código, modelo de datos, integraciones, calidad de datos, procesos críticos. Termina con un informe que define alcance real, no el aspiracional.
2. Decisión de estrategia. Recomendamos rewrite, strangler, side-by-side o extender, con justificación documentada y sin amor propio por una opción.
3. POC del módulo más crítico (4-6 semanas). Antes de comprometerse al proyecto completo, validamos la viabilidad con el módulo que más duele si falla. Si la prueba no convence, se para.
4. Roadmap iterativo. Entregas cada 2-3 semanas con revisión conjunta. Nada de “vuelvo a los 6 meses con esto terminado”.
5. Migración por fases. Los usuarios pasan a producción con cada módulo en cuanto está listo. No big bang.
6. Apagado controlado del legacy. Solo cuando el flujo crítico lleva al menos un trimestre en producción sin incidencias.

Si tienes un ERP que sospechas ha llegado al límite, hablamos. Una llamada de 30 minutos suele bastar para distinguir si lo que necesitas es modernización seria o solo una capa de integraciones encima.

Recursos

• Patrón Strangler Fig (Martin Fowler, original)
• Control horario obligatorio RD-Ley 8/2019: qué tener en cuenta si modernizas un sistema que registra jornada.
• Software a medida vs SaaS: cuándo cada uno: la decisión paralela que conviene tomar antes de empezar.
• Servicios de VisibleSoft: qué tipo de proyectos de modernización abordamos.
• Reserva un diagnóstico gratuito