Sí, podés mover un sitio web a otro servidor después de publicarlo. Este proceso se denomina migración y no exige necesariamente cambiar el dominio, rediseñar la web ni empezar de cero. El objetivo es copiar los componentes necesarios, comprobarlos en el nuevo alojamiento y recién entonces dirigir el tráfico hacia el destino.
La dificultad depende de la tecnología utilizada, el tamaño del sitio, la cantidad de correo y los accesos disponibles. Una página estática puede trasladarse copiando archivos; una tienda o un CMS necesita además bases de datos, configuraciones y una planificación para no perder pedidos o cambios recientes.
El dominio y el hosting son servicios diferentes
El dominio es el nombre que utilizan los visitantes, mientras que el hosting contiene la web, las bases de datos y, en muchos casos, el correo. Podés mantener el dominio registrado con el mismo proveedor y apuntarlo hacia otro servidor mediante sus registros DNS o sus nameservers.
Por lo tanto, migrar el sitio no obliga a transferir el registro del dominio. Tampoco cambiar el registrador mueve automáticamente los archivos. Comprender esta separación evita cancelar un servicio antes de haber trasladado la información correcta.
Qué elementos pueden formar parte de una migración
Antes de copiar, prepará un inventario. Según el proyecto, puede incluir:
- Archivos públicos, archivos ocultos y directorios privados de la aplicación.
- Bases de datos, usuarios y permisos asociados.
- Configuración del CMS, versión de PHP y extensiones necesarias.
- Cuentas de correo, mensajes, reenviadores, filtros y respuestas automáticas.
- Subdominios, dominios adicionales y redirecciones.
- Certificados, tareas programadas y reglas especiales del servidor.
- Registros DNS personalizados para web, correo y servicios externos.
No todos estos componentes deben mudarse juntos. Por ejemplo, la web puede cambiar de servidor mientras el correo continúa en Microsoft 365, Google Workspace u otro proveedor. Esa decisión debe tomarse antes de modificar DNS.
Comprobar si la plataforma es portable
WordPress, Joomla, PrestaShop y otras aplicaciones instaladas en un hosting convencional suelen poder trasladarse si se dispone de archivos y base de datos. En cambio, algunos constructores cerrados no permiten exportar el sitio completo o utilizan funciones exclusivas de su plataforma.
También puede haber licencias vinculadas al dominio o a la dirección IP, integraciones que autorizan únicamente el servidor anterior y módulos que necesitan una versión concreta de PHP. Conviene identificar estas dependencias antes de contratar el destino.
Elegir el método de transferencia
El método más conveniente depende de los paneles y accesos:
- Transferencia entre servidores cPanel: puede copiar una cuenta completa mediante herramientas administrativas.
- Restauración de un backup completo: el proveedor de destino restaura un archivo generado en el panel anterior.
- Migración manual: se copian archivos, bases y configuraciones por separado.
- Herramienta del CMS: algunos sitios pueden clonarse mediante una extensión especializada.
Si ambos extremos utilizan cPanel, consultá cómo migrar una cuenta cPanel completa. Cuando solo se trasladará una aplicación, la guía para migrar un sitio con base de datos explica los componentes técnicos.
Crear un respaldo independiente
Aunque el proveedor realice la transferencia, conservá una copia propia de los datos importantes. El respaldo debe incluir archivos y base de datos correspondientes al mismo momento. Si el correo también se mueve, definí cómo se preservarán los mensajes existentes.
Un backup no debe considerarse válido solamente porque el archivo existe. Verificá que termine sin errores, tenga un tamaño razonable y pueda ser leído por la herramienta de restauración. En cPanel podés seguir la guía para generar un backup completo del sitio.
Revisar compatibilidad en el servidor nuevo
Antes del cambio, compará versión de PHP, módulos, motor de base de datos, límites de memoria, tareas programadas y espacio disponible. Una aplicación antigua puede necesitar una versión que el nuevo servidor ya no ofrece; una aplicación moderna puede fallar si el origen nunca fue actualizado.
La migración es una buena oportunidad para detectar software obsoleto, pero no siempre conviene actualizar y mudar simultáneamente. Separar ambos cambios facilita identificar la causa de un error.
Probar el sitio antes de cambiar DNS
Siempre que sea posible, verificá la copia mediante una dirección temporal o una configuración local que permita abrir el dominio en el servidor nuevo. Revisá páginas, panel administrativo, formularios, búsquedas, imágenes, descargas, carrito, certificados y tareas automáticas.
En una tienda o sitio con usuarios activos, definí un momento de corte. Si continúan ingresando pedidos, comentarios o cambios al servidor anterior después de copiar la base, será necesaria una sincronización final o un período breve de mantenimiento.
Planificar el correo por separado
El correo es uno de los puntos que más fácilmente se omiten. Antes del cambio, creá las casillas en destino, copiá los mensajes si corresponde y revisá cuotas, filtros y reenviadores. Confirmá además los registros MX, SPF, DKIM y DMARC.
Durante la actualización de DNS algunos remitentes podrían llegar al servidor anterior y otros al nuevo. Mantener ambos servicios activos y realizar una sincronización final reduce el riesgo de dejar mensajes sin copiar.
Cambiar DNS únicamente cuando el destino esté listo
DNS indica a navegadores y clientes de correo qué servidor deben utilizar. El cambio puede consistir en reemplazar nameservers o modificar registros individuales. La opción correcta depende de quién administra actualmente la zona.
El tiempo de actualización no es idéntico para todos porque existen respuestas almacenadas en caché. Podés ampliar este punto en cuánto tarda la propagación DNS. No cambies la delegación antes de copiar y probar.
Cómo conservar direcciones y posicionamiento
Si se mantiene el mismo dominio y las mismas URL públicas, la migración de servidor no debería requerir redirecciones. Comprobá que el nuevo sitio responda mediante HTTPS, conserve canonicals y no tenga bloqueos de indexación utilizados durante las pruebas.
Si además cambia la estructura de URL, prepará una correspondencia entre cada dirección antigua y su equivalente nueva. Las redirecciones permanentes deben probarse evitando cadenas, bucles y destinos sin relación.
No cancelar inmediatamente el servicio anterior
Mantené el origen operativo durante un período prudente. Revisá registros, formularios, correo y datos recientes antes de solicitar la baja. También conservá una copia descargada, ya que después de cancelar puede no ser posible recuperar la cuenta.
Si el destino será Atlántica Digital, consultá la guía específica para migrar un sitio web hacia nuestros servidores. Informar el panel de origen, tamaño, tecnología y alcance del correo permite determinar el método adecuado antes de iniciar.
