Prueba visual de migración: proceso de verificación sistemática de la integridad visual de un sitio web antes y después de una migración (cambio de CMS, de framework, de diseño o de infraestructura), que consiste en capturar una referencia visual completa del sitio antiguo y compararla automáticamente con el nuevo para detectar cualquier regresión no intencional.
Cada migración de sitio web es una apuesta. Lo sabes si has vivido una. Ya sea un cambio de CMS, un paso a un nuevo framework front-end o un rediseño completo, el momento en que pasas de lo viejo a lo nuevo es el momento en que aparecen los problemas.
Y estos problemas no son los que esperas. No es la página de inicio la que se rompe — esa la verifica todo el mundo. Es la página de condiciones generales enterrada a tres niveles de navegación cuyo formato se ha desmoronado. Es el widget de newsletter cuyo botón se ha vuelto invisible porque el color de fondo cambió. Es el margen de 24 píxeles entre secciones que pasó a 0 en móvil porque un reset CSS del nuevo framework sobreescribió los estilos antiguos.
Según un análisis de Semrush, una migración de sitio mal ejecutada puede provocar una caída del tráfico orgánico del 10 al 30% en las semanas siguientes — y parte de esa caída proviene directamente de problemas de interfaz que degradan la experiencia del usuario y aumentan la tasa de rebote.
La prueba visual es el único método fiable para sistematizar la verificación antes/después de una migración. Y sin embargo, la mayoría de los equipos todavía prescinde de ella.
Por qué las migraciones son el momento de riesgo máximo
Una migración no es un despliegue clásico. En un despliegue clásico, modificas una parte del sistema y el resto no se mueve. En una migración, todo se mueve al mismo tiempo — o casi. Y es ese "casi" lo que es peligroso.
El volumen de cambios es inmanejable manualmente
Tomemos una migración de CMS: de WordPress a un headless CMS como Strapi o Contentful, por ejemplo. El contenido se migra, las plantillas se reescriben, el sistema de routing cambia, los plugins de WordPress desaparecen y son reemplazados por código custom o integraciones de terceros. Cada página del sitio está potencialmente afectada.
Si tu sitio tiene 50 páginas, verificar manualmente cada una en desktop y móvil lleva días. Si tu sitio tiene 500 — algo habitual en un sitio e-commerce o un sitio corporativo multilingüe — la verificación manual completa es simplemente imposible dentro de un calendario de proyecto realista.
El resultado: los equipos verifican las 10 páginas principales y esperan que el resto aguante. Es una estrategia basada en la esperanza, no en el rigor.
Las regresiones son sutiles
Los bugs visuales post-migración no son errores 500 ni páginas en blanco. Son degradaciones sutiles que nadie nota hasta que un usuario — o peor, un cliente — lo reporta.
Un espaciado que pasa de 16 píxeles a 12 píxeles. Una tipografía que pasa de peso 400 (regular) a 300 (light). Un degradado CSS que ya no se muestra porque la sintaxis cambió ligeramente entre el framework antiguo y el nuevo. Un border-radius que desaparece en las tarjetas de producto. Una sombra que se desvanece porque la propiedad CSS fue sobreescrita por un reset más agresivo.
Individualmente, cada una de estas regresiones es menor. Colectivamente, dan la impresión de que el sitio ha "perdido calidad" sin que nadie pueda señalar un problema específico. Es la muerte por mil cortes de la percepción de calidad.
Las pruebas funcionales no cubren lo visual
Tu suite de pruebas funcionales verifica que el botón "Añadir al carrito" funciona, que el formulario de contacto envía, que la redirección 301 se realiza correctamente. Es necesario. Pero ninguna prueba funcional verifica que el botón "Añadir al carrito" sigue siendo verde con un border-radius de 8 píxeles y un margen de 16 píxeles debajo del precio.
Las pruebas funcionales responden a la pregunta "¿funciona?". La prueba visual responde a la pregunta "¿se ve como debería?". Durante una migración, ambas preguntas son críticas.
Los tipos de migración y sus riesgos visuales específicos
No todas las migraciones crean los mismos riesgos. Estos son los escenarios más comunes y las regresiones visuales típicas asociadas.
El rediseño: el riesgo más alto
El rediseño es con diferencia la migración más arriesgada visualmente. También es la más común: según una encuesta de HubSpot, las empresas rediseñan su sitio web en promedio cada dos o tres años.
En un rediseño, todo debe cambiar — ese es el objetivo. Pero "todo cambia" no significa "nada necesita verificarse". El brief creativo dice "nuevo header, nuevo footer, nueva paleta de colores". No dice "el texto de las condiciones generales puede perder su formato" ni "las publicaciones antiguas del blog pueden tener imágenes que ya no se muestran correctamente en el nuevo layout".
Las regresiones típicas de un rediseño incluyen contenido antiguo que no se adapta al nuevo layout (textos demasiado largos, imágenes con la proporción incorrecta), componentes secundarios olvidados en el rediseño (páginas de error, emails transaccionales, popups, modales), estados interactivos que cambian de manera inconsistente (hover, focus, active en botones y enlaces), y breakpoints responsive que ya no corresponden a los mismos viewports.
Migración de CMS
Pasar de WordPress a Contentful, de Drupal a Strapi, de Magento a Shopify — cada migración de CMS implica reescribir las plantillas que producen el HTML y el CSS. El contenido permanece teóricamente idéntico, pero el renderizado visual puede cambiar de forma inesperada.
Los riesgos específicos de la migración de CMS son el contenido enriquecido (WYSIWYG) que pierde su formato durante la transferencia, los shortcodes o widgets específicos del CMS que no se migran, las imágenes que cambian de dimensiones o calidad de compresión, y las URLs de recursos (CSS, imágenes, fuentes) que se rompen en el nuevo sistema.
Migración de framework front-end
Pasar de jQuery a React, de AngularJS a Vue, de React class components a Next.js App Router — estas migraciones cambian fundamentalmente la forma en que se genera el HTML y se aplica el CSS.
El riesgo principal es la diferencia de renderizado entre el framework antiguo y el nuevo, incluso con el "mismo" CSS. Cada framework tiene sus propios mecanismos de scoping CSS, gestión de animaciones y renderizado condicional. El CSS-in-JS del framework antiguo no produce necesariamente el mismo resultado que los CSS Modules del nuevo.
Migración de infraestructura
Cambiar de proveedor de hosting, pasar de un servidor dedicado a un CDN, migrar de AWS a GCP — estos cambios no deberían teóricamente cambiar nada del renderizado visual. En teoría.
En la práctica, las diferencias de configuración del servidor (compresión de imágenes, headers de caché, versiones de Node.js para SSR) pueden producir diferencias visuales sutiles. Un servidor que comprime imágenes JPEG al 80% en lugar del 85% produce imágenes ligeramente diferentes. Un renderizado SSR en una versión diferente de Node.js puede generar HTML ligeramente diferente si el código utiliza funcionalidades dependientes de la versión.
El método: prueba visual antes/después de la migración
El principio es simple y potente: capturar una fotografía visual completa del sitio antiguo, luego comparar sistemáticamente con el nuevo. Cada diferencia es detectada, analizada y clasificada como intencional o regresión.
Paso 1: capturar la baseline en el sitio antiguo
Antes de tocar nada, captura el estado visual completo de tu sitio actual. Es tu baseline — tu verdad de referencia.
¿Qué páginas capturar? Idealmente, todas. En la práctica, prioriza en función del tráfico y la importancia de negocio. Empieza por las páginas que generan tráfico orgánico significativo (consulta Google Analytics 4 o Search Console), las páginas de conversión (registro, compra, solicitud de presupuesto), la página de inicio y las páginas de navegación principal, y las plantillas únicas (cada tipo de página: artículo, producto, categoría, landing page).
¿En qué viewports? Como mínimo desktop (1440px o 1920px) y móvil (375px o 393px). Si tu audiencia en tableta es significativa, añade un viewport intermedio (768px o 1024px).
¿Cuándo capturar? Lo más tarde posible antes de la migración, para que la baseline refleje el estado más reciente del sitio. Pero no el mismo día del cambio — necesitas tiempo para verificar que las capturas están completas y correctas.
Esta baseline es tu red de seguridad. Trátala con la misma seriedad que un backup de base de datos antes de una migración.
Paso 2: preparar la comparación
Antes de comparar, identifica los cambios intencionales. Si haces un rediseño, el nuevo header será diferente del antiguo — ese es el objetivo. Documenta estos cambios esperados para poder distinguirlos de las regresiones durante la comparación.
Crea una lista de las zonas que cambiarán intencionalmente y configura tu herramienta de prueba visual para tratarlas por separado. El objetivo es concentrar tu atención en las diferencias no intencionales — las verdaderas regresiones.
Paso 3: capturar el nuevo sitio y comparar
Una vez que el nuevo sitio está desplegado (en un entorno de staging, no en producción), captura las mismas páginas en los mismos viewports y lanza la comparación con la baseline.
Cada diferencia detectada cae en una de estas categorías.
Cambio intencional: el nuevo diseño es diferente, es lo esperado. Validas y actualizas la baseline.
Regresión: algo cambió que no debería haber cambiado. Creas un ticket y lo corriges antes de la puesta en producción.
Zona gris: un cambio sutil del que no estás seguro si es intencional o accidental. Consultas al diseñador o al jefe de proyecto para aclarar.
Paso 4: iterar antes de la puesta en producción
La primera comparación revelará decenas, incluso cientos de diferencias. Es normal. El trabajo consiste en clasificarlas, corregir las regresiones y relanzar la comparación hasta que las únicas diferencias restantes sean intencionales.
Este proceso iterativo es exactamente lo que la prueba visual automatizada hace viable. Hacer esta clasificación manualmente en 100 páginas sería agotador y propenso a errores. Con una herramienta que resalta las diferencias y permite validarlas o rechazarlas una por una, es metódico y fiable.
Paso 5: monitorización post-migración
La migración no termina el día del cambio. En los días y semanas que siguen, pueden aparecer problemas adicionales — una caché que se vacía y revela un problema oculto, contenido antiguo que pasa por una ruta de renderizado no probada, una interacción entre el nuevo código y una extensión de navegador popular.
Mantén una monitorización visual regular durante al menos dos semanas después de la migración. La nueva baseline es el nuevo sitio validado, y cualquier desviación respecto a esta baseline es una alerta.
Lo que Delta-QA aporta en un contexto de migración
Delta-QA es particularmente adecuado para migraciones por varias razones estructurales.
La captura de baseline sin código. No necesitas configurar un pipeline CI/CD para capturar el sitio antiguo. Abres Delta-QA, navegas por tu sitio y la herramienta captura cada página. Es una operación que cualquier miembro del equipo puede hacer — el jefe de proyecto, el tester, el diseñador.
La comparación estructural. El algoritmo de 5 pasadas de Delta-QA no compara imágenes. Compara las propiedades CSS calculadas — dimensiones, colores, tipografías, espaciados, posiciones. Cuando te dice "el margen entre la sección Hero y la sección Funcionalidades pasó de 64px a 48px", sabes exactamente qué verificar y qué corregir.
Este enfoque elimina el ruido de falsos positivos por diferencias de renderizado que afectan a las herramientas pixel diff durante las migraciones. Un cambio de framework puede modificar ligeramente el anti-aliasing de las fuentes sin cambiar las propiedades CSS — una herramienta pixel diff señalaría un cambio en cada texto de cada página. Delta-QA ignorará estas diferencias cosméticas y se centrará en los verdaderos cambios estructurales.
Cero infraestructura. En un contexto de migración, el equipo ya está sobrecargado. Añadir una herramienta que requiere un pipeline, una cuenta cloud, integración SDK y mantenimiento, es añadir complejidad en el peor momento. Delta-QA se instala en minutos y funciona inmediatamente, en local, sin dependencias externas.
Los errores clásicos a evitar al probar una migración
La experiencia muestra que ciertos errores se repiten sistemáticamente. Conocerlos permite evitarlos.
No capturar la baseline a tiempo. Si capturas la baseline después de haber comenzado la migración, ya no tienes una referencia fiable del sitio antiguo. Captura antes de cualquier modificación, y conserva esas capturas con cuidado.
Probar solo en un entorno. El sitio en staging puede comportarse de forma diferente al sitio en producción — URLs diferentes, datos diferentes, configuración de servidor diferente. Idealmente, prueba tanto en staging como en producción (después del cambio) y compara ambos con la baseline.
Ignorar las páginas de bajo tráfico. La página "Quiénes somos" con 50 visitas al mes no es prioritaria para el negocio. Pero si está visualmente rota, es una señal de calidad negativa para cada visitante que la consulta — incluidos los prospectos que evalúan tu credibilidad. Las páginas de bajo tráfico son a menudo las primeras olvidadas y las últimas corregidas.
Olvidar los estados autenticados. Muchos sitios tienen una experiencia diferente para usuarios conectados y desconectados. Si solo pruebas el estado desconectado, te pierdes las regresiones del dashboard, el perfil, los ajustes — páginas que tus clientes existentes usan a diario.
Confiar únicamente en los comentarios de los usuarios. "Ya veremos si los usuarios reportan problemas" no es una estrategia de QA. Los usuarios no reportan problemas visuales sutiles — se van en silencio. Solo verás la consecuencia en las métricas de tasa de rebote y conversión, semanas después, cuando sea demasiado tarde para aislar la causa.
Checklist de prueba visual para una migración
Aquí tienes una checklist que puedes seguir para estructurar tu enfoque de prueba visual en tu próxima migración.
Antes de la migración:
- Listar todas las páginas y plantillas únicas del sitio
- Capturar las baselines en desktop y móvil para cada página
- Verificar que las capturas están completas y correctas
- Documentar los cambios intencionales esperados
- Identificar las zonas dinámicas a excluir de la comparación (fechas, contadores, contenido personalizado)
Durante la migración (staging):
- Capturar las mismas páginas en el nuevo sitio en staging
- Comparar con las baselines y clasificar las diferencias
- Corregir las regresiones identificadas
- Relanzar la comparación después de las correcciones
- Iterar hasta que solo queden los cambios intencionales
Después de la migración (producción):
- Capturar el sitio en producción en las horas siguientes al cambio
- Comparar con las baselines validadas en staging
- Verificar las páginas de bajo tráfico a menudo olvidadas
- Monitorizar visualmente durante dos semanas
- Actualizar las baselines definitivas para la vigilancia continua
FAQ
¿Cuánto tiempo antes de la migración hay que capturar la baseline?
Idealmente, captura la baseline una o dos semanas antes de la fecha prevista de migración. Esto te da tiempo para verificar que las capturas están completas y resolver los eventuales problemas de captura (páginas que requieren autenticación, contenido dinámico a estabilizar). Si tu sitio evoluciona frecuentemente, recaptura la baseline unos días antes del cambio para tener la referencia más fresca posible.
¿Cómo gestionar los cambios intencionales durante la comparación antes/después?
Documenta los cambios esperados antes de lanzar la comparación. Cuando analices los resultados, trata primero las diferencias inesperadas — son tus regresiones prioritarias. Los cambios intencionales pueden validarse en lote y servir para actualizar la baseline. Algunas herramientas como Delta-QA permiten excluir zonas específicas de la comparación para ignorar los elementos que cambian voluntariamente.
¿La prueba visual es suficiente para validar una migración?
No. La prueba visual cubre la integridad de la interfaz — lo que el usuario ve. Pero una migración también implica la verificación de las redirecciones 301, del SEO técnico (robots.txt, sitemap, etiquetas canonical, datos estructurados), de las funcionalidades aplicativas (formularios, pago, autenticación) y del rendimiento. La prueba visual es un pilar de la validación, no la validación completa.
¿Cuál es la diferencia entre una herramienta pixel diff y una herramienta estructural para probar una migración?
Una herramienta pixel diff superpone dos capturas de pantalla y señala los píxeles diferentes. Es sensible al renderizado de fuentes, al anti-aliasing y a las micro-variaciones — lo que genera muchos falsos positivos durante una migración donde el motor de renderizado cambia. Una herramienta estructural como Delta-QA compara las propiedades CSS calculadas (dimensiones, colores, posiciones). Detecta los verdaderos cambios de layout y estilo sin ser contaminada por las diferencias de renderizado cosméticas.
¿Cómo probar las páginas que requieren autenticación?
Conéctate a tu aplicación antes de capturar las baselines, luego permanece conectado durante toda la sesión de captura. Con una herramienta desktop como Delta-QA, navegas en tu aplicación normalmente — la autenticación se hace exactamente como un usuario real. Captura las páginas autenticadas como un recorrido: conexión, navegación al dashboard, perfil, ajustes.
¿Cuántas páginas hay que probar durante una migración?
Idealmente, todas las páginas con una plantilla única. Un sitio con 500 páginas pero 15 plantillas diferentes puede cubrirse eficazmente probando una muestra representativa de cada plantilla — como mínimo la página más visitada de cada tipo. Para sitios e-commerce, añade páginas de producto con características variadas (títulos largos/cortos, con/sin imágenes, con/sin promociones) para cubrir los casos límite de la plantilla.
Conclusión
Una migración es una inversión importante para tu empresa — en tiempo, presupuesto y riesgo. No verificar sistemáticamente el resultado visual de esta inversión es una elección que nada justifica cuando existen las herramientas para hacerlo de manera eficiente.
La prueba visual antes/después de una migración transforma un proceso basado en la esperanza ("debería estar bien") en un proceso basado en la evidencia ("aquí está exactamente lo que cambió, aquí está lo validado, aquí está lo que debe corregirse").
Tu próxima migración merece algo mejor que verificaciones manuales parciales y plegarias silenciosas.