Actualizar Lambdas Legacy a Python 3.12 — en una sola conversación

Actualizar código heredado puede ser un caos. Se rompen dependencias, desaparecen los logs y lo que parecía aislado, termina impactando en otros entornos. Pero con las herramientas adecuadas y un plan claro, el proceso se convierte en algo fluido, documentado y repetible.

Este post resume cómo migramos una función crítica de AWS Lambda —que corría sobre el runtime obsoleto Python 2.7— a Python 3.12. Sin adivinanzas. Sin downtime. Usamos la interfaz conversacional de Q Developer, junto con MCP Servers, para ejecutar la migración en pocas horas.

¿El resultado? Un flujo automatizado, trazable y reutilizable, que hoy usamos como estándar para cualquier Lambda legacy en nuestro entorno.

¿Qué es Q Developer?

Q Developer es un asistente de desarrollo potenciado por IA, creado por AWS. Funciona como una interfaz CLI combinada con un entorno conversacional, diseñado para guiar a los desarrolladores en tareas cloud en tiempo real.

Podés pedirle que escanee tu infraestructura, sugiera comandos, cree tickets en Jira o incluso genere planes de despliegue. Su diferencial es cómo se integra con el Model Context Protocol (MCP) para manejar lógica, permisos y herramientas de forma estructurada y trazable.

Con MCP, Q Developer se convierte en más que un asistente CLI: es una capa de orquestación con memoria, contexto y trazabilidad. Ideal para entornos de desarrollo donde la automatización y la iteración rápida son clave.

El Desafío

Teníamos una Lambda crítica, parte de un flujo de automatización, todavía corriendo en Python 2.7, un runtime sin soporte y sin actualizaciones de seguridad. Además, ya no era compatible con muchos paquetes modernos.

Nuestro objetivo era simple: migrarla a Python 3.12, sin perder logs, métricas ni pasos del despliegue.

Pero no era solo cambiar de versión.

Necesitábamos:

• Migrar sin downtime

• Preservar logs, métricas y alarmas

• Evitar pasos manuales que suman riesgo

• Documentar todo el proceso para reutilización

  
  

Necesitábamos algo más que una guía paso a paso: necesitábamos un framework, no una solución puntual.

¿Qué cambió todo? Un enfoque conversacional + contextual

Esta migración no se hizo con scripts sueltos en Notion o comandos pegados en Slack. Ejecutamos todo desde Q Chat, la interfaz conversacional dentro de Q Developer. Con Q Chat, orquestamos el proceso completo: desde el diagnóstico hasta el despliegue.

¿Qué lo hizo tan potente?

• Instrucciones guiadas en tiempo real — Q indicaba qué hacer y pedía confirmación cuando era necesario.

• Ejecución automatizada con MCP — Cada comando de AWS CLI o ticket en Jira fue generado desde lógica contextual.

• Todo en un solo lugar — Logs, validaciones y artefactos en la misma interfaz.

• Documentación en vivo — Todo el flujo quedó registrado y vinculado a Jira automáticamente.
  

Se sintió como trabajar con un experto que conoce a fondo tu entorno cloud.

Herramientas que usamos

Nuestro stack para esta migración:

• Q Developer + Q Chat

• MCP Servers:

  • awslabs.core-mcp-server@latest

  • awslabs.aws-serverless_mcp_server@latest

  • jira-mcp conectado vía SSE endpoint

• Python 3.12, requests, urllib3 y librerías compatibles

• AWS CLI, bash, curl, jq

• Empaquetado ZIP, carpeta temporal /tmp/lambda

• CloudWatch Logs, métricas personalizadas, alarmas

• Espacio de trabajo Jira con seguimiento vía MCP

Este no fue un setup teórico. Lo replicamos ya en varios equipos.

El flujo, paso a paso

1. Detección y planificación

Pedimos a Q Chat que identificara funciones aún en Python 2.7. En segundos, generó un listado con métricas de invocación. Marcamos la prioritaria.

Q ejecutó:

• Creación automática de ticket en Jira

• Generación del plan de migración

• Identificación de roles, logs y targets

• Definición de rollback documentado

Planeamos, pero ya podíamos ejecutar.

2. Preparar el entorno

Q creó una carpeta segura y extrajo el código con aws lambda get-function. Luego escaneó dependencias y mostró:

• Problemas específicos del runtime

• Imports obsoletos

• Conflictos de librerías con Python 3.12

Después, propuso un entorno de prueba para validar comportamiento antes de migrar.

3. Refactor con confianza

Acá vino lo complejo: transformar el código legacy a Python 3.12.

Q nos guió paso a paso:

• Señaló funciones obsoletas como wrap_socket

• Sugirió reemplazar print por logging

• Aplicó type hints y mejoras de manejo de errores

Usamos pyupgrade, black y mypy, todo orquestado desde la interfaz CLI. También generó scaffolding de tests unitarios.

4. Empaquetar y desplegar

Q generó un artefacto ZIP, con hash de build y configuración firmada. Lo probamos en un entorno shadow con dry-run automático.

Luego:

• Ejecutamos pruebas de integración

• Ajustamos permisos IAM

• Cambiamos el runtime

• Desplegamos en producción

Todos los logs y estados fueron enviados a Jira.

5. Migración de logs en CloudWatch

La función original tenía logs que no podíamos perder. Q automatizó:

• Replicación de grupos

• Actualización de alarmas

• Clonado de políticas de retención

Hizo la transición por partes, validando cada digest hash.

6. Validación en producción

Tras el despliegue, Q ejecutó validaciones:

• Métricas en tiempo real: latencia, errores

• Activó logs de debug temporalmente

• Lanzó invocaciones canary

Un timeout inicial nos permitió detectar un cold start alto. Q ajustó la memoria y redeployó.

Resultados

• Migración a Python 3.12 completada

• Cero downtime, cero rollback

• Continuidad total de logs y métricas

• Ticket Jira generado automáticamente

• Documentación completa y reutilizable

• Scripts de despliegue listos para otros equipos
  

Por qué MCP fue clave

Velocidad

Automatizamos tareas repetitivas, paralelizamos análisis y despliegue. Ganamos horas.

Precisión

Sin comandos mal tipeados. Sin pasos omitidos. La lógica la resolvió la IA.

Visibilidad

Tuvimos acceso a logs y métricas en tiempo real. Nada quedó a ciegas.

Documentación

Cada acción quedó trazada y vinculada a Jira. Sin tareas a posteriori.

Escalabilidad

El proceso ya se replicó en otras Lambdas. Logs migrados sin pérdida. Observabilidad intacta.

¿Y el ticket?

El ticket en Jira fue generado automáticamente por MCP desde Q Developer. Incluyó:

• Objetivo de la migración

• Acciones ejecutadas

• Riesgos considerados

• Criterios de éxito

• Confirmación de logs y métricas
  

Todo quedó escrito antes de terminar el despliegue. Sin tareas pendientes.

Pensamiento final

Esto no es solo una historia de upgrade técnico. Es la diferencia entre ver la migración como una tarea aislada o como parte de un sistema más inteligente. Con Q Developer, MCP y un flujo bien diseñado, transformamos un problema heredado en un proceso automatizado, auditable y listo para escalar. ¿Querés modernizar tu infraestructura sin caos?Este enfoque funciona. Lo comprobamos. ¿Lo escalamos a tu entorno? Estamos listos — desde el prototipo hasta producción.

Nicolas Rossi Martin Carletti Valentino Gabrieloni

Solutions Architect Cloud Engineer Cloud Engineer