Statement of Work para migración AWS: qué debe incluir y qué preguntar antes de firmar

¿Qué es un SOW y por qué importa en una migración cloud?

Un Statement of Work es un contrato técnico que complementa el contrato comercial. Mientras el contrato comercial define precio, plazo de pago y condiciones generales, el SOW define el alcance técnico: qué sistemas se migran, bajo qué metodología, con qué criterios de aceptación y con qué responsabilidades divididas entre el proveedor y la empresa.

En migraciones a AWS, el SOW es especialmente importante porque hay múltiples zonas grises: ¿quién configura las cuentas AWS? ¿quién compra las licencias? ¿quién valida que la aplicación funciona en el nuevo entorno? ¿qué pasa si hay downtime no planificado durante el cutover? Sin un SOW claro, cada una de esas preguntas puede convertirse en un conflicto.

Las 7 secciones que no pueden faltar

10 preguntas que debes hacer antes de firmar

Más allá del texto del SOW, estas preguntas revelan si el proveedor tiene experiencia real o está vendiendo capacidades que no tiene:

• ¿Han hecho migraciones con AWS DMS antes? Si van a mover bases de datos relacionales en producción, deben tener experiencia con Change Data Capture (CDC). Sin CDC, el downtime puede ser de horas en lugar de minutos.
• ¿Tienen acceso a soporte AWS Business o Enterprise? Si aparece un problema con un servicio AWS durante la migración, el tiempo de respuesta de soporte puede determinar si el proyecto se bloquea por horas o días.
• ¿Cómo manejan un descubrimiento tardío? Es normal que durante el MRA aparezcan sistemas o dependencias que no estaban en el inventario inicial. ¿Cómo se maneja ese cambio de alcance? ¿Se cobra aparte? ¿Se extiende el plazo?
• ¿Quién ejecuta el proyecto — el vendedor o un subcontratista? En algunas empresas quien vende no es quien ejecuta. Pregunta directamente quién va a estar en el proyecto día a día y pide hablar con esa persona antes de firmar.
• ¿Qué pasa si el proyecto se extiende más del plazo acordado? ¿Hay costo adicional por semana extra? ¿Se renegocia? Tener esto claro antes evita conversaciones incómodas si el proyecto se alarga.
• ¿Las credenciales AWS quedan en poder de la empresa o del proveedor? Al finalizar el proyecto, la cuenta AWS y todas las credenciales deben quedar en manos de la empresa, no del proveedor. Algunos proveedores crean las cuentas a su nombre y esto genera dependencia.
• ¿Cuántas horas de QA y pruebas están incluidas? El testing en el nuevo entorno toma tiempo real. Si el SOW no especifica horas de pruebas, es probable que ese tiempo no esté presupuestado y el proveedor lo haga de prisa o lo cobre aparte.
• ¿El precio incluye el costo de AWS o solo los honorarios? Esta confusión es más común de lo que parece. Aclara si el valor del SOW cubre solo el trabajo del proveedor o también los servicios AWS que se usan durante el proyecto.
• ¿Qué monitoreo queda configurado al finalizar? Una migración exitosa incluye alertas de CPU, memoria, disponibilidad y costos configuradas en CloudWatch. Si el proveedor no menciona esto espontáneamente, pregunta directamente.
• ¿Pueden mostrar un proyecto similar que hayan completado? No necesitas un caso de éxito publicado — con una referencia de contacto de un cliente anterior es suficiente para validar experiencia real.

Señales de alerta en un SOW

Estos elementos en un SOW deben hacerte pausar antes de firmar:

• Alcance descrito en términos vagos: frases como “migración de infraestructura a AWS” sin listar sistemas específicos son una garantía de conflictos futuros.
• Sin plan de rollback documentado: cualquier proveedor con experiencia real tiene un plan B. Si no lo mencionan, es porque no lo han pensado.
• Cronograma sin hitos intermedios: un SOW que dice “entrega en 8 semanas” sin checkpoints no permite detectar problemas a tiempo. Los hitos semanales o por fase son la norma en proyectos bien gestionados.
• Sin mención de documentación de entrega: si el SOW no lista qué documentación recibes al finalizar, probablemente no recibirás nada.
• Precio muy por debajo del mercado: una migración seria de 5-10 servidores con bases de datos toma entre 6 y 12 semanas de trabajo. Si el precio implica que el proveedor trabajaría 2 semanas, algo no cierra — o el alcance es menor de lo que crees, o van a trabajar muy rápido sin las pruebas necesarias.

Cómo dimensionar el esfuerzo sin hablar de cifras

En vez de preguntar cuánto cuesta una migración, conviene preguntar qué mueve el costo. Tres cosas lo mueven más que ninguna otra, y las tres se pueden evaluar antes de pedir una sola cotización:

• Cuántos sistemas tienen dependencias reales entre sí. Diez servidores independientes son mucho más simples que cuatro que se hablan todo el tiempo. Lo que pesa son las dependencias, no la cantidad.
• Si las bases de datos en producción deben moverse con downtime mínimo. Suele ser el factor más grande de todos. Mover una base que puede estar seis horas abajo es un proyecto distinto de una que solo puede parar quince minutos.
• Cuánto hay que cambiar de la aplicación. Un rehost puro no toca código. En el momento en que hay que rehacer sesiones, almacenamiento de archivos o direcciones cableadas, el alcance ya es otro.

Responder esas tres antes de hablar con proveedores además te da con qué comparar cotizaciones: si dos propuestas difieren mucho, casi siempre es porque leyeron estas tres respuestas de forma distinta, no porque una sea más barata.