Migrar un sistema heredado (un Access antiguo, un PHP construido por un freelance que ya no está, una base de datos que solo entiende una persona) es uno de los proyectos más caros y delicados que afronta una PYME. La razón es simple: no es construir algo desde cero, es construir algo nuevo manteniendo la información, los procesos y las costumbres del anterior. Y el anterior casi nunca está documentado.
La mayoría de empresas que hemos visto fallan no por elegir mal a la agencia, sino por arrancar el proceso desde el lugar equivocado. Estos son los seis errores más frecuentes y, después, la secuencia que sí funciona.
Error 1: pedir presupuesto antes de saber qué se quiere mantener
Es la primera tentación. Llevas meses pensando que el sistema heredado tiene que sustituirse. Llamas a tres agencias y les dices "queremos sustituir esto, pasadnos presupuesto". Las agencias preguntan qué quieres conservar y descubres que no lo sabes. Algunas funcionalidades del sistema actual son críticas, otras son ruido histórico, otras se usan una vez al año. Sin esa distinción hecha por adentro, cada agencia presupone una cosa distinta.
Los presupuestos divergen no porque las agencias sean diferentes, sino porque están cotizando distintos sistemas. Una asume migración completa, otra asume migración parcial, la tercera asume reescritura desde cero conservando solo los datos. Tres proyectos distintos con el mismo nombre.
Error 2: dar por hecho que la documentación existe
Antes de hablar con una agencia, casi todo el mundo asume que la documentación del sistema actual está en algún sitio. Manuales, esquema de la base de datos, listado de funcionalidades, casos especiales. Cuando se busca, casi nunca aparece. La mayoría de sistemas heredados de PYMEs se construyeron rápido, se ampliaron a parches y la documentación, si existió, quedó desactualizada hace años.
Esto se descubre demasiado tarde. La empresa pasa el "manual" del sistema antiguo a la agencia y la agencia, basándose en él, presupuesta. Después, cuando empiezan a construir, descubren que el manual omite la mitad de las particularidades del sistema real. La agencia entonces o factura "extras" o entrega algo que no replica el comportamiento que la empresa espera. Cualquiera de las dos opciones es mala.
Error 3: confundir migrar con copiar
"Queremos lo mismo, pero moderno." Es la frase que más aparece en proyectos de migración fallidos. Quien la dice está pensando que el sistema actual hace lo correcto y solo está obsoleto técnicamente. Casi nunca es así.
El sistema actual hace lo que hace porque se construyó así hace años, en un contexto distinto, con limitaciones que probablemente ya no existen. Replicarlo "tal cual" significa heredar todas sus malas decisiones de diseño, sus parches encadenados y sus cuellos de botella. Lo razonable no es copiar, es identificar qué hace bien (la lógica de negocio probada con años de uso) y qué hace por inercia (la implementación, las pantallas, las restricciones técnicas) para mantener lo primero y rediseñar lo segundo.
Error 4: preguntar al freelance que mantiene el sistema cómo migrarlo
El freelance o consultor externo que ha mantenido el sistema durante años conoce mejor que nadie las particularidades del sistema actual. También suele ser quien menos interés tiene objetivamente en que la migración salga bien.
No tiene por qué ser malicia. Es que su modelo de ingresos depende de que tu empresa siga necesitando su mantenimiento. Una migración exitosa a un sistema mantenible por otros (o por un equipo interno) reduce su rol. La consecuencia práctica es que sus aportaciones tienden a sobreestimar la complejidad del actual ("sin mí, esto no se puede migrar"), a infravalorar las alternativas ("ningún sistema estándar te va a dar esto") y a desincentivar la sustitución sin que parezca que lo está haciendo a propósito.
La información que tiene es valiosa. La opinión que da sobre la migración hay que filtrarla.
Error 5: empezar por elegir el stack tecnológico
Otro patrón común: la empresa decide que va a migrar a "X tecnología" antes de saber qué necesita el negocio. La elección viene de leer un artículo, de una recomendación de un conocido o porque el director técnico tiene preferencia personal. Después se busca agencia que trabaje con esa tecnología.
El problema es que la tecnología debería derivar de los requisitos, no preceder. Si necesitas algo simple y autocontenido, microservicios en Kubernetes te van a costar el triple en mantenimiento sin aportar valor. Si necesitas algo con alta concurrencia y procesamiento distribuido, un PHP monolítico clásico te va a frenar. Pero esa decisión solo se puede tomar bien después de saber qué hace el sistema, qué carga maneja y cómo se va a evolucionar.
Error 6: prometer fechas antes de empezar
La empresa, presionada por la jubilación inminente del freelance, por un cambio normativo, por un cliente importante o simplemente por hartazgo, fija una fecha límite. "Tiene que estar listo en seis meses." Llama a las agencias con esa fecha como restricción. Las agencias se ajustan al plazo recortando alcance, reduciendo pruebas o asumiendo riesgos.
Una migración de sistema heredado de complejidad media en una PYME suele requerir entre seis y doce meses. Forzar tres meses no acorta el proyecto, lo divide en dos: la entrega oficial a la agencia (que cumple un plazo aparente) y los siguientes seis a doce meses corrigiendo lo que no se hizo bien por las prisas. El coste total acaba siendo más alto que si se hubieran dado los plazos reales desde el principio.
Lo que sí funciona, en orden
La secuencia razonable para una migración de sistema heredado tiene seis pasos. Con tiempos típicos.
Primero: documentar el sistema actual desde dentro (4-8 semanas). No "el manual oficial" que probablemente no existe o está obsoleto. Una documentación honesta de qué hace el sistema, qué procesos cubre, qué reglas de negocio implementa, qué datos guarda y cómo se usa en el día a día. Esto se hace con observación directa, entrevistas a los usuarios reales y, si hay código, revisión del mismo. Es la fase que más tienta saltarse y la más imprescindible.
Segundo: separar lo esencial de lo accidental (1-2 semanas). Una vez documentado, distinguir qué hace el sistema porque el negocio lo requiere (esto se mantiene), qué hace porque se diseñó así por una limitación que ya no existe (esto se rediseña), qué hace porque alguien lo añadió hace años y nadie lo usa ya (esto se elimina). Esta separación la tiene que liderar quien dirige el negocio, no la agencia.
Tercero: definir el alcance de la migración (2-3 semanas). Qué se migra, qué se reescribe, qué datos históricos se traen y cuáles se quedan en archivo, qué procesos manuales se mantienen como están, qué integraciones hay que respetar. Acotar pequeño es mejor que abarcar grande: una migración por fases, donde se sustituye una pieza cada vez, suele tener mejor resultado que una sustitución total de golpe.
Cuarto: pliego para cotizar (1-2 semanas). Solo después de los tres pasos anteriores se redacta el pliego que se envía a las agencias. Con toda la información necesaria: qué se mantiene, qué se rediseña, qué datos hay, qué carga de uso, qué integraciones, qué requisitos no funcionales, qué fecha es razonable.
Quinto: cotización y elección de agencia (3-4 semanas). Tres ofertas, evaluación con matriz de criterios, conversaciones aclaratorias, selección. Dos meses entre que se manda el pliego y se firma el contrato es razonable si el pliego está bien hecho. Si está mal hecho, son tres o cuatro y con menos garantías.
Sexto: ejecución supervisada (4-12 meses según complejidad). Con hitos claros, revisiones periódicas y la persona que coordinó las fases anteriores presente durante la ejecución. Sin esa figura interna o externa que mantiene la coherencia, las agencias acaban tomando decisiones que el cliente descubre tarde.
El cálculo de tiempos
Sumando todo, una migración bien hecha de un sistema heredado de complejidad media supone entre 9 y 16 meses desde el día que se decide hacer hasta el día que está en producción y estabilizada. Tres a cuatro de preparación, dos de cotización, cuatro a diez de ejecución. La preparación parece mucho. No lo es. Es la única que evita que la ejecución se descontrole.
Las migraciones que arrancan saltándose la preparación tardan típicamente entre 14 y 24 meses, con sobrecoste medio del 60-80% sobre el presupuesto inicial. Aritméticamente, la preparación se paga sola.