Migrar un producto antiguo a una tecnología nueva con Claude Code

A quién le sirve. Equipos técnicos que tienen que reconstruir un producto antiguo sobre tecnología nueva y quieren dividir el trabajo en tickets que una IA ejecute con supervisión.

Qué hicieron

El ingeniero escribió archivos CLAUDE.md por capas con el contexto y le dio a Claude Code los repositorios antiguos, conexiones de solo lectura a MySQL y PostgreSQL y una implementación de referencia. Claude redactó el diseño y varios agentes revisores en paralelo lo pusieron a prueba. Después Claude creó 19 tickets en Jira. Cada uno tuvo un documento de diseño y otro de plan que él revisó, y se ejecutó en su propio worktree de git (una copia de trabajo aislada), con la integración continua vigilada en un bucle.

Cómo salió

En unos 15 días de trabajo salieron unos 50 tickets y 580 pruebas superadas, con más del 95 % de cobertura de la API y cero errores o vulnerabilidades al pasar a control de calidad. La revisión por IA solo detectó entre el 30 y el 40 % de los problemas, y el MCP de Jira no podía enlazar tickets.

Conviene saber

El coste rondó los 5.000 $ en tokens de Bedrock, sobre todo al principio. Además, el MCP de Confluence cortaba en silencio las páginas de más de unos 5 KB y sobrescribió dos documentos de diseño grandes.

Qué necesitas

• Claude Code con acceso a un modelo (en el caso, a través de Amazon Bedrock)
• Los repositorios antiguos (las carpetas donde vive el código) y una implementación de referencia de cómo quieres que quede
• Conexiones de solo lectura a las bases de datos antigua y nueva
• Un gestor de tickets (Jira en el caso) y un lugar para los documentos de diseño
• Un ingeniero con tiempo para revisar cada diseño y cada plan

Cómo hacerlo tú, paso a paso

1. Escribe archivos CLAUDE.md por capas, que son notas de contexto que Claude lee solo: reglas generales, reglas de cada repositorio y convenciones.
2. Dale a Claude Code los repositorios antiguos, las conexiones de solo lectura y la implementación de referencia.
3. Pide primero un diseño y un plan por fases con sus riesgos, con el prompt de esta ficha. Haz que varios agentes revisores lo cuestionen en paralelo.
4. Convierte el plan en tickets pequeños. Cada ticket lleva su documento de diseño y su plan, que revisas tú.
5. Ejecuta cada ticket en su propio worktree de git (una copia de trabajo aislada) y vigila en un bucle la integración continua (las pruebas automáticas que se lanzan con cada cambio).
6. Párate antes de fusionar nada o de aplicar cambios en una base de datos real.
7. Pasa a control de calidad con una revisión humana además de la de la IA.

Quiero una migración de prueba de [producto antiguo] desde [tecnología actual, por ejemplo 4 repositorios, MySQL y una versión antigua del framework] a [tecnología nueva, por ejemplo 2 repositorios, PostgreSQL y el framework actual]. Empieza leyendo el código y escribiendo un plan de migración por fases con sus riesgos, y ejecuta la primera fase en una rama nueva con las pruebas en verde. Párate para que yo revise antes de fusionar nada o de aplicar cambios en una base de datos real.

Consejos

• No te fíes solo de la revisión de la IA: detectó únicamente entre el 30 y el 40 % de los problemas.
• Gran parte del gasto se va al principio, al preparar el contexto. Mide un tramo pequeño antes de lanzar todo.
• Si usas un conector a Confluence u otra herramienta de documentos, comprueba que no recorta las páginas largas: en el caso las cortó en silencio y sobrescribió dos documentos de diseño.

Preguntas frecuentes

Fuentes

• @aws-builders en DEV ↗

En el directorio desde el 3 de octubre de 2026.