Cuándo una migración no vale la pena

Casi todas las migraciones que revisamos se justifican con un ahorro mensual y se pagan con algo que no aparece en la justificación: seis meses de atención del equipo que construye el producto. Ese es el costo real, y es el que decide si la migración vale la pena.

El cálculo que casi nadie hace completo

El punto de equilibrio de una migración es simple de escribir y molesto de llenar:

meses para recuperar =
    (horas de equipo × costo hora
     + meses de operación en paralelo × costo de ambos sistemas
     + costo esperado de incidentes)
    ÷ ahorro mensual real

Las tres líneas del numerador son las que se subestiman:

• Horas de equipo. No solo de quien ejecuta la migración. Cuente las revisiones, las reuniones de coordinación, el tiempo de quien responde preguntas sobre el sistema viejo y el trabajo de producto que se dejó de hacer.
• Operación en paralelo. Toda migración responsable corre los dos sistemas a la vez durante un tiempo. Ese solapamiento es doble factura, y dura más de lo planeado en la mayoría de los casos.
• Incidentes esperados. No es pesimismo: es que un sistema recién migrado tiene un perfil de fallas distinto al que su equipo sabe diagnosticar. Presupuestar cero incidentes es presupuestar mal.

Y en el denominador, el ahorro mensual real casi nunca es el que dice la propuesta del proveedor nuevo, porque la comparación suele omitir egreso de datos, respaldos, monitoreo y las horas de administración que el esquema nuevo requiere.

Con el cálculo completo, la regla que usamos es: por debajo de 12 meses la migración se defiende sola; entre 12 y 24 necesita otra razón además del costo; por encima de 24 meses hay que justificarla con algo que no sea dinero.

Cuatro casos donde la respuesta correcta es no migrar

1. El sistema actual es aburrido y funciona. “Está en una tecnología vieja” no es un problema de negocio si el sistema está estable, alguien lo sabe operar y el proveedor todavía publica parches de seguridad. La deuda técnica solo cuesta cuando frena un cambio que usted necesita hacer. Si nadie está intentando cambiar ese sistema, la deuda no está generando intereses.

2. La migración depende de una persona. Si el conocimiento del sistema actual vive en una sola cabeza y esa persona también va a ejecutar la migración, no tiene un plan: tiene un riesgo con cronograma. La secuencia correcta es documentar y distribuir el conocimiento primero, y eso ya es un proyecto en sí mismo.

3. Se está migrando para no tomar una decisión de producto. Ocurre más de lo que parece: el sistema no da abasto porque el modelo de datos no soporta lo que el negocio hace hoy, y en vez de rediseñar el modelo se cambia de infraestructura. La carga se mueve a un servidor más grande y el problema real sigue ahí, ahora con una factura mayor.

4. El ahorro es real pero pequeño frente al costo de oportunidad. Ahorrarse cuatro millones de pesos mensuales es atractivo hasta que se calcula que los seis meses de equipo dedicados a lograrlo eran los seis meses en los que se iba a lanzar la funcionalidad que sí genera ingresos.

Cuándo sí, sin discusión

Hay casos en los que el análisis financiero es secundario:

• Fin de soporte del proveedor. Cuando la versión que usted corre deja de recibir parches de seguridad, la migración deja de ser una decisión de costo y pasa a ser una de exposición.
• Una restricción de cumplimiento o contractual que el esquema actual no puede satisfacer, como residencia de datos exigida por un cliente o por regulación.
• Un límite técnico duro y cercano. No “va lento”, sino un techo real: la instancia más grande del proveedor, el máximo de conexiones, un límite de almacenamiento. Aquí la pregunta no es si migrar sino cuándo, y conviene que sea antes de chocarse con el techo.
• Concentración de riesgo en un proveedor sin salida. Si perder ese proveedor lo dejaría sin operación y no existe un plan de reversa, está pagando un seguro que no tiene.

Cómo bajar el costo de una migración que sí va

Si la decisión es migrar, tres cosas reducen el costo más que cualquier elección de tecnología:

Migre en rebanadas verticales, no por capas. Mover “toda la base de datos” primero y “toda la aplicación” después obliga a mantener las dos mitades hablando entre sí a través de la red durante meses. Mover una funcionalidad completa de punta a punta permite validar el camino entero con poco alcance y aprender antes de repetirlo.

Escriba el plan de reversa antes que el de avance, y pruébelo. Un plan de reversa que nunca se ejecutó en un ensayo no es un plan, es una intención escrita bajo presión.

Congele el alcance funcional durante la migración. La tentación de “ya que estamos, aprovechemos para mejorar X” es la razón por la que las migraciones se doblan en tiempo. Si el sistema nuevo hace cosas distintas al viejo, no puede comparar comportamientos para saber si migró bien.

---

Si tiene una migración planeada y quiere el cálculo del punto de equilibrio con los números suyos, escríbanos. A veces el resultado del análisis es que no la haga, y ese también es un entregable válido.