Cambiarse a un servidor nuevo es sobre todo copiar con cuidado y esperar con paciencia, y los problemas que duelen rara vez están en el sitio web en sí. Están en lo que lo rodea: el correo que vivía en la cuenta de hosting anterior, una pasarela de pago que solo acepta solicitudes desde la dirección IP del servidor viejo, una tarea programada que nadie sabía que existía. Si piensa migrar un sitio web a un nuevo hosting, siga el orden de abajo y la mayoría de las sorpresas se convertirán en puntos de una lista de verificación.
Antes de migrar un sitio web a un nuevo hosting: haga un inventario
Una lista de verificación de migración de hosting empieza con lo que existe hoy, no con la copia:
- Dónde está cada pieza. El registrador del dominio, el proveedor de DNS, el hosting web y el correo suelen ser cuatro cuentas distintas. Anote qué empresa tiene cada una y quién tiene el acceso.
- Versiones de software: versión de PHP y extensiones, servidor de base de datos y su versión, servidor web y cualquier capa de caché.
- Bases de datos y sus tamaños, incluidas las de instalaciones antiguas que nadie recuerda.
- Tareas cron y otras tareas programadas: copias de seguridad, feeds, exportación de pedidos, precalentadores de caché.
- Correo electrónico. ¿Los buzones están en la misma cuenta de hosting? ¿El sitio envía correo desde el servidor local o mediante un servicio externo?
- Listas de IP permitidas. Pasarelas de pago, conexiones de envíos y ERP o API de socios que solo aceptan tráfico del servidor actual. El servidor nuevo tendrá una dirección de salida distinta.
Copia de archivos y bases de datos
Los archivos se mueven mejor con rsync sobre SSH, que se puede volver a ejecutar para copiar solo lo que cambió. Para MySQL y MariaDB, mysqldump con la opción --single-transaction toma una instantánea consistente de las tablas InnoDB sin bloquear el sitio mientras se ejecuta. En el servidor nuevo, importe el volcado y compare el número de filas de las tablas clave: pedidos, clientes, entradas.
Esté atento a los detalles que causan daños silenciosos:
- Juegos de caracteres. Una base de datos antigua en latin1 importada sin cuidado como utf8mb4 produce acentos y símbolos ilegibles. Revise el juego de caracteres y la collation antes y después.
- Saltos de versión. Pasar de MySQL a MariaDB, o a una versión principal más nueva, puede cambiar el comportamiento de algunas consultas y configuraciones. Ensaye con una copia.
- Rutas y URL fijas en los archivos de configuración. Si además cambia el dominio, WordPress necesita una búsqueda y reemplazo que entienda los datos serializados, como el que incluye WP-CLI.
Pruebe en el servidor nuevo mediante el archivo hosts
Antes de cualquier cambio de DNS, puede ver el sitio en el servidor nuevo desde su propia computadora. Agregue una línea al archivo hosts de su computadora que asocie el dominio con la dirección IP del servidor nuevo, y su navegador cargará la copia nueva mientras todos los demás siguen viendo la anterior. Inicie sesión, envíe formularios, haga un pedido de prueba, active un correo de restablecimiento de contraseña y lea los registros de errores del servidor nuevo.
Planifique con anticipación el certificado SSL después de la migración. Los certificados de Let's Encrypt y de autoridades similares se validan normalmente por HTTP, lo que solo funciona cuando el DNS ya apunta al servidor nuevo. Puede copiar el certificado existente para el cambio, validar mediante un registro DNS o emitir un certificado nuevo justo después del cambio final. Lo que debe evitar es que los visitantes lleguen al servidor nuevo antes de que haya un certificado válido. Este enfoque de probar primero es el núcleo de nuestro servicio de migración de hosting y bases de datos.
El cambio de DNS: TTL, servidores de nombres y propagación
Los resolvedores de todo el mundo guardan en caché las respuestas de DNS durante el tiempo que permita el TTL (tiempo de vida) de cada registro. Con un día o más de anticipación, reduzca el TTL del DNS de los registros que va a cambiar, como los registros A del dominio y de www, a unos pocos minutos. Espere al menos tanto como duraba el TTL anterior, para que el valor corto sea el que todos tienen en caché. El día del cambio, modifique los registros y la mayoría de los visitantes lo notará en minutos.
Lo que la gente llama propagación de DNS es en realidad el vencimiento de respuestas antiguas en caché. Por eso cambiar registros en el mismo proveedor de DNS es rápido, mientras que decidir cambiar los servidores de nombres al mismo tiempo es más lento: la delegación del dominio se guarda en caché en los servidores del dominio de nivel superior, a menudo hasta por dos días. Si también debe cambiar el proveedor de DNS, copie primero todos los registros (MX, los registros TXT de SPF, DKIM y DMARC, registros de verificación y subdominios) y cambie los servidores de nombres en un día distinto al del cambio de servidor.
Cómo mover un sitio web sin perder el correo
Si el correo está alojado en otro lugar, como Microsoft 365 o Google Workspace, deje los registros MX intactos y el correo no notará el cambio. Si los buzones están en la cuenta de hosting anterior, necesitan su propia migración, y el cambio de MX debe hacerse solo después de copiarlos. Nuestra migración de correo electrónico a Microsoft 365 o Google Workspace se ocupa de eso, y un cambio de hosting suele ser el momento ideal para separar el correo del servidor web.
Después del cambio: migrar un sitio web a un nuevo hosting
- En tiendas y sitios de membresía, pause brevemente los pedidos nuevos, haga una última sincronización de la base de datos y luego cambie el DNS, para que no se escriba nada en el servidor viejo después de la última copia.
- Vuelva a crear las tareas cron en el servidor nuevo y desactívelas en el viejo, o los clientes podrían recibir cada correo programado por duplicado.
- Configure copias de seguridad y monitoreo en el servidor nuevo; no viajan con los archivos.
- Vigile el registro de accesos del servidor viejo. Cuando los únicos visitantes que queden sean bots, el cambio está completo.
- Conserve el hosting anterior una o dos semanas antes de cancelarlo, por si aparece un archivo o un buzón olvidado.
Preguntas frecuentes: migrar un sitio web a un nuevo hosting
¿Cuánto tarda la propagación de DNS?
En los cambios de registros preparados con un TTL corto, minutos para la mayoría de los visitantes. En los cambios de servidores de nombres, calcule hasta uno o dos días, porque la delegación se guarda en caché en los servidores del registro.
¿Se puede mover un sitio web sin tiempo de inactividad?
En sitios informativos y blogs, sí: ambos servidores sirven el mismo contenido mientras cambia el DNS. Las tiendas necesitan una breve pausa en los pedidos nuevos durante la sincronización final, que conviene programar en la hora más tranquila de la semana.
¿Debemos cambiar también el hosting del DNS al mismo tiempo?
Mejor no. Cambie una cosa a la vez: primero el servidor y, cuando todo esté estable, el proveedor de DNS o el registrador.
¿Cambiar de hosting arreglará un sitio lento?
Solo si el servidor es el cuello de botella. Si el servidor responde rápido pero las páginas cargan lento, la causa suele ser el tema, las imágenes o los plugins, y un servidor nuevo por sí solo no ayudará. Mida primero.
¿Va a mover un sitio WordPress, WooCommerce, Magento o Joomla, o una cuenta completa de cPanel a un servidor en la nube? Nuestro servicio de migración de sitios web y bases de datos incluye la copia, la revisión de las bases de datos, la sincronización final y el cambio de DNS. Cuéntenos dónde está alojado el sitio ahora, adónde va y dónde se administran el DNS y el correo, y planificaremos la migración con usted.
