Migración de servidor: cómo mover tu sitio web sin perder datos

La migración de servidor es el proceso planificado de trasladar los archivos de un sitio web, su base de datos, cuentas de correo, registros DNS y configuraciones de la aplicación desde el servidor actual a una nueva infraestructura. Para migrar un sitio web sin perder datos, el método más seguro es el siguiente: primero se realiza una copia de seguridad completa, después se prepara el nuevo servidor con las mismas versiones de software o versiones más recientes y compatibles, se transfieren archivos y base de datos, se prueba el sitio mediante el archivo hosts o una URL temporal, se cambia la resolución DNS con un TTL bajo y, tras la migración, se revisan logs, formularios, flujos de pago, entrega de correos y señales SEO.

Mover una web de servidor no es un simple “copiar y pegar”. En sitios WordPress, tiendas WooCommerce, proyectos Laravel, aplicaciones PHP a medida, medios digitales con mucho tráfico o empresas que dependen del correo corporativo, una migración mal ejecutada puede provocar pérdida de pedidos, caracteres especiales dañados, errores 500, avisos de SSL, interrupciones de email y caídas de visibilidad en buscadores. Por eso, toda migración debe hacerse con un plan claro, una lista de verificación técnica y un escenario de vuelta atrás por si algo no sale como se esperaba.

En esta guía veremos paso a paso cómo realizar un cambio de hosting o servidor de acuerdo con las expectativas de SEO y rendimiento de 2026. También repasaremos distintos escenarios como cPanel, Plesk, VPS, servidor cloud y migración manual; además, compartiremos recomendaciones prácticas sobre tiempos de DNS, alcance de la copia de seguridad, compatibilidad de bases de datos, instalación SSL y revisiones SEO posteriores al traslado.

¿Cuándo es necesario hacer una migración de servidor?

La necesidad de migrar un sitio web a un nuevo servidor suele aparecer por motivos de rendimiento, seguridad, coste o escalabilidad. Por ejemplo, una web corporativa con 5.000 visitas mensuales puede funcionar sin problemas en un hosting compartido, mientras que una tienda online con 20.000 visitas diarias puede empezar a sufrir límites de CPU, consultas lentas y timeouts en la página de pago. En ese punto conviene valorar un plan de hosting más potente, un VPS o una infraestructura en la nube.

Estas son señales habituales de que ha llegado el momento de plantear una migración:

• El tiempo de carga supera los 3 segundos y empeoran las métricas de Core Web Vitals.
• En el panel de hosting se alcanzan con frecuencia los límites de CPU, RAM, inodos o uso de disco.
• La web necesita versiones actualizadas de PHP, MySQL, MariaDB, Node.js, ionCube u otros componentes.
• Se repiten problemas con la renovación SSL, la entrega de correos o la gestión DNS.
• El proveedor actual se queda corto en soporte, copias de seguridad o nivel de seguridad.
• El tráfico aumenta de forma brusca durante campañas, anuncios, rebajas o temporadas clave.

Si tu sitio está creciendo y se acerca a los límites del plan actual, es mucho más seguro preparar una migración controlada que esperar a una crisis de rendimiento. Según tus necesidades, puedes comparar opciones como Paquetes de alojamiento web, Soluciones de servidor VPS o Hosting Corporativo para elegir una base técnica adecuada.

Preparación antes de migrar: la fase más crítica

La mayoría de migraciones con pérdida de datos no fracasan durante la transferencia, sino por una preparación insuficiente. Antes de empezar, hay que levantar un inventario del sitio actual, definir qué información se va a mover y detectar qué servicios son sensibles a cualquier interrupción.

1. Haz un inventario completo del sitio

El primer paso es crear un mapa técnico de la web. Deben anotarse el CMS o framework utilizado, la versión de PHP, el tipo de base de datos, el tamaño en disco, las cuentas de email, tareas cron, registros DNS, certificado SSL, redirecciones personalizadas e integraciones con terceros. Por ejemplo, en un sitio WordPress no basta con mover la carpeta wp-content; también hay que revisar reglas .htaccess, ajustes de wp-config.php, prefijos de tablas, plugins de caché y archivos multimedia.

En una tienda online, además, hay que comprobar la pasarela de pago, la integración logística, la sincronización de stock, la conexión con ERP, el servicio SMTP y las URL de webhooks. Cuando después de migrar no entran pedidos, muchas veces el problema no está en la transferencia de archivos, sino en una restricción de IP olvidada en una API o en una regla de seguridad asociada al servidor antiguo.

2. Realiza una copia de seguridad completa y verifícala

En una migración de servidor, hacer una copia de seguridad no es suficiente: también hay que confirmar que esa copia puede restaurarse. Un backup completo debe incluir estos elementos:

• Archivos del sitio web: public_html, carpetas de la aplicación, directorios de subida, temas y plugins.
• Bases de datos: MySQL, MariaDB, PostgreSQL u otras bases usadas por la aplicación.
• Datos de correo: buzones, redirecciones, filtros y respuestas automáticas.
• Registros DNS: A, AAAA, CNAME, MX, TXT, SPF, DKIM y DMARC.
• Configuraciones: .htaccess, nginx.conf, php.ini, cron jobs y archivos de entorno.
• Certificados SSL y reglas de seguridad específicas.

Como práctica recomendable, antes de migrar guarda al menos dos copias: una en el servidor actual y otra en una ubicación externa. En sitios grandes se puede usar rsync para archivos, mysqldump para bases de datos o las herramientas de backup del panel. En bases de datos de más de 10 GB, suele ser más seguro trabajar con copias comprimidas y divididas en partes que con un único dump enorme.

3. Reduce el TTL de DNS con antelación

Para que el cambio DNS se propague con rapidez, conviene reducir el TTL unas 24 horas antes de la migración. Si el TTL está en 14400 segundos, algunos usuarios pueden seguir llegando al servidor antiguo durante horas. Bajarlo a 300 segundos antes del traslado permite un cambio más controlado. Una vez completada la migración y verificado que todo funciona, el TTL puede volver a 3600 o 14400 segundos.

Una gestión ordenada del dominio y del DNS influye directamente en el éxito de la migración. Para configurar correctamente tu dominio y sus registros, puedes revisar las guías de Consulta de dominio y gestión de nombre de dominio.

Comparativa de métodos para migrar un servidor

No existe un único método ideal para todos los sitios. Una web corporativa pequeña puede moverse fácilmente desde un panel de control, mientras que una tienda online con mucho tráfico puede requerir sincronización progresiva y modo mantenimiento.

Al elegir la nueva infraestructura, fijarse solo en el espacio en disco puede ser engañoso. El número de PHP workers, núcleos de CPU, RAM, discos NVMe, frecuencia de backups, ubicación del centro de datos, soporte para LiteSpeed o Nginx, WAF y protección DDoS también determinan el rendimiento real. Por eso, cambiar al plan más barato sin un análisis de necesidades puede obligarte a hacer otra migración poco tiempo después.

Cómo hacer una migración de servidor paso a paso

Paso 1: Prepara el nuevo servidor

En el nuevo servidor deben instalarse el sistema operativo, servidor web, versión de PHP, servicio de base de datos y módulos necesarios. Para WordPress se recomiendan PHP 8.2 o 8.3, una versión reciente de MariaDB, OPcache y un valor de memory_limit adecuado. En frameworks como Laravel también hay que configurar Composer, cron, queue workers y permisos de storage. Si una extensión PHP que existía en el servidor antiguo no está disponible en el nuevo, después del traslado pueden aparecer pantallas en blanco o errores 500.

En el apartado de seguridad, conviene definir la política del puerto SSH, contraseñas fuertes, firewall, escaneo antimalware y actualizaciones automáticas. Es mucho más sencillo establecer una base segura cuando el nuevo servidor todavía está limpio que corregir problemas después de poner la web en producción. Si necesitas SSL, incluye obligatoriamente instalación de certificado SSL dentro del plan de migración.

Paso 2: Transfiere los archivos

Para mover los archivos puedes usar FTP, SFTP, SSH, rsync o la herramienta de copias del panel, según el tamaño del sitio. En webs pequeñas suele bastar con crear un archivo comprimido y descomprimirlo en el nuevo servidor. En proyectos grandes, lo recomendable es hacer una primera copia con rsync y repetir la sincronización justo antes del cambio DNS. Este método ahorra mucho tiempo en sitios donde la carpeta de uploads cambia constantemente.

Después de transferir los archivos, revisa los permisos. De forma general, las carpetas suelen funcionar con permisos 755 y los archivos con 644, aunque cada aplicación puede tener requisitos propios. Archivos sensibles como wp-config.php, .env o similares no deben quedar legibles para cualquiera. Asegúrate también de que se han copiado los archivos ocultos, como .htaccess, .user.ini y otros archivos de configuración que algunos clientes FTP pueden ocultar por defecto.

Paso 3: Migra la base de datos

La transferencia de la base de datos es una de las partes más delicadas para evitar pérdida de información. Primero se exporta un dump desde el servidor antiguo y después se crea la base de datos y el usuario correspondiente en el nuevo. Siempre que sea posible, conviene usar utf8mb4 como juego de caracteres. Para evitar problemas con acentos, eñes y caracteres especiales, hay que conservar la misma collation durante la exportación y la importación.

En sitios que generan datos en tiempo real, como WooCommerce, áreas de miembros o plataformas de reservas, es recomendable activar un modo mantenimiento durante la migración. Si no se hace, durante la propagación DNS algunos usuarios pueden escribir datos en el servidor antiguo y otros en el nuevo. Esto provoca inconsistencias en pedidos, comentarios, registros de formularios o altas de usuarios. En sitios críticos, el último dump de base de datos debe hacerse después de activar el modo mantenimiento.

Paso 4: Actualiza los archivos de configuración

El nombre de la base de datos, usuario, contraseña, host y rutas de archivo deben adaptarse al nuevo servidor. En WordPress se revisa wp-config.php; en Laravel, .env; y en aplicaciones a medida, config.php u otros archivos equivalentes. Si quedan rutas absolutas, IPs, ajustes SMTP o directorios de caché del servidor antiguo, la web puede abrir aparentemente bien, pero generar errores en segundo plano.

También deben ajustarse valores como PHP memory_limit, upload_max_filesize, post_max_size y max_execution_time según las necesidades de la aplicación. Por ejemplo, si un panel de administración sube imágenes de producto de 200 MB y el límite de subida queda en 32 MB, la migración parecerá correcta, pero la operativa diaria no podrá continuar con normalidad.

Paso 5: Prueba antes de cambiar el DNS

La práctica más segura consiste en probar el sitio en el nuevo servidor antes de modificar el DNS. Para ello puedes editar el archivo hosts de tu ordenador y asociar tu dominio con la nueva IP. Así, los visitantes seguirán viendo el servidor antiguo mientras tú pruebas el nuevo entorno usando el dominio real.

La lista de pruebas debería incluir estas comprobaciones:

• ¿Cargan correctamente la home, categorías, productos, blog y página de contacto?
• ¿Funcionan el envío de formularios, inicio de sesión, recuperación de contraseña y proceso de pago?
• ¿Se cargan sin errores las imágenes, CSS y archivos JavaScript?
• ¿El panel de administración se abre sin avisos ni errores?
• ¿El certificado SSL está emitido para el dominio correcto?
• ¿Existen errores 404, 500, mixed content o bucles de redirección?
• ¿robots.txt, sitemap.xml y etiquetas canonical son correctos?

Paso 6: Instala el certificado SSL

En una web moderna, el SSL no solo es seguridad: también es confianza del usuario y un requisito básico para SEO. Si cambias el DNS sin tener SSL preparado en el nuevo servidor, los usuarios pueden ver avisos de “sitio no seguro”. Por eso, el certificado debe dejarse listo justo antes del cambio o instalarse en paralelo a la propagación. Certificados gratuitos como Let’s Encrypt son suficientes para muchos sitios; en proyectos corporativos con pagos o requisitos de validación más estrictos, pueden elegirse opciones SSL de mayor nivel.

Después de instalar SSL, confirma que las URL HTTP redirigen a HTTPS con 301, que no hay errores de mixed content y que el sitemap contiene URLs HTTPS. Para ver productos y alternativas de instalación, puedes consultar certificados SSL.

Paso 7: Cambia los registros DNS

Cuando las pruebas se hayan completado correctamente, el registro A del dominio debe apuntar a la IP del nuevo servidor. Si el servicio de correo también se migra al mismo servidor, habrá que actualizar MX, SPF, DKIM y DMARC. Si el correo se mantiene en otro proveedor, no se deben tocar los registros MX. Uno de los errores más comunes es intentar mover solo la web, modificar accidentalmente los registros de email y cortar todo el tráfico de correo.

La propagación DNS suele completarse entre unos minutos y 24 horas. Si el TTL se redujo previamente, la mayoría de usuarios llegará al nuevo servidor en poco tiempo. Durante ese periodo, no apagues el servidor antiguo de inmediato. Mantenerlo disponible al menos 48 horas, y si es posible 72, es una práctica mucho más segura.

Paso 8: Haz la sincronización final y revisa los logs

Después del cambio DNS, hay que comprobar si se ha escrito algún dato nuevo en el servidor antiguo. Conviene comparar pedidos, formularios de contacto, registros de usuarios y comentarios. Los access logs y error logs del servidor web ayudan a entender qué IPs están enviando peticiones a cada servidor y si todavía queda tráfico llegando al entorno antiguo.

Durante las primeras 24 horas posteriores a la migración deben vigilarse errores 500, aumento de 404, consultas lentas, picos de CPU y colas de correo. Si no se hacen estas revisiones, la web puede parecer operativa, pero estar perdiendo conversiones o solicitudes importantes en segundo plano.

Checklist profesional para migrar una web sin perder datos

La siguiente lista cubre los puntos que más problemas generan en la práctica. Marcarla antes y después de la migración reduce de forma notable el riesgo del proceso.

• La migración se programó en una franja de bajo tráfico.
• Se realizó copia completa de archivos, base de datos, correo y DNS.
• Se comprobó que el backup puede abrirse y restaurarse.
• El TTL de DNS se redujo al menos 24 horas antes.
• El nuevo servidor se preparó con PHP, base de datos y módulos necesarios.
• Los archivos se transfirieron completos y se revisaron los permisos.
• Se validó la compatibilidad de charset y collation de la base de datos.
• Los archivos de configuración se actualizaron con los datos del nuevo servidor.
• Se probó el sitio mediante el archivo hosts antes de pasarlo a producción.
• Se instaló SSL y se comprobaron las redirecciones HTTPS.
• Los registros DNS A, AAAA, MX y TXT se actualizaron correctamente.
• El servidor antiguo se mantuvo activo al menos 48 horas.
• Se monitorizaron Google Search Console, Analytics y registros del servidor.

Comprobaciones posteriores para no perder SEO tras la migración

En teoría, una migración de servidor no debería afectar al SEO si la estructura de URLs se mantiene intacta. En la práctica, sin embargo, una web más lenta, errores 404, un robots.txt incorrecto, SSL incompleto o redirecciones mal configuradas pueden impactar en los rankings. Por eso, la revisión SEO posterior es tan importante como la migración técnica.

Revisión de URLs y redirecciones

Si al migrar no cambias la estructura de URLs, la necesidad de redirecciones 301 será mínima. Pero si al mismo tiempo cambias dominio, estructura de enlaces permanentes o carpetas, las URLs antiguas deben redirigirse a sus equivalentes nuevas mediante 301. Las redirecciones 302 temporales no son adecuadas para transferir señales SEO de forma permanente. Por ejemplo, si la antigua página /producto/abc pasa a /tienda/abc, debe existir una redirección uno a uno; enviar todas las URLs antiguas a la home empeora la experiencia de usuario y puede perjudicar el rendimiento orgánico.

Revisión de robots.txt y sitemap

Si durante las pruebas se bloqueó a los buscadores con una regla Disallow en robots.txt, esa restricción debe eliminarse al publicar. Este descuido es una de las causas clásicas de pérdida de indexación tras una migración. El sitemap debe incluir las nuevas URLs HTTPS y enviarse de nuevo desde Google Search Console.

Rendimiento y Core Web Vitals

Aunque el nuevo servidor sea más potente, una mala configuración de caché puede empeorar el rendimiento. LiteSpeed Cache, Redis, OPcache, CDN y optimización de imágenes deben configurarse con cuidado. Durante la primera semana conviene revisar PageSpeed Insights, Chrome UX Report y logs del servidor para detectar posibles empeoramientos en LCP, INP y CLS. Para mejorar el rendimiento de tu hosting, puedes apoyarte en los contenidos de Optimización de velocidad de WordPress.

Qué tener en cuenta al migrar el correo electrónico

En muchas migraciones, los archivos web se trasladan sin problema, pero el correo queda olvidado. Si los emails están alojados en el servidor actual, deben moverse buzones, contraseñas de usuarios, redirecciones y filtros. La sincronización IMAP es un método fiable para copiar mensajes desde el buzón antiguo al nuevo.

En DNS, el registro MX define el servidor de correo, SPF indica quién tiene permiso para enviar, DKIM firma los mensajes y DMARC establece la política del dominio. Si estos registros se configuran mal, los correos pueden acabar en spam o ser rechazados directamente. Después de la migración conviene enviar pruebas a cuentas de Gmail, Outlook y correo corporativo, y revisar las cabeceras del mensaje para comprobar autenticación y ruta de entrega.

Errores frecuentes en una migración de servidor

Los proyectos de migración exitosos tienen algo en común: previenen errores simples antes de que ocurran. Estos son algunos de los problemas más habituales:

• Migrar sin copia de seguridad o sin probar que el backup funciona.
• Cambiar la IP sin reducir antes el TTL de DNS.
• Apagar el servidor antiguo antes de que termine la propagación DNS.
• Importar mal el charset de la base de datos y romper acentos, eñes o caracteres especiales.
• Olvidar reglas de redirección en .htaccess o Nginx.
• Enviar tráfico HTTPS al nuevo servidor sin instalar SSL previamente.
• Actualizar de forma incorrecta los registros MX y TXT del correo.
• Dejar un plugin de caché apuntando a rutas del servidor antiguo.
• No revisar Search Console ni logs después de la migración.

En sitios con ventas en vivo, la migración no debería hacerse en horario laboral de máxima actividad, sino en el tramo con menor tráfico y menor volumen de pedidos. En grandes proyectos e-commerce, planificar una ventana de mantenimiento de 15 a 30 minutos evita inconsistencias de datos que podrían aparecer en segundo plano.

¿Cuándo conviene contratar soporte profesional de migración?

Una web sencilla de presentación puede migrarse manualmente, pero hay casos en los que contratar soporte profesional resulta más barato y seguro. Entrarían aquí tiendas online con alta facturación mensual, empresas con muchas cuentas de correo, portales con software a medida, medios con tráfico elevado y negocios que alojan datos sujetos a requisitos regulatorios.

Un servicio profesional de migración suele incluir análisis previo, copias de seguridad, entorno de pruebas, transferencia, cambio DNS, validación y monitorización. Así no solo se trasladan archivos: también se protege la continuidad del negocio. Si estás pensando en pasarte a la infraestructura de Hostragons, puedes revisar Soluciones de hosting Hostragons para valorar conjuntamente opciones de hosting, dominio y SSL según tus necesidades.

Conclusión: una migración planificada evita caídas y pérdida de datos

La migración de servidor no tiene por qué ser un proceso arriesgado si se planifica bien. La clave está en no saltarse los pasos esenciales: backup completo, preparación correcta del servidor, planificación del TTL DNS, entorno de pruebas, instalación SSL, revisión de correo y monitorización posterior. En sitios donde la base de datos cambia continuamente, la sincronización final y el modo mantenimiento son especialmente importantes.

En resumen, para migrar una web sin perder datos no conviene correr: verifica cada paso y no apagues el servidor antiguo demasiado pronto. Si quieres renovar tu infraestructura y ofrecer una experiencia web más rápida y segura, puedes revisar las soluciones de hosting, dominio y SSL de Hostragons y diseñar un plan de migración tranquilo, ordenado y bajo control.

Preguntas frecuentes

¿Cuánto tarda una migración de servidor?

Depende del tamaño y la complejidad del sitio. Un WordPress pequeño puede migrarse en 30-60 minutos, mientras que una gran tienda online o un proyecto corporativo con muchas cuentas de correo puede requerir entre 1 y 3 días incluyendo preparación, pruebas y propagación DNS.

¿Mi web se caerá durante la migración?

Con una buena planificación, la interrupción puede reducirse a unos minutos o incluso pasar desapercibida para los usuarios. Para lograrlo, hay que reducir el TTL con antelación, probar el nuevo servidor antes de publicar y mantener el servidor antiguo activo hasta que finalice la propagación DNS.

¿Cuál es el paso más importante para no perder datos?

El paso más importante es contar con una copia de seguridad completa y verificada. Deben respaldarse archivos, base de datos, correo y registros DNS; especialmente en sitios que generan pedidos o altas de usuarios, el último backup de base de datos debe hacerse después de activar el modo mantenimiento.

¿La migración de servidor afecta al posicionamiento SEO?

Si se conserva la estructura de URLs, la web carga rápido y SSL y redirecciones están bien configurados, la migración de servidor por sí sola no debería causar pérdida SEO. Sin embargo, errores 404, robots.txt mal configurado, servidor lento o redirecciones 301 incorrectas pueden afectar negativamente a los rankings.

¿También se migran las cuentas de correo con el servidor?

Si los correos están alojados en el hosting antiguo, deben migrarse por separado. Hay que revisar buzones, redirecciones, filtros y registros MX, SPF, DKIM y DMARC. Si el correo se mantiene en otro proveedor, no se deben modificar los registros MX.