El primer impulso del consultor es cambiar el software. Es cómodo, es vendible y da la sensación de que se está haciendo algo grande. El cliente lo compra porque el problema es visible: «nuestro programa se queda corto». La conclusión aparente es que hay que cambiarlo. Casi siempre, no lo es.
En los últimos años, la mayoría de proyectos que hemos rescatado empezaron con una migración recomendada por otro proveedor. Empresas que se movieron de un ERP asentado a uno moderno, de un software de facturación a otro, de una hoja de cálculo a una plataforma con licencia mensual. En dos de cada tres casos, la operativa siguió rompiéndose exactamente por los mismos sitios. La herramienta era nueva. El problema no.
Qué cuesta migrar de verdad
La factura de la nueva licencia es la parte visible del coste, y no siempre la mayor. Cuando desglosas una migración real, aparecen tres capas de coste que rara vez se presupuestan:
- El coste de aprendizaje. Todo el equipo tiene que reajustar rutinas. Los meses siguientes a la migración, la productividad cae entre un 15 % y un 30 %. Vuelve a subir cuando todos se han acostumbrado. Ese pico negativo raramente aparece en el business case.
- El coste de la información perdida. Ninguna migración es limpia. Siempre hay campos que no encajan, históricos que se truncan, relaciones que se rompen. El equipo dedica meses a recuperar información a mano.
- El coste de la personalización previa. La herramienta anterior estaba adaptada a diez años de decisiones concretas. Reproducir esas adaptaciones en la nueva es un proyecto por sí mismo, y suele descubrirse tarde.
Sumando estas tres capas, una migración razonable de un ERP en una empresa de treinta personas suele estar en la horquilla de 40.000 a 120.000 euros de coste real, sin contar la licencia. Y ese coste solo se justifica si el ERP nuevo hace algo que el anterior no puede hacer de ninguna forma.
Casi nunca es el caso
En la mayoría de las empresas medianas, el software que ya usan no está mal. Está infrautilizado. El ERP tiene un módulo de facturación recurrente que nadie activó porque nadie se leyó la documentación. El CRM permite exportaciones automáticas que nadie configuró. La pasarela de cobro tiene webhooks que nadie conectó. El excel del viernes no es culpa del software: es culpa de que nadie ha construido el puente entre el software y el excel.
La primera pregunta que hacemos, antes de considerar cambiar nada, es muy sencilla: ¿qué funciones del programa actual no se están usando, y por qué? La respuesta más habitual es «no lo sabíamos» o «nadie ha tenido tiempo». Rara vez la respuesta es «lo intentamos y no funcionó».
Cuándo migrar sí tiene sentido
No siempre estamos en contra. Hay tres escenarios en los que recomendamos migrar sin dudarlo:
- El fabricante ha anunciado el fin de soporte. No es discutible. Un sistema sin actualizaciones de seguridad es una bomba con temporizador. La migración se planifica con tiempo, no se improvisa el trimestre en que caduca.
- El modelo de negocio ha cambiado y la herramienta no lo contempla. Un ejemplo típico: una empresa de servicios pasa a vender también suscripciones, y su ERP no gestiona rentas recurrentes de forma nativa. Antes de migrar, comprobamos si hay módulo o integración; si no lo hay, migrar es lo correcto.
- El coste de mantenimiento del actual supera al de migrar.Esto pasa con sistemas muy antiguos que exigen infraestructura propia, licencias caras y personal especializado. Los números hablan solos y suelen decir que migrar sale más barato en tres años.
Fuera de estos tres escenarios, la respuesta por defecto debería ser no migrar. Y no porque el software nuevo sea peor, sino porque el coste de cambio rara vez se recupera con la mejora funcional.
La alternativa: conectar lo que ya se paga
Casi ninguna empresa tiene un problema de software. Tiene varias herramientas correctas, ninguna que mande sobre las demás, y personas haciendo de puente entre ellas.
La alternativa a migrar es integrar. Coger las herramientas que la empresa ya paga y hacer que se hablen entre sí. En términos técnicos: levantar un flujo intermedio, sea con n8n, con Make, con una función propia o con lo que corresponda, que consuma los datos de un sistema y los deposite en otro sin pasar por una persona. En términos económicos: convertir un coste de 60.000 euros en migración en un coste de 8.000 en integración.
La diferencia no es solo el precio. Es la cantidad de cosas que no se rompen: no se reeduca al equipo, no se pierde historial, no se renegocian personalizaciones. La operativa sigue exactamente igual, salvo por el detalle de que ha dejado de existir el puente humano entre programas.
Cómo lo enfocamos en cada proyecto
Antes de proponer nada, dedicamos dos semanas a mapear el ecosistema actual. Qué herramientas hay, qué dato vive en cada una, quién mueve cada dato de una a otra. Es un ejercicio aburrido pero imprescindible. En el 80 % de los casos, el mapa deja clarísimo que no hay que cambiar de programa: hay que conectar tres puntos concretos. En el 20 % restante, aparece un problema estructural que sí justifica migrar. En ese momento la conversación es honesta y con datos, no con impulso.
Esta forma de trabajar cuesta menos, tarda menos, y sobre todo respeta lo que la empresa ha construido en años. Es la única razón por la que trabajamos así.