Estrategia de pruebas de migración a la nube: fases, tipos de prueba y lista de comprobación
Una estrategia de pruebas de migración a la nube define qué se prueba antes, durante y después de cada oleada de migración, y los criterios de éxito o fallo que deciden si una carga de trabajo entra en producción. Abarca funcionalidad, integridad de los datos, rendimiento, seguridad y reversión. El método: medir una línea base en la plataforma antigua, ejecutar una migración de prueba, comparar y hacer el corte solo cuando las cifras coinciden.
Puntos clave
- Capture las líneas base antes de mover nada: tiempos de respuesta, tasas de error, duraciones de los procesos por lotes y recuentos de filas.
- Acuerde los criterios de éxito o fallo y los desencadenantes de reversión antes de la primera oleada, no durante el corte.
- Use las funciones de prueba de las propias herramientas de migración: las migraciones de prueba de Azure Migrate y la validación de datos de AWS DMS existen para esto.
- Los tipos de prueba escalan con la vía de migración. Un lift-and-shift necesita sobre todo comprobaciones de paridad; un refactor necesita pruebas funcionales y de integración completas.
- Ejecute las migraciones de prueba en una red aislada. Microsoft desaconseja hacer migraciones de prueba en una red virtual de producción.
- Siga probando después del corte: vigile los indicadores de nivel de servicio (SLI) durante al menos un ciclo de negocio completo.
¿Qué son las pruebas de migración a la nube?
Las pruebas de migración a la nube son el conjunto de comprobaciones que demuestran que una aplicación, sus datos y su infraestructura funcionan al menos igual de bien después del traslado que antes. Se ejecutan a lo largo de toda la migración, no solo al final.
Se diferencian de las pruebas de versión habituales en tres aspectos:
- Cambia la plataforma, no el código. En un lift-and-shift el código es el mismo, así que se prueba el entorno: redes, identidad, rendimiento del almacenamiento, DNS y husos horarios.
- Los datos se mueven. Debe demostrar que cada fila y cada archivo han llegado sin cambios, y que los cambios en curso siguieron sincronizándose hasta el corte.
- La nube se comporta de otra manera. El escalado automático, los límites de los servicios gestionados, la latencia regional y la infraestructura compartida pueden cambiar el rendimiento aunque nada más haya cambiado.
Los criterios de éxito son los mismos que en local: las funciones deben funcionar, los datos deben estar completos y ser correctos, y los usuarios no deben notar una caída de velocidad.
Las cuatro fases de una estrategia de pruebas de migración
Divida las pruebas en cuatro fases, cada una con sus propias evidencias y su aprobación.
| Fase | Objetivo | Comprobaciones principales | Evidencias |
|---|---|---|---|
| 1. Planificación y línea base | Saber qué es «bueno» hoy | Mapa de dependencias, recorridos críticos de usuario, tiempos de respuesta actuales, duraciones de procesos por lotes, volúmenes de datos | Informe de línea base, criterios de éxito o fallo acordados |
| 2. Migración de prueba | Demostrar que la carga de trabajo funciona en el destino | Arranque y conectividad, pruebas funcionales de humo, integraciones, validación de datos, rendimiento bajo carga | Resultados de pruebas por carga de trabajo, lista de defectos |
| 3. Corte | Cambiar con seguridad, con una vía de vuelta | Sincronización final y validación de datos, comprobaciones de DNS y certificados, pruebas de humo, decisión go/no-go | Runbook de corte con tiempos, go/no-go firmado |
| 4. Posmigración | Confirmar la estabilidad y ajustar | Monitorización de SLI, aceptación de usuarios, prueba de copia y restauración, control de costes | Informe de hypercare, defectos cerrados |
Fase 1: planificación y línea base
Empiece con un inventario de aplicaciones, bases de datos, interfaces y tareas programadas, y ordénelos por riesgo para el negocio. Para cada carga de trabajo, registre las cifras con las que comparará después: tiempo de respuesta p95 de las transacciones clave, tasa de error, duración del proceso por lotes nocturno, tamaño de la base de datos y recuentos de filas.
Conviértalas en criterios. Por ejemplo: «p95 de la búsqueda de pedidos dentro del 10 % de la línea base», «cero discrepancias de filas en las tablas de finanzas», «el proceso nocturno termina antes de las 06:00». El libro de SRE de Google define un SLI como «una medida cuantitativa cuidadosamente definida de algún aspecto del nivel de servicio» y un SLO como un valor objetivo para ese indicador (libro de SRE de Google). Redactar sus criterios de ese modo hace objetiva la decisión go/no-go.
Fase 2: migración de prueba
Migre una copia de la carga de trabajo al destino y pruébela allí mientras el origen sigue funcionando. Las dos grandes plataformas lo admiten:
- Azure Migrate ofrece una migración de prueba que lanza las VM replicadas en una red virtual que usted elige. La guía de Microsoft indica que no se recomienda hacer la migración de prueba en una red virtual de producción, porque las conexiones abiertas con el entorno local pueden provocar VM duplicadas o cambios de DNS.
- AWS Application Migration Service (MGN) lanza instancias de prueba a partir de servidores replicados de forma continua, y la replicación continúa tras la prueba. AWS considera una buena práctica probar al menos dos semanas antes del corte previsto, para tener tiempo de corregir lo que se encuentre.
Aproveche esta fase para descubrir las sorpresas: direcciones IP fijas en el código, reglas de firewall que faltan, comprobaciones de licencia atadas al hardware y tareas que llaman a servidores que olvidó migrar.
Fase 3: corte
El corte es un runbook ensayado, no una improvisación. Congele los cambios, ejecute la sincronización final de datos, valide los datos, cambie el DNS o los destinos del balanceador de carga y ejecute las pruebas de humo. Cada paso tiene un responsable, una hora prevista y una acción de reversión.
Defina los desencadenantes de reversión de antemano, por ejemplo: «si las pruebas de humo fallan o la validación de datos muestra discrepancias 60 minutos después del cambio, revertir el DNS al origen». Ensaye la reversión al menos una vez durante las migraciones de prueba.
Fase 4: validación posmigración
Tras la puesta en producción, compare los SLI con la línea base durante al menos un ciclo de negocio completo, incluido el cierre de mes o los días de mayor actividad si es posible. Ejecute las pruebas de aceptación de usuario, pruebe una restauración desde las nuevas copias de seguridad y compare la primera factura de la nube con la estimación. Solo entonces dé de baja el origen.
¿Qué tipos de prueba debe ejecutar?
Adapte los tipos de prueba al riesgo de cada carga de trabajo. No todas las aplicaciones necesitan todas las pruebas.
| Tipo de prueba | Qué demuestra | Herramientas habituales |
|---|---|---|
| Funcional y de regresión | Las funciones y los recorridos de usuario siguen funcionando | Selenium, Playwright, suites de pruebas existentes |
| Integración | Se conectan las API, las colas de mensajes, las transferencias de archivos y los servicios de terceros | Pruebas de contrato, herramientas de pruebas de API, transacciones sintéticas |
| Validación de datos | Cada fila y cada archivo han llegado y coinciden | Validación de datos de AWS DMS, sumas de verificación, recuentos de filas, herramientas de comparación de bases de datos |
| Rendimiento y carga | Los tiempos de respuesta y el rendimiento cumplen los objetivos y el escalado automático funciona | JMeter, k6, Gatling |
| Seguridad y cumplimiento | Los accesos, el cifrado, las reglas de red y los registros son correctos | Herramientas de postura de seguridad en la nube, análisis de vulnerabilidades, revisiones de IAM |
| Resiliencia y DR | La carga de trabajo sobrevive a los fallos y se puede restaurar | Simulacros de conmutación por error, restauraciones de copias, AWS Fault Injection Service |
| Aceptación de usuario | Los usuarios de negocio confirman que el sistema es apto para su uso | UAT guionizada con aprobación |
Para pruebas de carga realistas que reproduzcan su tráfico pico, consulte nuestro servicio de pruebas de carga.
¿Cómo se validan los datos durante una migración?
Valide los datos en tres niveles: recuentos, sumas de verificación y comparación fila por fila en las tablas críticas.
- Recuentos: filas por tabla, archivos por bucket, bytes totales. Es rápido y detecta errores groseros.
- Sumas de verificación y agregados: sumas de importes, hashes de columnas clave. Detecta problemas de truncado y de codificación.
- Comparación a nivel de fila: en las bases de datos, la validación de datos de AWS DMS compara cada fila de origen con su fila de destino e informa de las discrepancias, incluidos los cambios capturados durante la replicación en curso.
Conviene planificar dos límites prácticos de la documentación de AWS: la validación necesita una clave primaria o un índice único en cada tabla, y añade carga de consultas tanto en el origen como en el destino. Programe las validaciones pesadas fuera del horario laboral, o ejecútelas como tareas de solo validación.
Pruebe también lo que cambia a propósito. Si convierte de Oracle a PostgreSQL, los tipos de datos, la colación y el orden difieren, así que compara los resultados de las consultas, no solo los valores almacenados. Nuestro servicio de migración de bases de datos cubre estas conversiones.
Cómo cambian las pruebas según la vía de migración
- Rehost (lift and shift): céntrese en la paridad del entorno. Compruebe redes, DNS, identidad, rendimiento del almacenamiento, tareas de copia de seguridad y agentes de monitorización. Las pruebas funcionales pueden limitarse a una prueba de humo más los recorridos críticos.
- Replatform: cuando mueve una base de datos a un servicio gestionado o una aplicación a contenedores, añada validación de datos, pruebas de rendimiento y comprobaciones de los límites del servicio gestionado, como el número de conexiones.
- Refactor: trátelo como software nuevo. Ejecute pruebas funcionales, de integración y de rendimiento completas, y use lanzamientos canary o blue/green con feature flags para limitar la exposición.
Lista de comprobación de pruebas de migración a la nube
- Inventario y mapa de dependencias completos para la oleada
- Líneas base registradas para los recorridos críticos, los procesos por lotes y los volúmenes de datos
- Criterios de éxito o fallo y desencadenantes de reversión aprobados por el responsable de negocio
- Entorno de pruebas aislado de las redes de producción
- Infraestructura definida como código para que pruebas y producción coincidan (consulte nuestro servicio de infraestructura como código con Terraform)
- Datos de prueba enmascarados cuando contienen datos personales
- Migración de prueba realizada, defectos corregidos y vueltos a probar
- Validación de datos superada para todas las tablas del alcance
- Prueba de carga al pico previsto superada
- Revisión de seguridad hecha: IAM, cifrado, grupos de seguridad, registros
- Reversión ensayada y cronometrada
- Runbook de corte con responsables y tiempos aprobado
- Paneles de monitorización y alertas posmigración operativos
- Restauración de copias de seguridad probada en la nueva plataforma
Cómo ayuda Opsio
Opsio planifica y ejecuta migraciones a la nube con las pruebas integradas en cada oleada. Para SilverRail Technologies, Opsio trasladó la filial nórdica de la empresa a AWS y la fusionó con la organización global. La fase Mobilize incluyó una migración piloto de prueba de cargas de trabajo seleccionadas, y el proceso de migración y los servicios de AWS se ajustaron a partir de esas pruebas. Los datos se movieron con herramientas nativas de PostgreSQL bajo un plan de corte detallado, y los cortes se hicieron en ventanas de servicio muy ajustadas para limitar el impacto en los clientes. Lea el caso de éxito de SilverRail.
Preguntas frecuentes
¿Qué es una estrategia de pruebas de migración a la nube?
Es un plan que define qué pruebas se ejecutan antes, durante y después de cada oleada de migración, los criterios de éxito o fallo de cada una y quién las aprueba. Abarca funcionalidad, datos, rendimiento, seguridad y reversión.
¿Cuáles son las fases de las pruebas de migración a la nube?
Planificación y línea base, migración de prueba, corte y validación posmigración. Cada fase produce evidencias, como informes de línea base, resultados de pruebas, un go/no-go firmado y un informe de hypercare.
¿Cómo se prueban los datos después de una migración a la nube?
Compare recuentos de filas y sumas de verificación de todas las tablas, y ejecute comparaciones a nivel de fila en los datos críticos. En AWS, la validación de datos de DMS compara las filas de origen y destino e informa de las discrepancias; necesita una clave primaria o un índice único en cada tabla.
¿En qué se diferencia probar un lift-and-shift de un refactor?
Un lift-and-shift necesita sobre todo comprobaciones de paridad del entorno y de los recorridos críticos, porque el código no cambia. Un refactor necesita pruebas funcionales, de integración y de rendimiento completas, ya que en la práctica lanza software nuevo.
¿Cuánto tiempo hay que monitorizar después del corte?
Al menos un ciclo de negocio completo, incluidos los días pico como el cierre de mes, antes de dar de baja los sistemas de origen. Mantenga abierta la opción de reversión hasta que se cumplan los criterios acordados.
Sobre el autor
Normas editoriales: Este artículo lo ha escrito un profesional certificado, indicado arriba como autor. Lo actualizamos cuando cambia la tecnología o la normativa que trata; las fechas de arriba indican la última actualización. Opsio mantiene su independencia editorial: recomendamos soluciones por su mérito técnico, no por relaciones comerciales.