El falso éxito de una migración web

He visto decenas de migraciones que “salieron bien” en apariencia: no hubo errores visibles, el dominio apuntaba correctamente y el sitio cargaba sin caídas. Sin embargo, al cabo de unos días, el tráfico bajaba, el SEO se resentía o la web empezaba a ir más lenta. La causa casi nunca es un único fallo, sino una suma de pequeños errores invisibles que pasan desapercibidos cuando damos por hecho que “todo está bien”.

Una migración web no termina cuando cambias los DNS o copias los archivos. De hecho, es justo después cuando aparecen los problemas que separan una migración profesional de una chapuza silenciosa.

Errores invisibles que arruinan una migración aparentemente correcta

1. DNS propagados, pero TTL mal configurado

Uno de los errores más comunes es asumir que los DNS propagados equivalen a “migración completada”. El Time To Live (TTL) define cuánto tiempo se cachean los registros. Si antes de la migración tienes TTL altos (3600 segundos o más), los visitantes seguirán llegando al servidor antiguo durante horas. Eso genera comportamiento inconsistente, sobre todo si hay bases de datos activas o formularios.

Solución: antes de migrar, reduce los TTL a 300 segundos un día antes del cambio. Así podrás controlar mejor el tráfico y minimizar inconsistencias.

2. Archivos copiados, pero sin permisos seguros

Muchos paneles de hosting o scripts automáticos copian bien los archivos, pero no respetan los permisos del sistema original. Luego llegan los “error 500”, los problemas con cachés o sesiones que no se guardan. En servidores Linux, permisos demasiado restrictivos o permisivos (por ejemplo, 777 en carpetas sensibles) pueden romper funciones PHP o abrir vulnerabilidades.

Solución: tras copiar los archivos, revisa con find . -type f -perm 777 y find . -type d -perm 777 si algo quedó mal. Ajusta los permisos a 644 para archivos y 755 para directorios.

3. Base de datos importada, pero con colación incorrecta

He visto migraciones en las que el sitio parece funcionar, pero aparecen caracteres extraños (acentos, ñ, comillas invertidas…). Normalmente es culpa de haber importado la base de datos con una colación distinta: por ejemplo, pasar de utf8mb4_unicode_ci a latin1_swedish_ci. El resultado es un desastre de codificación silenciosa.

Solución: asegúrate de exportar la base de datos con --default-character-set=utf8mb4 y comprueba que el nuevo servidor usa la misma configuración. No confíes en lo que “parezca bien”.

4. Cron jobs y tareas programadas olvidadas

Muchos CMS y ecommerces dependen de tareas programadas (cron jobs) para limpiar cachés, enviar emails o actualizar inventarios. En migraciones “manuales” es habitual olvidarlas. Resultado: el sitio funciona, pero no se actualiza nada o el almacenamiento se llena de basura con el tiempo.

Solución: revisa siempre el crontab -l del servidor antiguo y replica las tareas. Si usas un panel (Plesk, cPanel, RunCloud, etc.), verifica que siguen programadas en la nueva cuenta.

5. Cachés incompatibles o mal configuradas

Al cambiar de servidor, cambian versiones de PHP, extensiones o sistemas de caché (APCu, Opcache, Redis). Una web puede funcionar, pero mucho más lenta porque las cachés ni se reactivaron ni son compatibles. Un WordPress, por ejemplo, puede quedarse sin object cache tras una migración de un hosting optimizado a otro plano más genérico.

Solución: vacía todas las cachés después de migrar (incluidas Cloudflare, LiteSpeed, Redis, Varnish…). Reconfigura los plugins de caché, comprueba compatibilidad con la versión de PHP y ejecuta pruebas de carga reales.

6. Cambios de entorno PHP

He visto sitios que parecían intactos, pero daban problemas intermitentes por versiones distintas de PHP o librerías. Un proyecto en Laravel, por ejemplo, puede depender de extensiones como intl o mbstring, que no siempre están activadas por defecto.

Solución: antes de migrar, exporta con php -m > modules.txt la lista de extensiones del servidor actual y compárala con la del nuevo. Evita sorpresas después.

7. Faltan subdominios o redirecciones

La atención se centra en el dominio principal, pero olvidamos los subdominios: cdn.tusitio.com, blog.tusitio.com o admin.tusitio.com. Si no se migran correctamente o no se actualizan las redirecciones 301, Google detecta URLs rotas y se pierde autoridad SEO.

Solución: genera un inventario de subdominios y revisa las redirecciones en el .htaccess o el panel DNS. Usa herramientas como Screaming Frog para localizar URLs con errores 404 o redirecciones incorrectas.

8. HTTPS y certificados SSL obsoletos

Algo muy típico: se migra la web y se copia todo, incluyendo la configuración HTTPS, pero el nuevo servidor no tiene el certificado SSL o éste caducó. El sitio carga, pero los navegadores lanzan alertas de seguridad o el contenido mixto (imágenes HTTP dentro de HTTPS) rompe la experiencia de usuario.

Solución: renueva el certificado en el nuevo hosting (Let’s Encrypt o SSL comercial). Luego pasa un análisis con Why No Padlock para comprobar enlaces inseguros.

9. Cambios en rendimiento y latencia

Aunque la migración “técnica” esté perfecta, la velocidad puede empeorar. La causa: el nuevo servidor está más lejos del público objetivo o usa un tipo de almacenamiento más lento (por ejemplo, pasar de NVMe a SSD SATA). Google PageSpeed no distingue si el hosting es barato o caro; solo mide el resultado.

Solución: ejecuta Pingdom o traceroute para comparar latencias y tiempos de respuesta. Si el salto es grande, plantéate usar CDN o mover la instancia a otra región.

10. Ficheros temporales y rutas absolutas

Otra fuente clásica de fallos invisibles: los CMS que usan rutas absolutas (por ejemplo, /home/usuario/domains/tudominio.com/) o variables de entorno definidas en archivos .env. Cuando cambian los paths del sistema, dejan de funcionar ciertas funciones. WordPress, Joomla o Laravel lo sufren con frecuencia.

Solución: revisa el archivo de configuración del CMS y actualiza todas las rutas absolutas. En WordPress, comprueba wp-config.php y la opción SITEURL en la base de datos.

11. Errores de SEO silenciosos

Una migración puede afectar al posicionamiento sin generar errores visibles. Por ejemplo, el sitemap queda desactualizado, las URLs cambian de estructura o las canonical siguen apuntando al antiguo dominio. Google no avisará al instante, pero en semanas notarás caídas en tráfico orgánico.

Solución: actualiza Search Console con la nueva propiedad, envía de nuevo el sitemap y monitoriza las impresiones en el informe de cobertura. No des por hecho que Google resolverá redirecciones de forma automática.

12. Políticas de caché del navegador y headers HTTP

Después de una migración, algunos sitios cargan versiones antiguas del CSS o JavaScript. Esto no es culpa del servidor, sino de los headers Cache-Control o Expires que no se ajustaron. La web se muestra desalineada o rota hasta que el usuario hace un hard refresh.

Solución: limpia el caché CDN y ajusta los headers del servidor para que los recursos estáticos se renueven correctamente en cada despliegue.

Cómo verificar una migración correctamente

Casi nadie dedica suficiente tiempo a la verificación post-migración. Es la parte más importante. Este es mi checklist básico que aplico tras cualquier migración:

  • Comprobar logs de error PHP y servidor durante 24 horas.
  • Ejecutar tests de carga con herramientas como ab o k6.
  • Monitorizar el rendimiento de la base de datos y caché (consulta lenta, errores de conexión, tamaño de logs).
  • Verificar redirecciones 301 y canonical tags.
  • Comprobar correo saliente (SMTP, SPF, DKIM y DMARC).
  • Analizar métricas de Core Web Vitals y TTFB en Google Search Console.

Una migración solo puede considerarse “correcta” cuando el nuevo entorno reproduce exactamente el comportamiento anterior, o lo mejora. Que cargue la página no basta.

Costes ocultos de una mala migración

Una migración mal ejecutada cuesta más de lo que parece. No solo en tiempo técnico, sino en reputación y rendimiento SEO. He visto tiendas online perder decenas de pedidos diarios por caídas intermitentes que nadie sabía rastrear hasta revisar DNS y cron jobs olvidados. También he encontrado agencias que, por no testear headers, tuvieron semanas con contenidos cacheados erróneos. No son errores de “programación”, son errores de proceso.

Si al migrar ves que “todo parece correcto” pero tu web va peor, no es casualidad. Lo invisible también se rompe. Por eso siempre vale la pena auditar cada capa: DNS, SSL, PHP, base de datos, cron, cachés y SEO técnico.

Conclusión práctica

Migrar una web no es solo mover archivos, es reproducir exactamente el entorno donde el proyecto vivía. Cuando se ignoran variables como versión de PHP, configuración de caché o estructura DNS, los fallos son silenciosos pero inevitables. Incluso migraciones “perfectas” pueden degradar rendimiento o SEO por ajustes mínimos que nadie revisó.

Mi consejo: usa una lista de comprobación antes y después de migrar. Documenta configuraciones y no des por hecho nada. Si no tienes claro qué hosting elegir para tu próximo proyecto o para una migración segura, te recomiendo revisar esta comparativa de los servidores web más baratos y fiables.