Hace un tiempo atrás me tocó apoyar la migración de un sistema legado de escritorio. En realidad, eran varias plataformas pequeñas que, internamente, formaban un flujo de trabajo completo dentro de la empresa.
Cuando pregunté por qué me estaban llamando para algo que en el papel ya estaba realizado, la respuesta no fue ni sí ni no. Fue más bien: "está hecho, pero al mismo tiempo no".
Pedí más información y claro: la migración había sido realizada y entregada, pero no funcionaba. Al pedir el código, se veía bien, levantaba, pero como me habían dicho, no funcionaba. Ahí me di cuenta de algo importante: el sistema, la plataforma y el stack habían cambiado, pero la operación seguía esperando el mismo resultado de siempre.
Después pedí el código original. Me dijeron que la empresa tenía "una fuente de verdad" construida durante la migración. El problema era que, al mirarla, tenía parte del código y podías preguntarle al modelo interno de IA sobre los repositorios, pero no sobre lo que realmente hacía el usuario con ellos.
Ahí me entró el bichito. Como soy metido cuando algo me entusiasma, pedí el código original del producto y acceso a los usuarios finales para entender qué estaba pasando en el día a día, sin mirar la migración como punto de partida.
Me encontré con problemas bastante repetidos.
- Documentos grandes procesados dentro de una solicitud HTTP.
- Procesos largos que no calzaban bien con una ejecución web tradicional.
- Diferentes formatos de salida según el caso.
- Nomenclaturas específicas con fixes propios del programa instalado en cada máquina, sin tracking tipo Git para compartir esas diferencias.
- A veces había más de una versión del mismo sistema. Algunas tenían más funcionalidades, otras menos, y varias diferencias habían sido hechas como "gauchada".
Por ende, el código sí estaba migrado, pero el caso de uso no. Y a eso me refiero para que no me crucifiquen: migraron literalmente el código, pero no necesariamente lo que el sistema debía hacer.
¿Entonces copiar el código no es suficiente?
La respuesta fea es NO.
¿Por qué? Partamos por lo obvio, una web depende de servidores, límites de infraestructura, timeouts, memoria, colas, almacenamiento, permisos, tamaño de archivos, observabilidad y varias cosas que en una aplicación de escritorio muchas veces quedaban escondidas en la máquina del usuario.
Con contenedores y servicios cloud aparecen otros problemas. Puede que un proceso que antes corría localmente durante varios minutos ahora quede atrapado en una solicitud HTTP. Puede que un archivo que antes se generaba en la máquina del usuario ahora sea demasiado grande para responderlo directamente desde un endpoint. Puede que una salida que antes se guardaba en una carpeta local ahora necesite trazabilidad, permisos, expiración o un flujo de descarga.
Entonces fui a hablar con las personas que todavía estaban ahí y que habían construido las soluciones originales. Si pueden conseguirse un senior con más de 25 años de contexto, háganlo. Sáquenle todo el jugo posible. La IA ayuda, sí, pero una persona que entiende la operación real te puede ahorrar semanas de vueltas weonas.
Revisamos cada situación y dividimos el trabajo en consolidar una única "verdad" para cada caso. Con eso empezamos a levantar información, mucha documentación y apoyo de un modelo LLM. Pero si quieres que algo así salga bien, date el tiempo de leer. No se lo pases solamente al modelo.
Yo lo dividí así:
- Documentar técnicamente el proyecto original:
- Diagramas de flujo y un resumen técnico.
- Dependencias del proyecto original.
- Una aproximación de qué intenta hacer el sistema y qué problema intenta solucionar.
- Separación de los casos de uso del contexto global.
- Extracción de consultas de base de datos, separándolas por partes, si apuntan a un stored procedure, si usan funciones, si dependen de tablas auxiliares, etc.
- Hacer lo mismo con el proyecto nuevo, pero de forma más resumida, porque el más importante era el original.
- Comparar qué teníamos y qué no teníamos listo, porcentaje de avance, diferencias, mejoras propuestas por el cliente y brechas reales.
- Obtener información directa de los usuarios mediante reuniones. Para esto recomiendo activar la transcripción automática, porque puede que algunas partes del proyecto ya no se usen, o que se usen de una manera que nadie documentó.
Sé que probablemente alguien piense, "muchas vueltas, ¿por qué no le pasaste todo a un modelo para acelerar?". Pero eso ya se había hecho con prompts, skills y todo el show. El problema es justamente ese, usar agentes sin entender que tienes en tus manos y como deberia funcionar finalmente no sirve de mucho.
¿Entonces cuándo debería entrar la IA?
Mi respuesta es, siempre debería estar ahí, pero no como reemplazo del criterio, estamos hablando de algo que quizas quien sabe quien lo hizo y si continua en la compañia,o derechamente no se acuerda mucho.
Entonces el modelo debería estar aprendiendo qué haces, qué obtienes y cómo opera realmente el sistema. Debería alimentarse constantemente de la operación y quedar como una fuente de verdad consultiva y también de ejecución, pero una ejecución correctamente hecha.
No se trata solo de copiar código. Se trata de entender los problemas, resultados, tamaños de salida, bugs legados, funcionalidades, necesidades de los usuarios y continuidad operativa. Y para eso, tarde o temprano, un usuario final tiene que probar lo que estás construyendo. Más que mal, ellos son los que hacen la pega, ¿no?
Esto se puede lograr de varias formas, pero como siempre digo, depende primero de qué necesitas migrar. ¿Es una plataforma pequeña que hace una sola cosa? ¿Es un sistema grande y complejo que sostiene gran parte de la operación? ¿Son múltiples sistemas que se comunican entre sí para llegar a un resultado dentro de la empresa?
Toda estrategia depende del QUÉ, y ese QUÉ te va a dar el CÓMO.
En algunos casos serán ajustes pequeños que te llevarán rápido a un buen resultado. En otros, tendrás que ir estrangulando el software de a poco.
Si quieres una referencia para esto, puedes revisar el patrón Strangler Fig. Sinceramente, no tenía idea de este patrón hasta que me topé con estos mismos problemas, y es una buena base para comenzar.
Pero como dije desde el principio, siempre tienes que pensar en el depende.
Ahora, no pretendo dar una clase ni vender una verdad absoluta. No soy experto. Quizás a alguien le haga sentido lo que digo, quizás alguien crea que soy un idiota, y está bien. A mí me funcionó.
Lo que sí aprendí con esto es que muchas veces no se entiende qué significa realmente una migración de software y eso pensando en todos los ambitos, incluso empresas que se dice, dedican a esto especificamente. Sobre todo ahora, donde aparece la frase "pero tienes IA" y te intentan meter métricas de aceleración, porcentajes mágicos y bla bla bla.
Y la cosa no es tan simple, no tienes el mismo contexto de hace años atrás, el que llevó a que ese software fuera construido así. Y ese contexto no aparece solo por pasarle el repositorio a una IA.
En ese caso, la IA puede ser un muy buen partner, pero no reemplaza la responsabilidad primaria de entender el problema real. No basta con entender el flujo de la aplicación: hay que entender la operación que esa aplicación sostiene.
Migrar no es cambiar ventanas de desktop por pantallas web, ni cambiar una UI antigua por algo más moderno, ni envolver todo en APIs. Modernizar es entender qué parte del sistema sigue siendo verdad, qué parte ya no sirve y qué necesita realmente el usuario para seguir haciendo la pega.