Cuando llegamos al proyecto, el cliente tenía 11 años de infraestructura on-premise acumulada. Ficheros de configuración de Ansible dispersos en cuatro repositorios distintos, scripts de bash sin documentar, dependencias entre servicios que nadie del equipo actual sabía que existían. La pregunta era sencilla: ¿cómo migramos esto a AWS sin romper producción? La respuesta fue menos obvia: con un LLM como copiloto de análisis.
Las migraciones cloud de infraestructura legacy son proyectos donde el conocimiento tácito mata los plazos. El equipo que montó esa infraestructura ya no está, la documentación tiene tres años de retraso y nadie quiere tocar nada por miedo a romper algo que "simplemente funciona".
En este artículo contamos exactamente cómo usamos modelos de lenguaje grande —concretamente GPT-4o y Claude 3.5 Sonnet— para comprimir semanas de análisis manual en días, y qué aprendimos en el proceso.
El problema real de migrar infraestructura legacy
Antes de hablar de IA, conviene entender por qué las migraciones legacy son tan costosas en tiempo. El problema no es técnico, es epistemológico: no sabes lo que no sabes.
En una infraestructura con años de historia, las dependencias se acumulan de formas no documentadas. Un servicio de reporting que solo se ejecuta el primer día de cada mes y que consume una base de datos que creías que podías migrar antes. Un script de backup que escribe en una ruta hardcodeada que solo existe en el servidor antiguo. Una regla de firewall que bloquea tráfico que debería estar bloqueado pero que nadie recuerda por qué.
Cómo usamos LLMs para el análisis de configuración
La aproximación que desarrollamos tiene tres fases diferenciadas. No es magia: es ingeniería de prompts aplicada con rigor y mucho contexto.
Fase 1: Ingesta y mapeo de configuración
El primer paso fue construir un pipeline de ingesta que extraía todos los ficheros de configuración relevantes —playbooks de Ansible, Dockerfiles, docker-compose, ficheros de nginx, configuraciones de cron, scripts de bash— y los convertía en chunks procesables por el modelo.
Para cada chunk, pedíamos al modelo que respondiera tres preguntas concretas:
- ¿Qué servicios o componentes define o referencia este fichero?
- ¿Qué dependencias externas necesita (puertos, rutas, variables de entorno, otros servicios)?
- ¿Qué asunciones sobre el entorno hace que podrían romperse en una migración cloud?
Las respuestas se almacenaban en una base de datos estructurada que íbamos enriqueciendo progresivamente. Después de procesar los ~4.200 ficheros del proyecto, teníamos un grafo de dependencias generado por el modelo que ningún humano habría podido construir en el mismo tiempo.
Fase 2: Detección de dependencias ocultas
Con el grafo inicial construido, la segunda fase consistía en hacer queries de razonamiento sobre él. Le preguntábamos al modelo cosas como:
Prompts de detección de dependencias
La tasa de falsos positivos fue del 12% —el modelo a veces veía dependencias donde no las había—, pero la tasa de falsos negativos fue prácticamente cero. Preferimos revisar 12 dependencias que no existían a perdernos una que sí existía.
Fase 3: Generación automática de documentación
La tercera fase fue la más inesperadamente valiosa. Una vez que el modelo tenía el contexto completo del sistema, lo usamos para generar documentación de arquitectura que nunca había existido.
El output incluía: diagramas de dependencias en formato Mermaid, descripciones de cada servicio en lenguaje natural, runbooks de operación básicos y una lista priorizada de riesgos de migración con justificación. Todo revisado y corregido por el equipo de ingeniería, pero con el 80% del trabajo ya hecho.
Qué modelos usamos y por qué
Probamos varios modelos a lo largo del proyecto. No todos funcionaron igual de bien para las mismas tareas.
GPT-4o fue más preciso en el análisis de código bash y la detección de patrones en scripts de infraestructura. Su ventana de contexto y la velocidad de respuesta lo hacían ideal para el procesamiento en batch de los ficheros de configuración.
Claude 3.5 Sonnet fue claramente superior para la generación de documentación en español técnico y para las tareas de razonamiento sobre el grafo de dependencias. Las explicaciones eran más coherentes y requerían menos edición.
Para tareas de clasificación rápida —¿este fichero es relevante para la migración o no?— usamos GPT-4o mini, que reducía el coste por token en un 90% con resultados aceptables para esa tarea concreta.
Los límites de este enfoque
- El modelo no entiende el negocio: puede decirte que dos servicios están conectados, pero no puede decirte si esa conexión es crítica o un artefacto histórico irrelevante. Eso requiere contexto humano.
- El contexto tiene límites: con 4.200 ficheros, no podíamos meter todo en una sola llamada. El chunking introduce pérdida de información entre chunks.
- Los outputs requieren revisión: el 100% de la documentación generada fue revisada por el equipo de ingeniería. Publicar el output de un LLM sin revisión en un proyecto de migración es una forma creativa de crear problemas nuevos.
- El coste no es trivial: el coste en tokens del proyecto completo fue de aproximadamente 380€. No es caro para lo que ahorra, pero es un coste real que hay que presupuestar.
Conclusión
El análisis manual de infraestructura legacy tiene un problema de incentivos: es tedioso, lleva tiempo y el equipo tiende a parar cuando cree que ha encontrado "suficiente". El análisis con LLM es sistemático por naturaleza: procesa todos los ficheros, no solo los que parecen importantes a primera vista.
El resultado no es un análisis perfecto. Es un análisis exhaustivo que sirve de base para el trabajo de ingeniería humana, que es donde el juicio experto realmente importa.
¿Tienes una migración cloud en mente?
Te contamos cómo aplicamos este enfoque a tu infraestructura y qué podríamos encontrar antes de que lo encuentres en producción.
Hablar con un experto →