¿Cambias de hosting? Migramos tu web gratis

La migración, en el orden en que se hace

Una migración rara vez falla por la técnica: falla por el orden. El TTL que se baja después del cambio, el MX que se modifica antes de haber creado los buzones, el contrato antiguo cancelado antes de haber leído los registros de error — cada una de esas inversiones cuesta medio día. Esta es la secuencia completa, del primer inventario hasta la cancelación.

Las referencias en días valen para un sitio o un servidor normal. Una tienda en plena temporada, o un parque de varias decenas de buzones, obliga a estirar estas etapas, no a saltárselas.

1. D-7 — Inventariar lo que realmente funciona. Los sitios y sus dominios, la versión de PHP en uso, las bases y su motor, los buzones y su volumen, las tareas programadas, los certificados y su fecha de caducidad, y los servicios de terceros que conocen tu dirección IP actual (pasarela de pago, relé SMTP, webhooks). Esa lista, y no tu memoria, será el control final.
2. D-7 — Dimensionar el destino según el uso real, no según el plan que pagas hoy. Mide el espacio en disco ocupado, el tamaño de las bases, la memoria realmente consumida. Un sitio que cabe en 6 GB no necesita un plan de 200 GB porque el anterior lo anunciara.
3. D-5 — Abrir el nuevo hosting y montar la copia. Archivos y bases se transfieren una primera vez, completos, sin que cambie nada del lado público. Esa copia no necesita estar al segundo: sirve para comprobar que la aplicación arranca.
4. D-3 — Congelar los cambios en el servidor antiguo. Nada de publicar artículos, actualizar extensiones o retocar el tema hasta el cambio. Todo lo que se escriba a partir de ese punto habrá que resincronizarlo a mano.
5. D-2 — Bajar el TTL de los registros que van a cambiar, a 300 segundos. Esta etapa se hace al menos 48 horas antes del cambio, por la razón que explica la sección de DNS más abajo. Es la etapa que más a menudo se hace tarde, y la única que no tiene remedio.
6. D-1 — Probar la copia con su nombre de dominio real, sin tocar el DNS público: modifica el archivo hosts de tu equipo para que el dominio apunte a la nueva dirección IP. Verás exactamente lo que verán tus visitantes, incluidos enlaces absolutos y redirecciones.
7. D-1 — Preparar la zona DNS de destino sin publicarla. Anota los valores exactos de los registros A, AAAA, MX, SPF, DKIM, DMARC y CAA que vas a poner. Escribirlos por adelantado evita improvisarlos el día del cambio, cuando el sitio ya está a medio conmutar.
8. Día D — Resincronizar la diferencia. Una segunda pasada de copia transfiere solo lo que ha cambiado desde D-5, y luego un volcado de base fresco sustituye al anterior. Esa segunda pasada, corta, es la que define la verdadera ventana de indisponibilidad.
9. Día D — Publicar los nuevos registros DNS. Con un TTL de 300 segundos puesto dos días antes, el cambio es efectivo en minutos para la mayoría de visitantes, no en veinticuatro horas.
10. Día D — Recorrer las comprobaciones en el orden indicado más abajo. No marques nada de memoria: abre la lista y prueba de verdad.
11. D+1 — Subir el TTL a su valor habitual; 3600 segundos sirven en la mayoría de casos. Un TTL corto permanente multiplica sin motivo las consultas a tus servidores de nombres.
12. D+7 — Cancelar el contrato antiguo, no antes. Espera a haber recibido correo en los nuevos buzones, restaurado una copia de seguridad en el nuevo hosting y leído los registros de error. Una cancelación suele borrar los datos ese mismo día.

Qué se transfiere, y por qué medio

Un hosting no es un bloque único: es una pila de elementos que se mueven cada uno con su propia herramienta. Tratarlos por separado evita el error más común, que consiste en copiar los archivos y confiar en que el resto siga.

• Los archivos. rsync por SSH cuando ambos lados lo permiten, SFTP si no. Dos pasadas valen más que una: una completa mientras el sitio funciona, y otra justo antes del cambio que solo recoge las diferencias. Comprueba después que permisos, propietarios y enlaces simbólicos han sobrevivido — un FTP mal configurado los aplana sin avisar.
• Las bases de datos. mysqldump --single-transaction --quick para MySQL y MariaDB, pg_dump -Fc para PostgreSQL. Anota el juego de caracteres y la colación de la base de origen y crea la de destino con los mismos: ese detalle es el que convierte las tildes en caracteres ilegibles tras la importación.
• La copia de seguridad del panel. Si tu hosting actual se administra con un panel, su exportación integrada — archivos, bases, buzones y ajustes en un solo archivo — suele ser la vía más segura. Nuestros planes de hosting web incluyen el panel Plesk, que dispone de sus propias herramientas de copia y restauración.
• La imagen de disco, para un servidor entero. En un VPS o un servidor dedicado hay dos caminos: copiar el disco tal cual (imagen raw o qcow2, o copia bloque a bloque desde un sistema de rescate), o partir de un sistema limpio y volver a desplegar la aplicación encima. Si tu hosting actual no da acceso a la imagen de disco, el segundo camino es el único posible — y es de todos modos el que recomendamos para un sistema de varios años.
• Los certificados. No los muevas: un certificado Let's Encrypt se reemite en segundos en el nuevo servidor, una vez apuntado el dominio. Si pagas un certificado de validación extendida, exporta la clave privada antes de cancelar, o tendrás que volver a comprarlo.
• Los buzones de correo. Una sincronización IMAP copia los mensajes, el árbol de carpetas y el estado leído o no leído de un servidor a otro. Pásala dos veces, como con los archivos: una antes del cambio y otra después, para recuperar los mensajes llegados entre medias.
• Las tareas programadas y los servicios. Los cron, los temporizadores systemd, las colas y los procesos permanentes no aparecen en ninguna copia de seguridad del sitio. Cópialos a mano y comprueba luego que se ejecutan tras el cambio, no solo que están declarados.
• Los secretos. Claves SSH autorizadas, tokens de API, claves de cifrado de la aplicación, credenciales de servicios: viven a menudo fuera de la carpeta del sitio y se pierden en silencio. Una aplicación que arranca pero ya no descifra sus datos es casi siempre una clave que se quedó en el servidor antiguo.

El DNS: qué se prepara antes, qué conmuta el día D

El DNS es la parte de la migración que no controlas tú solo. Entre tu zona y tus visitantes hay resolutores que guardan en memoria la respuesta antigua durante exactamente el tiempo que les has anunciado. Ese tiempo se llama TTL, y es la única palanca de la que dispones para acortar el cambio.

De ahí la regla: el TTL se baja antes, nunca durante. Si hoy tu TTL vale 86400 segundos y lo pones a 300 la mañana del cambio, los resolutores que ya tienen el valor antiguo seguirán respetándolo veinticuatro horas. Bajándolo 48 horas antes, dejas que el valor antiguo caduque solo, y el cambio pasa a ser cuestión de minutos.

1. 48 horas antes: bajar el TTL a 300 segundos en todos los registros que vayas a modificar — como mínimo A y AAAA, más el MX y los CNAME asociados si el correo también se muda. El TTL se ajusta en la zona DNS, allí donde esa zona esté alojada: tu registrador, en la mayoría de los casos.
2. Anotar la zona actual antes de tocarla. Una consulta dig tudominio.es ANY, o una exportación de zona desde la interfaz, te da el estado de partida. Consérvalo: es tu punto de retorno si algo sale mal.
3. A y AAAA. El registro A lleva la dirección IPv4 del nuevo hosting, y AAAA su dirección IPv6 si la tiene. No olvides www ni los subdominios realmente en uso: un webmail, una api, una preproducción. Los que se olvidan son los que uno nunca visita.
4. MX: el registro que se olvida. Designa al servidor que recibe tu correo, y es independiente del que aloja el sitio. Si tu correo se queda donde está, no lo toques: es el error clásico del cambio «sustituimos todas las IP de la zona», que desvía el correo a un servidor que no lo conoce. Si el correo también se muda, cambia el MX solo cuando los buzones ya existan y estén sincronizados.
5. SPF. Es un registro TXT único que enumera los servidores autorizados a enviar correo en tu nombre. Si sigue designando al hosting antiguo, los mensajes salidos del nuevo acabarán en spam o rechazados. Añade el nuevo servidor antes del cambio, retira el antiguo cuando la migración esté confirmada — y mantén un solo registro SPF: dos se anulan entre sí.
6. DKIM. La firma la produce el servidor de envío y se verifica con una clave pública publicada en tu zona bajo un selector. Publica el selector del nuevo servidor antes de conmutar y deja el antiguo unos días: dos selectores conviven sin estorbarse, cosa que no ocurre con el SPF.
7. DMARC. Indica a los destinatarios qué hacer con los mensajes que fallan los controles anteriores. Durante una migración, quédate en p=none con una dirección de informes: observas sin romper nada y endureces la política cuando SPF y DKIM estén limpios por ambos lados.
8. CAA, si existe. Este registro lista las autoridades autorizadas a emitir un certificado para tu dominio. Si no menciona la que usa tu nuevo hosting, la emisión falla en silencio y el sitio se queda con un HTTPS inválido, sin mensaje de error claro en ninguna parte.
9. DNS inverso (PTR). No se configura en tu zona sino en la dirección IP, es decir en el hosting que la posee. Cuenta desde el momento en que tu servidor envía correo por sí mismo: sin un PTR coherente con el nombre anunciado, parte de los destinatarios rechaza el mensaje. En nuestro caso, el DNS inverso puede personalizarse bajo petición.

La indisponibilidad real, y cómo dejarla casi en cero

El corte que la mayoría teme — «mi web estará inaccesible durante la propagación DNS» — no existe si ambos hostings responden a la vez. Durante la propagación una parte de los visitantes llega al servidor antiguo y otra al nuevo, y los dos muestran el sitio. Nadie ve un error.

La ventana real está en otro sitio: es el momento en que el sitio sigue aceptando escrituras por un lado cuando la base ya ha sido exportada. Un pedido hecho durante esa ventana queda registrado en el servidor antiguo y nunca existirá en el nuevo. Reducir la indisponibilidad es, por tanto, reducir esa ventana de escritura — no pelearse con el DNS.

• Web corporativa o sitio estático: ningún corte. No se escribe nada del lado del servidor, la copia puede hacerse la víspera y el cambio no exige ninguna precaución especial.
• Sitio con base de datos: unos minutos. Se pone el sitio en solo lectura o en mantenimiento, se exporta la base, se importa y se conmuta. En un sitio normal la maniobra cabe en cinco a quince minutos, programados en hora valle.
• Tienda online: la misma ventana, pero anunciada. Avisa al equipo, elige un valle real — a menudo a primera hora — y después compara los últimos pedidos de ambos lados antes de dar por prescindible el servidor antiguo.
• Correo: sin corte, pero con periodo de solapamiento. Mientras el MX no se haya propagado en todas partes, siguen llegando mensajes al servidor antiguo. Conserva el acceso unos días y repite una sincronización IMAP tras el cambio: eso es lo que evita el mensaje perdido.
• Aplicación con cola o tareas diferidas: vacía la cola antes. Un trabajo en curso en el momento de la exportación se perderá o se repetirá dos veces. Detén los consumidores, deja que la cola se vacíe y exporta después.

Tras el cambio: las comprobaciones, en orden

Esta lista se recorre de arriba abajo el día del cambio. El orden no es decorativo: cada punto supone verificado el anterior, y un fallo en el punto 2 vuelve ininterpretables todos los siguientes.

1. La resolución DNS. Consulta un resolutor público y el de tu proveedor de acceso: ambos deben devolver la nueva dirección. Mientras no sea así, lo que ves en tu navegador no demuestra nada.
2. El sitio responde, desde la máquina correcta. curl -I https://tudominio.es debe devolver un código 200; en caso de duda, curl --resolve permite forzar la dirección y comparar ambos servidores en paralelo.
3. El certificado. Válido, con el nombre correcto y cubriendo también www. Cuenta unos minutos tras la propagación para una emisión automática; si pasa de una hora, ve a mirar el registro CAA.
4. Las redirecciones. HTTP hacia HTTPS, y www hacia el dominio desnudo o al revés — pero en un solo sentido, en 301 y no en 302, y sin cadenas de dos redirecciones seguidas.
5. Las páginas profundas. La portada funciona casi siempre. Abre cinco o seis URL internas tomadas al azar: ahí se ven las reglas de reescritura perdidas y los enlaces absolutos que siguen apuntando al dominio antiguo.
6. Los formularios. Envía un mensaje de prueba desde el formulario de contacto y comprueba que llega. Un formulario que muestra «gracias» sin enviar nada es el defecto post-migración más frecuente.
7. El pago, si lo hay. Un pedido de prueba en modo sandbox, hasta la confirmación y su email. Comprueba de paso que la pasarela no tenga una lista de IP autorizadas pendiente de actualizar.
8. El correo saliente. Envía un mensaje desde el sitio a una dirección externa, abre la cabecera del mensaje recibido y lee los resultados SPF y DKIM. Hace falta «pass» en ambos; si no, vuelve a la sección de DNS.
9. El correo entrante. Escribe desde fuera a una de las direcciones migradas y sigue vigilando el buzón antiguo unos días.
10. Las tareas programadas. Espera a que haya pasado una ejecución y comprueba su rastro, en lugar de conformarte con que la línea figure en la tabla de tareas.
11. Los registros de error. Léelos durante las primeras 48 horas. Una extensión que falta o una ruta absoluta escrita a fuego se ven ahí de inmediato, casi siempre antes de que alguien se queje.
12. Una primera copia de seguridad en el nuevo hosting. Hazla y restáurala una vez para comprobar que es utilizable. Es la condición que hay que cumplir antes de cancelar el contrato antiguo.

Los errores que cuestan un día entero

• El TTL bajado el mismo día. No sirve de nada: el valor antiguo, largo, ya está en caché. Parte de tus visitantes se queda en el servidor antiguo todo el día y tú buscas una avería que no existe.
• El MX sustituido por reflejo. Sustituir «todas las IP de la zona» se lleva el correo junto con el sitio. Si el correo no se muda, el MX no se toca.
• El SPF apuntando aún al servidor antiguo. El sitio funciona, los emails salen y nadie los recibe — o caen en spam. Es el defecto más difícil de diagnosticar a posteriori, porque nada falla de forma visible.
• El contrato antiguo cancelado demasiado pronto. La cancelación borra los datos, a menudo el mismo día, y se lleva con ellos los mensajes llegados tras el cambio y la única copia todavía fresca de los archivos.
• El certificado pedido antes de que el DNS apunte. La validación falla, el sitio se muestra con un aviso de seguridad y el navegador guarda el error en memoria. Espera a la propagación y pide después la emisión.
• El robots.txt de preproducción copiado tal cual. Un Disallow: / heredado del entorno de pruebas desindexa el sitio en pocos días. Vuelve a leer ese archivo justo después del cambio.
• La versión de PHP que cambia sin haberlo decidido. El nuevo hosting suele ofrecer una versión más reciente por defecto. Reproduce primero la versión de origen y actualiza después, con la migración ya hecha.
• La caché y el CDN olvidados. Si hay un CDN delante de tu sitio, no es el registro A público lo que hay que cambiar sino el origen declarado en el CDN. Y purga la caché tras el cambio, o seguirás sirviendo el sitio antiguo.
• Las listas de IP autorizadas en terceros. Pasarela de pago, relé SMTP, API de un socio, base de datos remota: todo lo que filtra por dirección IP debe conocer la nueva antes del cambio, no después.

Migrar un servidor no es migrar un sitio

Las dos operaciones comparten nombre y poco más. Migrar un sitio es mover archivos, una base y unos buzones a un hosting ya administrado: el sistema, las actualizaciones de seguridad y el panel vienen incluidos. Eso es lo que cubre la migración asumida por nosotros hacia nuestros planes de hosting web.

Migrar un servidor es reconstruir una máquina: sistema, paquetes, servicios, cortafuegos, usuarios, certificados, copias de seguridad. En un VPS KVM recibes una dirección IPv4 dedicada, acceso root por SSH y un panel con reinicio, reinstalación, instantáneas y consola. Esa consola cuenta el día del cambio: es lo que te permite recuperar el control si una regla del cortafuegos te cierra la puerta SSH.

Nuestro consejo, cuando la máquina de origen tiene varios años: no copies el disco, reconstruye. De lo contrario heredas ajustes cuya razón ya nadie conoce. Toma una instantánea justo antes de cada etapa delicada — no cuesta tiempo y convierte un error en una simple vuelta atrás. Para una infraestructura entera que mover, descríbenos lo que tienes en un presupuesto: planificamos la secuencia contigo en lugar de anunciar un plazo antes de haber visto la máquina.

El posicionamiento durante la migración

Cambiar de hosting manteniendo el mismo dominio y las mismas URL no tiene, en sí, ningún efecto sobre el posicionamiento: para un buscador solo cambia la dirección IP, y eso no es un criterio de clasificación. Las pérdidas observadas tras una migración vienen casi siempre de otra cosa.

• URL que cambian sin redirección. Si la estructura evoluciona al mismo tiempo que el hosting, prepara la tabla de correspondencias antes del cambio y sirve 301, no 302. Consérvalas doce meses como mínimo.
• Un bloqueo de indexación involuntario. robots.txt, cabecera X-Robots-Tag, etiqueta noindex heredada de un entorno de pruebas: comprueba las tres el mismo día.
• Un sitio más lento que antes. La caché de la aplicación y la compresión suelen tener que reactivarse en el nuevo hosting. Mide el tiempo de respuesta antes y después en lugar de suponerlo.
• Un sitemap roto. Comprueba que sigue accesible y actualizado, y deja que el buscador vuelva por su cuenta. El ritmo de rastreo se restablece en pocos días; no hay nada que forzar si las URL no se han movido.