Un servidor más rápido no garantiza un sitio público más rápido. La migración puede cambiar la versión de PHP, el comportamiento de la caché, la configuración de la base de datos, la ruta DNS, el origen de la CDN y los trabajos programados. Una prueba cálida de la página de inicio inmediatamente después de la transición demuestra muy poco.
Compare condiciones equivalentes y verifique las funciones comerciales y la velocidad.
Preservar una línea de base significativa
Antes de la migración, pruebe las URL representativas de una sesión en frío cerrada: página de inicio, página de servicio, artículo, búsqueda sin caché, formulario y flujo de WooCommerce, si están presentes.
Registro:
- DNS y cadena de redireccionamiento;
- TTFB para caché impredecible;
- LCP y estabilidad del diseño;
- bytes transferidos y recuento de solicitudes;
- PHP/tiempo de base de datos para rutas dinámicas;
- encabezados de caché y estado de CDN.
Guarde versiones, extensiones PHP activas y configuraciones de hosting relevantes. No copie secretos en el informe.
Pruebe el nuevo host antes de la transición de DNS
Utilice el método de vista previa del host o una entrada de archivo de hosts local autorizada para que el dominio real llegue al nuevo servidor. El comportamiento de SSL y CDN puede diferir antes que el DNS público, así que identifique esas limitaciones.
Evite reemplazos temporales de URL dentro de la base de datos de WordPress si el dominio final se puede probar mediante el mapeo de host. Pueden crear problemas de contenido mixto y datos serializados.
Confirme que los robots y los controles de indexación sigan siendo apropiados para el entorno de prueba privado.
Coincidencia de condiciones de caché
Compare el éxito anterior con el nuevo y el fracaso anterior con el nuevo fracaso. Caliente cada página deliberadamente y luego registre las solicitudes repetidas. Pruebe también una purga y una primera regeneración.
Inspeccione los encabezados de respuesta para confirmar qué capa atendió la solicitud. Un host puede anunciar el caché del servidor que las cookies de WooCommerce omiten inesperadamente.
No almacene en caché el carrito, el pago o la cuenta para generar un número impresionante.
Verificar PHP, base de datos y caché de objetos
Verifique la versión de PHP, el controlador, la memoria, los trabajadores y las extensiones requeridas. Revise los registros en busca de obsolescencias o errores fatales que los visitantes no activen de inmediato.
Compare el tiempo de consulta de la base de datos y la latencia de conexión en solicitudes dinámicas. Confirme el conjunto de caracteres/clasificación de la tabla y el mantenimiento programado de la base de datos.
Si se migró Redis u otro caché persistente, verifique el aislamiento, la autenticación, el comportamiento de aciertos y el fallo elegante. Vacíe solo el caché del nuevo sitio a través de controles compatibles.
Pruebe la geografía y los medios de los visitantes
Un nuevo origen más cercano al administrador puede estar más alejado de los clientes. Pruebe desde regiones relevantes e inspeccione si la CDN está activa, almacena en caché archivos estáticos y los recupera desde el origen previsto.
Verifique imágenes, variantes WebP/AVIF, solicitudes de rango de video y encabezados de control de caché. Los módulos de servidor faltantes pueden hacer que el nuevo host proporcione originales de tamaño completo o tipos de contenido incorrectos.
Verifique el procesamiento de carga y el espacio libre del disco/inodo, no solo la velocidad de descarga.
Ejecute recorridos completos de aplicaciones
Envíe cada formulario y verifique la entrega. Pruebe inicio de sesión, restablecimiento de contraseña, búsqueda, páginas multilingües y tareas programadas.
Para WooCommerce, utilice pagos sandbox autorizados y confirme la persistencia del carrito, los impuestos, el envío, el stock, los correos electrónicos, los webhooks y el estado del pedido. Verifique las colas de cron y del Programador de acciones después de la transición.
El rendimiento no mejora si una devolución de llamada externa todavía apunta al servidor anterior.
Observar después de los cambios de DNS
Reduzca el TTL de DNS por adelantado solo cuando la política de cambios lo permita. Durante la propagación, supervise los hosts nuevos y antiguos; algunos visitantes pueden llegar a cualquiera de los dos.
Mantenga el entorno anterior intacto y sin conflictos durante una ventana de reversión acordada. Evite que dos sitios procesen de forma independiente cron, suscripciones o pedidos entrantes.
Después de la propagación, pruebe nuevamente la cadena SSL pública, las redirecciones canónicas y el caché.
Tomar la decisión de hospedaje a partir de evidencia
Compare medianas y muestras lentas en condiciones equivalentes. Observe las mejoras y regresiones por ruta. Un acierto en la caché de la página de inicio puede mejorar mientras que la cola de trabajadores de pago empeora.
Solicite una evaluación posterior a la migración cuando los resultados varíen según la región, los encabezados de la caché no estén claros o los flujos dinámicos se ralenticen. Compartir horarios de referencia y públicos; el acceso al hosting puede seguir después de que se acuerde el alcance y la reversión.