"Deberíamos reescribir esto en [framework de moda]."
Es una frase que aparece en muchos proyectos. A veces tiene sentido. La mayoría de veces, no.
Razones legítimas para migrar
1. El stack actual bloquea el negocio
No puedes implementar funcionalidades críticas. No es que sea difícil, es que es imposible sin cambios fundamentales. Por ejemplo, si necesitas tiempo real (WebSockets) y tu stack solo soporta peticiones HTTP tradicionales, o si tu monolito no puede escalar horizontalmente y estás perdiendo usuarios en picos de tráfico.
2. No encuentras talento
Si tu stack es tan antiguo o nicho que no puedes contratar a nadie que lo mantenga, tienes un problema real de continuidad.
3. Costes de mantenimiento insostenibles
Cada cambio pequeño requiere semanas. Los bugs tardan días en diagnosticarse. El equipo tiene miedo de tocar ciertas partes del código porque nadie sabe exactamente qué hacen. Esto es deuda técnica fuera de control.
4. Seguridad comprometida
El framework ya no recibe actualizaciones de seguridad (end of life) y no hay forma de parchearlo. Estás expuesto a vulnerabilidades conocidas que cualquiera puede explotar.
Razones ilegítimas para migrar
1. "Es viejo"
Viejo no significa malo. jQuery sigue funcionando perfectamente para muchos casos de uso. PHP 8 es un lenguaje moderno y potente. Una tecnología "vieja" pero estable y mantenida es mejor que una nueva sin madurar.
2. "X framework es mejor"
¿Mejor para qué? ¿Para tu caso concreto? ¿Con tu equipo? ¿O mejor según las tendencias de Twitter? La tecnología se elige por contexto, no por popularidad.
3. "Los desarrolladores quieren"
Entendible — trabajar con tecnología antigua puede ser frustrante. Pero el aburrimiento técnico no justifica el riesgo empresarial de una migración.
4. "Todos lo están haciendo"
Lo que funciona para Netflix con miles de ingenieros no funciona para un e-commerce con 1.000 visitas diarias. El contexto lo es todo.
Costes ocultos de una migración
Estos son los que casi nadie presupuesta:
La alternativa: strangler fig pattern
En lugar de reescribir todo de golpe, el patrón strangler fig (inspirado en los higos estranguladoras que crecen alrededor de otro árbol) propone migrar pieza a pieza:
Técnicamente, esto se implementa con un proxy o API gateway — un intermediario que dirige las peticiones al sistema nuevo o al viejo según la ruta. Así ambos conviven durante la transición sin que el usuario note nada.
Es más lento, pero infinitamente menos arriesgado. No hay un "día D" donde todo puede fallar.
Señales técnicas de que sí necesitas migrar
Para los más técnicos, estas son señales claras:
Mi regla personal
Migra cuando el coste de no migrar supere claramente el coste de migrar.
Y ese cálculo debe incluir:
Conclusión
La mayoría de migraciones que se proponen son innecesarias. Las que son necesarias, se subestiman brutalmente.
Antes de migrar, pregúntate: ¿qué problema concreto estoy resolviendo? Si la respuesta es vaga, probablemente no deberías migrar. Si es específica y medible, entonces vale la pena analizar el camino.
Si estás considerando un cambio de tecnología y quieres una segunda opinión, puedo ayudarte a evaluar si realmente merece la pena o si hay alternativas menos drásticas.