Introducción
Cambiar el hosting de una página web es una de esas tareas que pocos propietarios de sitios abordan por gusto. Por lo general, se realiza por necesidad: el plan actual se queda corto en recursos, el soporte técnico no responde con la celeridad esperada, el tiempo de carga del servidor ha empeorado, o simplemente se ha encontrado una oferta mejor que promete un rendimiento superior a un coste más razonable.
Aunque el motivo sea lógico y la decisión esté tomada, la ejecución despierta un temor muy legítimo. Nadie quiere despertarse y descubrir que su tienda en línea ha estado inaccesible durante horas o que el posicionamiento en Google ha caído en picado por errores evitables. El corazón del problema radica en que no hablamos de mover un archivo, sino de trasladar todo un ecosistema: bases de datos, archivos multimedia, certificados de seguridad, configuraciones específicas del servidor y una serie de detalles técnicos que, si se pasan por alto, pueden convertir una migración rutinaria en un dolor de cabeza.
Este artículo está pensado para acompañarte en ese proceso, pero con una premisa fundamental: la seguridad de tus datos no es negociable. Aquí no encontrarás atajos que pongan en riesgo tu información, sino una guía metódica que te permitirá entender qué ocurre entre bastidores. Vamos a desglosar cada fase, desde la copia de seguridad completa hasta la verificación final y la actualización de los DNS, para que comprendas no solo el "cómo", sino el "porqué" de cada acción. Al final de esta lectura, tendrás el criterio necesario para realizar el cambio con la confianza de quien sabe que, si sigues los pasos correctos, la migración no solo será segura, sino prácticamente imperceptible para tus visitantes.
Qué es
Qué es migrar una página web a otro hosting
Migrar una página web a otro hosting es el proceso técnico mediante el cual se transfieren todos los archivos, bases de datos, configuraciones y recursos digitales de un servidor a otro distinto. Este cambio implica mucho más que mover un conjunto de carpetas: significa trasladar la totalidad del "cerebro" del sitio (base de datos), su "estructura física" (archivos HTML, CSS, JavaScript, imágenes y otros recursos) y sus "documentos de identidad" (configuraciones de dominio y DNS) a un nuevo entorno de alojamiento sin que el usuario final perciba interrupciones o pérdidas de información.
Cuando hablamos de migración, no nos referimos simplemente a copiar y pegar archivos. Un servidor de alojamiento funciona con una arquitectura específica: versiones de PHP, configuraciones de MySQL, módulos de Apache o Nginx, extensiones de seguridad y ajustes de memoria. Ignorar estas diferencias puede provocar que un sitio que funcionaba perfectamente en el hosting anterior se rompa al llegar al nuevo. Por eso, una migración real implica una auditoría previa del entorno actual, la contratación de un plan que cumpla al menos con los mismos requisitos técnicos, la transferencia íntegra de archivos con sus permisos correctos y una exportación completa de las bases de datos con sus tablas y datos relacionales.
Para entender la complejidad de este proceso, es útil diferenciar la migración de otros términos relacionados que a menudo se confunden con ella. La transferencia de dominio, por ejemplo, se refiere exclusivamente al cambio de registrador del nombre de dominio (pasar de GoDaddy a Namecheap, por ejemplo), pero no implica mover los archivos del sitio. El cambio de DNS, por otro lado, es simplemente la modificación de los servidores que resuelven la dirección IP del sitio y puede ser parte de una migración, pero no es la migración en sí. Finalmente, la copia de seguridad (backup) es una fotografía estática de los datos en un momento dado, mientras que la migración requiere que esa fotografía se restaure, se valide y se ajuste en un entorno nuevo.
Existen dos tipos principales de migración. La migración manual implica el uso de herramientas como FTP, cPanel o paneles de control similares, así como el contacto directo con la base de datos mediante phpMyAdmin. Este método ofrece control total sobre cada archivo transferido, lo que lo hace ideal para sitios con muchos plugins o configuraciones personalizadas. Sin embargo, requiere conocimientos técnicos avanzados y es propenso a errores humanos, especialmente cuando se pasan por alto archivos ocultos como `.htaccess` o `wp-config.php`. La migración mediante plugin o herramienta especializada, como los sistemas integrados que incluyen algunos hosts, automatiza el proceso. Estas herramientas son la opción recomendada para usuarios con sitios basados en WordPress o que no tienen experiencia técnica completa, aunque su principal limitación es que pueden fallar cuando el sitio es demasiado grande (con muchos gigabytes de datos) o cuando los archivos tienen estructuras muy personalizadas.
Un ejemplo concreto ayuda a visualizar el concepto. Supongamos que tienes una tienda en línea con 1.200 productos y 40.000 clientes registrados. Durante una migración, se deben trasladar las tablas de la base de datos donde se almacenan los pedidos completados, los carritos abandonados, los cupones activos y los registros de inventario. Si la migración se realiza incorrectamente, los pedidos históricos podrían asociarse al cliente equivocado o, peor aún, quedar desvinculados de sus datos. Un buen proceso de migración no solo transfiere esos datos, sino que verifica la integridad referencial entre tablas: que cada pedido siga conectado a su cliente, a su dirección de envío y a su método de pago.
El aspecto más importante que distingue una buena migración de una mala es la fase de validación y entrada en producción. Después de mover los archivos y la base de datos al nuevo servidor, se debe probar el sitio en un entorno provisional (como un subdominio en el nuevo hosting) antes de cambiar las DNS definitivas. Esto permite detectar problemas de compatibilidad, enlaces rotos internos, errores de SSL y rutas incorrectas antes de afectar al tráfico real. La migración culmina formalmente con el cambio de los servidores de nombres del dominio, un proceso que puede tardar entre 4 y 24 horas en propagarse globalmente, y que exige mantener activo el hosting antiguo durante al menos 48 horas para evitar tiempos muertos inevitables.
Entender el concepto de migración en toda su profundidad es el primer paso para planificar correctamente el proceso, evitar ficheros corruptos, registrar los datos que realmente importan y tomar decisiones informadas sobre el método a utilizar según el presupuesto, los recursos técnicos disponibles y el nivel de riesgo aceptable.
Aspectos importantes a evaluar
Aspectos importantes a evaluar antes de migrar tu web
Migrar de hosting no es simplemente copiar archivos de un ordenador a otro; es un proceso quirúrgico que, si se ejecuta mal, puede provocar una caída del sitio, pérdida de tráfico orgánico o una vulnerabilidad de seguridad. Antes de tocar un solo archivo, es imprescindible evaluar una serie de factores que determinarán si la mudanza es un éxito o un dolor de cabeza. No se trata solo de "cambiar de casa", sino de asegurarse de que la nueva casa tiene los cimientos, la electricidad y la fontanería que tu web necesita para funcionar.
El primer y más crítico de los factores es el entorno técnico (Stack) y las versiones de software. No todos los servidores son iguales. Si tu sitio está construido con PHP, debes verificar la versión exacta que utiliza tu aplicación. Si tu hosting actual ejecuta PHP 7.4 y el nuevo solo ofrece PHP 8.2 o superior, podrías enfrentarte a errores de compatibilidad con temas o plugins antiguos. Esto no es un capricho: una actualización forzada de PHP puede romper funciones críticas de una web corporativa que no se actualiza desde hace años. De igual manera, revisa la versión de MySQL o MariaDB. Las bases de datos exportadas desde versiones antiguas pueden no ser legibles en versiones muy nuevas sin ajustes de codificación (colaciones y juegos de caracteres). Antes de pagar nada, pregunta al nuevo proveedor si puedes instalar la versión de PHP que tu web necesita, o si está dispuesto a ayudarte a migrar el código para que sea compatible. Un buen hosting te ofrecerá un "selector de versiones de PHP" para que tú controles este parámetro.
En segundo lugar, evalúa los límites de recursos del plan (Cuotas), pero no como un simple número de marketing. Las cuotas de "disco duro" suelen ser engañosas. Lo que realmente define el rendimiento es el límite de inodos (número de archivos, no el peso en MB) y la CPU/RAM dedicada. Una tienda online con 1.500.000 archivos temporales de caché puede ocupar solo 10 GB, pero si el nuevo plan tiene un límite de 500.000 inodos, tu web se caerá. Evalúa tu situación actual: entra en tu panel de control (cPanel, Plesk, etc.) y revisa cuántos inodos consumes y cuál es el uso real de CPU en los picos (normalmente a las 2 de la tarde o 8 de la noche). Si tu web recibe un pico de 2.000 visitas simultáneas en una oferta, un plan "Start" de bajo costo en el nuevo hosting probablemente se saturará.
Otro aspecto crucial es la seguridad del correo electrónico (Reputación IP). La gente a menudo migra la web pero olvida que el servidor de correo saliente (SMTP) tiene una reputación. Si el nuevo hosting tiene una dirección IP que ha sido utilizada anteriormente para envío de spam (algo común en servidores baratos compartidos), tus correos llegarán a la carpeta de spam de tus clientes. Pregunta al nuevo proveedor si tienen una IP dedicada opcional para correo saliente o si los servidores tienen protocolos de calentamiento de IP. Esto no se puede arreglar con un plugin; depende de configuraciones de red y listas negras externas. Si dependes del correo transaccional (facturas, recuperación de contraseñas), este punto es literalmente vital para tu negocio.
No puedes ignorar la estructura de la base de datos. No es lo mismo migrar una web estática que un sitio dinámico con bases de datos pesadas. Un error común es intentar importar un archivo SQL de 2 GB desde phpMyAdmin. El nuevo hosting tendrá un límite de carga (upload_max_filesize) o un tiempo máximo de ejecución (max_execution_time) que truncará la copia, resultando en tablas incompletas. Evalúa si tu nueva empresa de hosting ofrece herramientas como "Importación SQL remota" o si necesitas dividir el archivo en partes más pequeñas. Algunos sitios con tablas muy grandes (como los logs de WooCommerce) deberían ser limpiados antes de la exportación, eliminando datos obsoletos para reducir la posibilidad de que el proceso falle.
La gestión del DNS y los tiempos de propagación son, quizás, la parte más delicada. Cambiar los nameservers (DNS) no es instantáneo. Necesitas saber cuál es tu TTL (Time To Live) actual en los registros DNS. Si tu TTL es de 86400 segundos (24 horas), deberías reducirlo a 300 segundos (5 minutos) al menos 48 horas antes de la migración. Si no haces este ajuste, cuando cambies los nameservers, algunos usuarios en el mundo seguirán viendo la web en el servidor viejo (donde ya no está la base de datos actualizada) y se encontrarán con errores de conexión. Evalúa también si tienes registros DNS complejos (como SPF, DKIM y DMARC). Si el nuevo hosting tiene una IP diferente, deberás actualizar la IP en el registro DKIM para que tus correos no se marquen como falsificados. Un experto no migra sin una hoja de ruta del DNS anotada.
Finalmente, la infraestructura de seguridad y backups. ¿Qué herramientas de firewall a nivel de servidor (como ModSecurity) ofrece el nuevo proveedor? ¿Tienen protección DDoS incluida de forma nativa? A menudo, en el hosting actual, la seguridad la ponía un plugin. En el nuevo, la seguridad debe estar en la capa del sistema operativo. Además, revisa la política de backups: no basta con que hagan copias de seguridad; pregunta cada cuánto tiempo las realizan (¿cada 6 horas?), dónde las almacenan (¿en otro centro de datos?) y si la restauración es un proceso automático o requiere un ticket de soporte que tarda 24 horas. Una copia de seguridad que tarda dos días en restaurarse es inútil para un ataque de ransomware.
Para visualizarlo, imagina que tu web es un vehículo. El hosting actual es un garaje de pueblo. El nuevo es un concesionario de lujo. Si tu coche es un diésel antiguo y el concesionario solo tiene aparcamientos subterráneos de gasolina (versiones de software incompatibles), el coche no arrancará aunque el sitio sea más bonito. Evaluar estos factores técnicos no es paranoia; es el protocolo estándar para garantizar que la URL que el usuario teclea en el navegador devuelva la misma experiencia, pero con mayor velocidad y fiabilidad. Tómate el tiempo para pedir una "prueba de staging" al nuevo proveedor antes de mover el dominio. Todos estos criterios se resumen en una sola pregunta: *¿Puede este nuevo servidor ejecutar mi código exacto sin modificaciones forzadas?* Si la respuesta no es un sí rotundo, sigue buscando.
Cómo funciona o cómo tomar una decisión
El proceso de migración paso a paso: del diagnóstico a la verificación final
Migrar un sitio web no es un acto único, sino un proceso compuesto por fases diferenciadas. Entender cada una de ellas y el orden correcto es lo que separa una transición sin fricciones de una pesadilla de tiempo de inactividad. No se trata solo de copiar archivos; se trata de replicar un entorno completo y asegurarse de que el nuevo hogar del sitio funcione de manera idéntica (o mejor) que el anterior.
Vamos a desglosar el proceso en cuatro fases críticas que debes seguir de forma secuencial.
Fase 1: La auditoría y el mapeo del origen
Antes de tocar absolutamente nada, necesitas saber con exactitud qué compone tu sitio. Una migración falla a menudo porque se olvida un elemento periférico, como un certificado SSL de un subdominio o una base de datos secundaria usada por un plugin de foro. Esta fase es puramente de inventario.
- Inventario de archivos: Accede a tu hosting actual mediante FTP (o el administrador de archivos del panel) y descarga una copia completa de la carpeta `public_html` (o `www`). No la modifiques aún; solo es para inspeccionar el peso total, la estructura de carpetas y el tamaño de las subcarpetas críticas (como `wp-content` en WordPress). Esto te dará una idea del tiempo que tomará la transferencia.
- Inventario de bases de datos: Desde phpMyAdmin o el panel de control (cPanel, Plesk), identifica todas las bases de datos vinculadas al sitio. Anota el nombre de la base de datos y el usuario asignado a la misma. Necesitarás estos credenciales para la configuración posterior.
- Mapeo de dependencias: Revisa tu correo electrónico (si el hosting lo gestiona), las tareas cron programadas (en cPanel suelen estar en "Cron Jobs" o "Tareas Programadas") y los registros DNS (como el subdominio `mail.tudominio.com`). Una lista de verificación simple aquí puede ser tan útil como: "Sitio web", "Base de datos", "Correo", "Cron Jobs" y "Subdominios".
Cuando la gente piensa en migrar, imagina copiar archivos y listo. El error más común es ignorar el entorno del servidor. Tu sitio no solo necesita los archivos; necesita las extensiones de PHP, versiones de MySQL y configuraciones específicas que tu web usa.
La regla de oro es recrear el entorno, no solo el contenido.
- Elige un hosting nuevo que ya tenga preinstalado PHP 8.x (o la versión que tu CMS requiera) y MySQL 5.7+ o MariaDB.
- Una vez contratado el nuevo servicio, en lugar de subir los archivos inmediatamente, sube primero los archivos con la configuración de desarrollo o provisional. Esto significa que, antes de cambiar los DNS, tendrás el sitio funcionando en una URL temporal (como `server.ip.address/~tuusuario` o un subdominio asignado por el hosting).
- Este paso "seco" es crucial. Al cargar los archivos y la base de datos, podrás ver si el sitio tira errores (como incompatibilidad de extensiones de PHP) sin que los usuarios finales se vean afectados. Si tu web es de WooCommerce, por ejemplo, notarás rápidamente un error fatal si el nuevo servidor no tiene la extensión `intl` o `bcmath` habilitadas.
Esta es la parte más delicada. No se trata solo de exportar una base de datos e importarla, sino de hacerlo de forma segura para no perder transacciones o comentarios recientes.
- Exportación segura: Desde phpMyAdmin, exporta la base de datos en formato `.sql`. No uses el modo "rápido"; usa "Personalizado" y selecciona "Desactivar comprobaciones de claves foráneas" (SET FOREIGN_KEY_CHECKS=0) al inicio y al final del archivo. Esto evitará errores comunes de integridad referencial al importar en el destino.
- Importación y verificación de prefijos: Importa el archivo `.sql` en la nueva base de datos. Después, verifica el prefijo de las tablas (por ejemplo, `wp_` para WordPress). Esto es un punto de fallo común si estabas usando un prefijo personalizado como `miweb_` y el nuevo CMS asume `wp_`.
- El factor tiempo: Si tu sitio recibe pedidos o comentarios constantes, la copia que hiciste en la Fase 1 ya está desactualizada. La solución es un "modo de mantenimiento" temporal. Activa un plugin de mantenimiento o una página estática de "en obras" en el sitio original mientras realizas la transferencia final (en las últimas horas antes del cambio DNS). Esto congela la base de datos actual durante unos minutos, permitiéndote exportar una copia 100% limpia y sin pérdidas entre el momento de la copia y la activación.
Aquí es donde muchos se estancan. No tienes que mover toda tu web cambiando los DNS inmediatamente. Existen dos enfoques reales:
- La migración por DNS (estándar): Consiste en subir todo al nuevo hosting, verificar su funcionamiento en la URL temporal, y luego ir al registrador de dominios y cambiar los registros `A` y `www` (apuntando a la IP del nuevo servidor). Después, esperar la propagación (de 1 a 48 horas). Este método es el más limpio porque el nuevo sitio es una réplica exacta verificada previamente en su propio entorno.
- La migración por modificación de hosts local (pre-test): Si necesitas estar 100% seguro antes de dar el salto, puedes editar el archivo `hosts` de tu ordenador (en Windows: `C:\Windows\System32\drivers\etc\hosts`). Añades una línea con la IP del nuevo servidor y tu dominio (`IP_NUEVO tudominio.com`). Así, solo *tu* navegador verá la nueva web apuntando al nuevo hosting, mientras que el resto del mundo ve la antigua. Podrás navegar, hacer pedidos de prueba y probar plugins sin que el dominio público cambie.
Independientemente del método elegido, una vez que el nuevo hosting esté activo, debes reemplazar las URLs antiguas por las nuevas. No es tan simple como buscar y reemplazar en el editor de texto. Si tu sitio tiene URLs serializadas (común en opciones de WooCommerce o menús en WordPress), un reemplazo directo puede corromper la base de datos.
La forma más segura es usar un script SQL bien formulado (como el conocido `WP-CLI search-replace`, si dispones de acceso SSH) o el método que tu CMS ofrezca. Un error común es olvidar actualizar la URL en el archivo de configuración (`wp-config.php` para WordPress o `configuration.php` para Joomla), además de las que están dentro de la base de datos. Si no actualizas ambas, verás una página en blanco o un bucle de redireccionamiento.
Verificación final estructurada
Antes de celebrar, tu última tarea es una auditoría post-migración. No basta con que la web cargue. Debes verificar:
- Formularios: Envía un formulario de contacto y verifica que el correo llega. A menudo, el servidor SMTP del nuevo hosting tiene reglas de spam más estrictas.
- Permisos y enlaces: Haz clic en un enlace interno a un producto o post que haya sido indexado en Google. Si devuelve un 404, es que los enlaces permanentes no se regeneraron (ve a Ajustes > Enlaces permanentes y pulsa "Guardar" para forzar la reescritura).
- Cron de respaldo: Si no se ha movido el cron, los respaldos automáticos dejarán de ejecutarse.
Ventajas y limitaciones
Ventajas y limitaciones: qué ganas y qué debes vigilar al migrar de hosting
Migrar de hosting no es un simple cambio de domicilio digital. Cuando se ejecuta correctamente, esta operación tiene un impacto profundo en el rendimiento, la seguridad y la operativa diaria de tu proyecto. Sin embargo, para que el resultado sea positivo, necesitas conocer tanto los beneficios tangibles como los riesgos que aparecen cuando el proceso se subestima.
Las fortalezas reales de una migración bien ejecutada
La razón más común para cambiar de proveedor es la insatisfacción con el rendimiento actual. Si tu web recibe picos de tráfico estacionales (por ejemplo, una tienda online durante el Black Friday) y el servidor actual no responde, estás perdiendo ventas. Un hosting nuevo con mejores recursos (más RAM, CPU o almacenamiento SSD/NVMe) reduce drásticamente el tiempo de carga. En términos prácticos, pasar de un tiempo de respuesta de 2 segundos a 800 milisegundos no solo mejora la experiencia del usuario, sino que influye directamente en el posicionamiento SEO, ya que Google penaliza las páginas lentas.
Otra ventaja crucial es la seguridad. Los servidores antiguos suelen quedar obsoletos en sus versiones de PHP o bases de datos, lo que los convierte en objetivos fáciles para malware. Al migrar a un proveedor moderno, te beneficias de protocolos de seguridad actualizados, firewalls perimetrales y copias de seguridad automáticas diarias. Esto no es un extra menor: si tu web anterior fue hackeada, la migración te permite empezar de cero con un entorno limpio y parcheado.
La escalabilidad es quizás el beneficio más estratégico. Un plan de hosting básico tiene límites físicos. Migrar a una infraestructura que permita escalar verticalmente (aumentar recursos sin cambiar de servidor) o horizontalmente (añadir más servidores) te da margen para crecer sin fricciones. Por ejemplo, si tienes un blog que empieza a recibir 50,000 visitas mensuales, un hosting compartido colapsará. Un VPS o un servidor cloud te permite ajustar recursos según la demanda, pagando solo por lo que usas.
Además, una migración es una oportunidad perfecta para auditar tu proyecto. Mientras exportas la base de datos y los archivos, te ves obligado a revisar qué plugins, temas o archivos obsoletos ya no utilizas. Este "limpieza forzada" suele traducirse en una web más ligera y fácil de mantener.
Las limitaciones y riesgos que no debes ignorar
Ningún proceso de migración es perfecto, y la principal limitación es el tiempo de inactividad. Aunque con técnicas avanzadas (como la clonación en caliente) puedes reducir el corte a minutos, siempre existe el riesgo de que el DNS (el sistema que traduce tu dominio a la IP del servidor) tarde en propagarse. Durante ese periodo, algunos usuarios podrán ver la web nueva y otros la antigua. Para mitigar esto, es recomendable realizar la migración en horas de bajo tráfico y mantener el hosting anterior activo al menos 48 horas después del cambio.
Otro aspecto delicado es el riesgo de pérdida de datos. Si durante la exportación de la base de datos (especialmente en grandes volúmenes de registros) se produce un corte en la conexión, los datos pueden quedar corruptos o incompletos. Esto es especialmente crítico si tu web tiene una tienda online con pedidos o una comunidad con usuarios registrados. No basta con hacer una copia de seguridad; debes verificar la integridad de los archivos descargados comparando tamaños y ejecutando consultas de prueba en el destino antes de cambiar los DNS.
La curva de aprendizaje es otra limitación práctica. Si migras de un hosting compartido con cPanel a un VPS sin panel de control, el cambio en la gestión puede ser abrumador. De repente, necesitas configurar servidores web (Nginx o Apache), gestionar certificados SSL manualmente y ajustar archivos de configuración. Esto no es viable para todos los perfiles. Si no tienes conocimientos técnicos, te verás obligado a pagar por un servicio de migración gestionada, lo que añade un coste extra al proceso.
Finalmente, está el riesgo de errores de configuración. Cambiar de servidor implica ajustar rutas absolutas de archivos, permisos de carpetas y parámetros de conexión a la base de datos en el archivo de configuración (como `wp-config.php` en WordPress). Un pequeño error en la ruta de una imagen o en la cadena de conexión provocará errores 404 o pantallas blancas. Por eso es imprescindible probar la web en el nuevo servidor mediante un acceso provisional (como editar el archivo `hosts` de tu ordenador) antes de cortar el tráfico.
En resumen, la migración es un proceso de alto valor siempre que lo abordes con un plan claro de backup, un esquema de pruebas y una ventana de mantenimiento definida. Las ventajas en velocidad, seguridad y capacidad de crecimiento superan con creces a las limitaciones, siempre que no improvises y tengas preparado un plan de reversión por si algo falla.
Errores comunes
Errores comunes que convierten una migración en una pesadilla
La migración de hosting es un proceso crítico. No es simplemente copiar archivos de un sitio a otro; implica coordinar datos, configuraciones y DNS. Conocer los errores más frecuentes te permitirá anticiparte y proteger tu proyecto. A continuación, analizamos los fallos que más cuestan caros y cómo evitar caer en ellos.
1. Subestimar el tiempo de propagación del DNS (y confundirlo con un error)
El error más común no es técnico, sino de frustración. Después de mover los archivos y actualizar los servidores de nombres (nameservers), el tráfico comienza a migrar de forma progresiva. Este proceso, llamado propagación de DNS, puede tardar entre 24 y 72 horas (incluso más en redes corporativas).
El error ocurre cuando, durante la propagación, visualizas tu web desde tu red local o desde un dispositivo con caché y crees que "algo está roto". Terminas modificando archivos en el hosting antiguo, creando un conflicto de versiones. La solución es sencilla: durante este periodo, evita tomar decisiones basadas en lo que ves desde un único dispositivo. Utiliza herramientas online como `dnschecker.org` para verificar el estado global. No edites ni el hosting viejo ni el nuevo durante al menos 48 horas para evitar divergencias de contenido.
2. Mover el sitio, pero olvidar los servicios asociados (Email y Bases de Datos)
Muchos usuarios se centran en los archivos del sitio web y olvidan que el correo electrónico asociado al dominio (tus cuentas `@tudominio.com`) y las bases de datos dinámicas son dos entidades separadas.
Migrar solo los archivos sin exportar e importar correctamente la base de datos MySQL es un error fatal. Un CMS (como WordPress o Joomla) sin su base de datos es una carcasa vacía. Pero el fallo más silencioso es el correo.
El error: Te quedas en el hosting antiguo sin pensar en el correo. Si sigues usando las cuentas de email antiguas mientras el DNS ya apunta al nuevo servidor, es probable que los correos se pierdan o que las cuentas queden huérfanas. Cómo evitarlo: Antes de tocar el DNS, crea las mismas cuentas de correo en el nuevo hosting (con las mismas contraseñas) y exporta los buzones (archivos `.mbox` o `.eml`) desde el antiguo panel para importarlos después. No midas la migración solo por la web, sino por el flujo completo de datos: archivos, SQL y correos.
3. No coincidir las configuraciones de software y versiones
Copiar archivos es el primer paso, pero ignorar las diferencias de entorno entre servidores es un pasaporte directo al error 500.
Si tu web funciona en el hosting antiguo con PHP 7.4 y el nuevo servidor tiene PHP 8.2, es probable que algunos plugins, temas o scripts dejen de funcionar por incompatibilidad de funciones. El error común es no verificar estos requisitos antes de la migración.
Cómo evitarlo: Antes de cambiar los DNS, configura el nuevo servidor para que tenga exactamente las mismas versiones de PHP, MySQL y extensiones del servidor antiguo. Si tu panel (cPanel o Plesk) ofrece "Select PHP Version", ajústalo manualmente. Además, verifica los límites de memoria o `max_execution_time`; si no coinciden, obtendrás errores de tiempo de espera en funciones que antes eran instantáneas.
4. Copiar archivos manualmente mediante FTP y cortar el proceso
Usar un cliente FTP para arrastrar archivos es válido, pero falla cuando no respetas los tiempos de espera o interrumpes la transferencia accidentalmente.
Es común ver migraciones incompletas donde se han copiado solo el 90% de los archivos de la carpeta `wp-content/uploads`. Esto genera enlaces rotos e imágenes que cargan a medias.
El error: Depender de la "transferencia arrastrando" sin verificar que el número de archivos en el origen coincida con el destino. Cómo evitarlo: En lugar de FTP en bruto, usa el administrador de archivos del panel de control para crear un archivo comprimido (`.zip` o `.tar.gz`) de todo el directorio `public_html`. Descarga ese único archivo comprimido y súbelo al nuevo servidor para descomprimirlo allí. Esto reduce el margen de error a una sola transferencia de un archivo, y es mucho menos propenso a corrupción que miles de archivos individuales.
5. Cambiar el DNS antes de probar el nuevo entorno
Este es quizás el error más estratégico. Muchos usuarios completan la migración y acto seguido van a su registrador de dominios para cambiar los nameservers, sin haber comprobado si el sitio funciona en el nuevo servidor.
El error: Cambiar el tráfico a un servidor que aún tiene una base de datos no importada o archivos con permisos incorrectos, causando un periodo de inactividad innecesario.
Cómo evitarlo: Utiliza la técnica del "Archivo Hosts" (modificas temporalmente tu ordenador) o una herramienta de "Hosts Manager" para previsualizar el sitio en el nuevo hosting sin cambiar el DNS. Accede al sitio con el nuevo dominio, inicia sesión en el panel de administración, haz clic en todas las páginas principales y comprueba los formularios. Solo cuando el sitio funcione al 100% en el nuevo entorno, debes proceder a actualizar los nameservers. Una vez que la propagación termine, verifica y luego de 30 días con estabilidad, elimina el hosting antiguo.
Evitar estos cinco errores no garantiza una migración sin complicaciones, pero sí reduce el riesgo de pérdida de datos y minimiza el tiempo de inactividad a minutos en lugar de horas o días.
Preguntas frecuentes
¿Cuánto tiempo tarda la migración de un hosting a otro?
La duración de una migración varía según el tamaño de tu sitio web y la metodología empleada. Para un blog o una tienda online pequeña, el proceso de transferencia de archivos y base de datos suele completarse en un rango de 2 a 6 horas. Sin embargo, el tiempo total del servicio se extiende por la propagación del DNS (el cambio de "dirección" que conecta tu dominio con el nuevo servidor), que puede tardar entre 24 y 72 horas en estabilizarse globalmente. Durante este período, es crucial no desesperarse: el sitio puede verse distinto desde diferentes dispositivos, pero no debería sufrir caídas si seguiste los pasos de verificación previos. Un factor que acelera el proceso es si el hosting de origen y el de destino utilizan paneles de control como cPanel, ya que ofrecen herramientas de migración automática que minimizan el tiempo de descarga y carga de datos.
¿Qué pasa si mi web usa mucho PHP y MySQL, se perderán los datos si cambio de versión?
No, no se pierden datos, pero es un punto de fricción común. Al migrar, tu nuevo hosting puede tener una versión de PHP o MySQL más reciente. Aunque los datos (registros, usuarios, pedidos) permanecen intactos, a veces el código de aplicaciones antiguas (como una plataforma de foros o una versión desactualizada de WordPress) no es compatible con la nueva versión de PHP. Esto se manifiesta en errores de "página en blanco" o "error 500". La solución profesional es verificar los requisitos de tu aplicación antes de mover los archivos; si usas un CMS, actualiza el núcleo y los plugins en el hosting antiguo antes de la transferencia. Así, al llegar al nuevo servidor, el código ya está optimizado para funcionar con las versiones más modernas sin pérdida de información.
¿Debo informar a mi proveedor de hosting antes de realizar la migración?
No es obligatorio, pero es altamente recomendable. Avisar al hosting de origen te permite solicitar un "staging" (un entorno de prueba) o, si lo prefieres, que ellos mismos realicen una copia de seguridad completa en caliente sin cortar el servicio. Por otro lado, avisar al hosting de destino te da acceso al soporte técnico activo para que revisen las configuraciones de seguridad y te ayuden a subir archivos muy pesados si tu conexión a internet es lenta. En muchos casos, si la migración es de cPanel a cPanel, puedes generar un comprimido de la cuenta desde el propio panel y el hosting de destino lo descomprime automáticamente. Avisar a ambos proveedores evita bloqueos automáticos por "actividad inusual" al detectar múltiples conexiones FTP desde una IP diferente.
¿Qué sucede con los correos electrónicos (cuentas como [email protected]) durante la mudanza?
Este es el error más común y el que provoca pérdida de datos relativa. Al cambiar de hosting, los correos no se transfieren automáticamente. Si tu empresa depende del email, primero debes exportar los buzones existentes en formato EML o crear forwarders. Existen dos estrategias: 1) Redirigir el MX (servidor de correo) solo después de que el sitio web esté estable, manteniendo el correo en el servidor viejo durante unas semanas; 2) Migrar las cuentas de correo y los mensajes al nuevo panel (cPanel/WHM permite copiar la carpeta `mail` del usuario). Lo crítico es el tiempo de propagación: si mueves los registros MX mientras el DNS aún apunta al servidor viejo, perderás los mensajes que lleguen en esa ventana de horas. Lo más seguro es mantener el correo activo en el hosting antiguo hasta que el DNS esté 100% propagado y verificar que los clientes de email (Outlook/Outlook móvil) puedan conectarse al nuevo servidor sin perder la autenticación de contraseña.
¿Es necesario pagar por un servicio profesional de migración?
No, la mayoría de los hostings de gama media ofrecen "migración gratuita" como gancho, pero esta suele ser manual y solo mueve el sitio, no los correos ni las bases de datos complejas (como las configuraciones de Redis o caché en disco). Si tu web es un e-commerce o una aplicación a medida, pagar un servicio profesional es una inversión de seguridad: garantiza que la transferencia se haga sin cortes de servicio, que se reescriban las rutas absolutas dentro de los archivos de configuración y que se mantenga el valor SEO. Si tu proyecto es un blog o un sitio informativo, hacerlo tú mismo con un plugin de backup es totalmente viable y no genera costes extra, solo debes dedicar tiempo a leer las guías de verificación post-migración.
¿Cómo evito que Google penalice mi web tras el cambio de hosting?
Mientras mantengas el mismo dominio (no cambies de dominio, solo de servidor), no sufrirás penalizaciones. El error más grave es que el sitio quede caído durante más de 24 horas, porque Google interpreta la caída como un mal servicio y baja tu posicionamiento temporalmente. Para evitarlo, debes mantener activo el hosting viejo hasta que el nuevo esté completamente operativo. En lugar de eliminar la cuenta vieja al pasar los archivos, cambia el DNS a las 48 horas. Posteriormente, usa Google Search Console para verificar que la indexación sigue correcta y que no hay errores de "no encontrado" (404). Si tu web estaba subida con HTTP y el nuevo hosting trae HTTPS forzado, asegúrate de redirigir todo el tráfico mediante reglas 301 para no perder autoridad de enlaces.
Conclusión
Migrar una página web a otro hosting no debería ser un salto al vacío. Cuando termina el proceso, la sensación no debe ser "espero que todo funcione", sino "sé que todo está en su sitio". La diferencia entre ambas experiencias radica en un único factor: la verificación sistemática. Tras completar la transferencia de archivos y la base de datos, tu trabajo como administrador no termina; comienza la fase de validación. Esto implica comprobar el certificado SSL, revisar que los formularios envíen correos correctamente (un fallo habitual en cambios de servidor), y confirmar que las rutas absolutas de las imágenes no apunten a la antigua IP.
La recomendación práctica más valiosa aquí es no cancelar el servicio del hosting antiguo al menos durante 72 horas. Esto te permite comparar ambos entornos en tiempo real, revisar los registros de errores y solucionar conflictos de DNS sin la presión de una página caída. Si has exportado la base de datos desde phpMyAdmin, revisa que los prefijos de las tablas coincidan con los del nuevo servidor; un simple cambio en esta configuración puede volver inaccesible todo el panel de administración.
El verdadero éxito de la migración no se mide en el momento en que ves la web funcionando en el nuevo servidor, sino cuando pasa la prueba de uso real: navegar por cada enlace interno, hacer una compra de prueba o comentar en el blog. Si todo funciona, actualiza tu archivo de configuración de correo transaccional (SMTP) y avisa a tu proveedor de correo para evitar que tus mensajes terminen en spam tras el cambio de IP.
En definitiva, la metodología es simple: planifica, ejecuta con calma y verifica sin prisas. Si has seguido los pasos de esta guía, tu único riesgo residual será un tema de caché local, que se resolverá con un simple borrado de cookies. Confía en el proceso que has realizado, pero confirma cada detalle antes de dar por cerrada la tarea.