Cómo cambiar de hosting sin perder correos ni página web

Que la portada cargue no demuestra que los pedidos, formularios y correos hayan sobrevivido al cambio.

Qué cambia al migrar hosting, correo o dominio

El registrador del dominio, el proveedor DNS, el servidor web y el servicio de correo pueden ser cuatro empresas distintas. No necesitas trasladarlas todas a la vez. Antes de aceptar una “migración completa”, define cuáles están incluidas.

Si primero necesitas separar dominio y buzones, consulta cómo crear correo corporativo en ZonaPyme.

1. Haz un inventario antes de contratar la migración

• Dominio y DNS: registrador, zona autoritativa, registros actuales, subdominios y configuración DNSSEC si existe.
• Página: archivos, base de datos, versiones de software, almacenamiento externo, tareas programadas e integraciones.
• Correo: buzones, espacio ocupado, alias, reenvíos, filtros y servicios que envían mensajes en nombre del dominio.
• Negocio: formularios, accesos, pagos, pedidos, notificaciones, certificados y verificaciones de buscadores.
• Responsable: quién valida cada servicio y quién autoriza el cambio o la reversión.

Un buzón del servidor no necesariamente contiene lo que ves en Outlook. POP, carpetas locales, contactos y calendarios pueden requerir exportaciones o métodos diferentes. Confirma el alcance antes de borrar una cuenta o cancelar el origen.

2. Guarda copias y comprueba que se pueden restaurar

Conserva una copia independiente de archivos y base de datos, y registra su fecha. Si una tienda recibe pedidos durante la copia, archivos y base deben pertenecer a un estado compatible. Incluye contenido generado por usuarios y exporta por separado lo que reside en servicios externos.

Restaura una muestra o el sitio completo en un entorno autorizado. Un archivo descargado no demuestra una recuperación. La guía de backup y recuperación explica cómo definir pérdida de datos tolerable y tiempo de recuperación.

3. Prueba el nuevo hosting antes de apuntar el dominio

Restaura la aplicación y comprueba versiones, extensiones, permisos y conexión a la base de datos. Una URL temporal puede no funcionar con aplicaciones que dependen del nombre de dominio, como algunas instalaciones de WordPress. El responsable técnico puede preparar una resolución local controlada para probar el destino y deshacerla después; no debe desactivar la validación TLS como solución permanente.

• Abre páginas interiores, imágenes y descargas, no solo la portada.
• Prueba acceso, formularios, redirecciones y tareas programadas.
• Comprueba las notificaciones y el remitente del correo de la aplicación.
• En eCommerce, usa un modo de prueba autorizado para checkout y pagos, sin cobrar compras reales para “probar”.

Evita que las dos copias ejecuten a la vez tareas de cobro, facturación o campañas. Mantén el entorno de prueba fuera de la indexación y controla sus accesos.

4. Si mueves el correo, copia los mensajes antes de cambiar los MX

Si conservas el proveedor de correo, no cambies sus registros sin necesidad. Revisa, aun así, si el nombre del servidor de correo depende de la IP que vas a sustituir.

Si cambias de servicio, crea previamente usuarios, buzones, alias y capacidad suficiente. Cuando origen y destino sean compatibles, una migración IMAP puede copiar mensajes y carpetas; no convierte automáticamente contactos, calendarios ni archivos locales. Selecciona el método indicado para ambas plataformas.

Prepara una primera copia y una sincronización final para los mensajes que lleguen al origen durante la transición. La documentación de Microsoft recomienda preparar usuarios y buzones antes de dirigir el correo al nuevo servicio. Cambiar MX decide dónde se reciben nuevos mensajes: no traslada el historial.

En cPanel, revisa además Email Routing si el correo queda en un servicio remoto. La detección automática utiliza la zona local y no vuelve a ajustar la decisión por cada cambio posterior. Una configuración incorrecta puede afectar mensajes enviados desde formularios del propio servidor.

5. Cambia los registros en el proveedor DNS autoritativo

Editar una zona en un panel que no sirve el DNS público no cambia el destino de los visitantes. Localiza primero la zona autoritativa. Cambiar nameservers no siempre es necesario; si lo haces, replica previamente todos los registros y coordina DNSSEC cuando corresponda.

Bajar el TTL puede ayudar si se hace antes del cambio y se deja vencer el valor anterior. No hay una promesa universal de cinco minutos, 24 o 48 horas para completar una migración: el comportamiento de cachés también influye. Recupera después el TTL adecuado para la operación normal.

6. Haz el cambio final y valida el negocio

1. Define una ventana para controlar escrituras y cambios pendientes.
2. Sincroniza la última base de datos, archivos nuevos y correo, según el alcance.
3. Modifica únicamente los registros previstos y conserva los valores anteriores.
4. Comprueba resolución y funcionamiento desde más de una red.
5. Envía un correo desde una cuenta externa, responde desde el nuevo buzón y prueba el formulario.
6. Verifica que un pedido de prueba autorizado aparezca una sola vez, con sus avisos e inventario.
7. Concilia cambios que hayan llegado al servidor anterior durante la transición.

Documenta qué se probó, cuándo y con qué resultado. No canceles el origen porque un navegador muestre una portada correcta.

Cómo conservar el SEO al cambiar de servidor

Si no cambian dominio ni rutas, conserva las URL, contenido, canonical, redirecciones y sitemap. Revisa HTTPS, www, enlaces interiores y errores 404. Mantén los archivos de verificación de Google y Bing que utilices.

Antes de abrir el destino al público, retira el noindex o las restricciones usadas solo para las pruebas y comprueba que los rastreadores pueden acceder. Google documenta esta distinción en las migraciones de infraestructura sin cambios de URL. Si también cambias dominio o rutas, necesitas otro plan de redirecciones y verificación: no lo añadas por accidente a un simple cambio de hosting.

Estas comprobaciones reducen errores evitables; no garantizan mantener una posición ni una frecuencia de rastreo.

7. Conserva un plan de reversión y concilia datos

Define qué falla justificaría volver atrás, quién decide y qué registros recuperar. Volver a la IP antigua sin trasladar los pedidos o mensajes creados en el destino puede perder datos. La reversión necesita conciliación, no solo deshacer DNS.

Cancela el servicio anterior cuando el responsable confirme la sincronización final, las pruebas y que ninguna dependencia siga usándolo. El plazo depende del proyecto; no fijes una fecha universal sin comprobarlo.

Checklist antes de cancelar el hosting anterior

• Copia independiente identificada y restauración comprobada.
• Páginas interiores, formularios, acceso, cron y SSL validados.
• Pedidos y cambios finales conciliados, sin doble ejecución.
• Buzones, historial, envío externo, recepción y formularios comprobados.
• DNS autoritativo y autenticación del correo revisados.
• Canonical, robots, ausencia de noindex y verificaciones conservados.
• Sincronización final completada y plan de reversión aprobado.

Qué confirmar si contratas una migración con HostingPlus

Afiliación: TopHosting está afiliado a HostingPlus y puede recibir una comisión si contratas mediante su enlace. Esa relación no demuestra rendimiento ni sustituye las condiciones del servicio.

La ficha oficial de VPS anuncia migración web gratuita al consultar el 11-10-2026. Antes de contratar, confirma elegibilidad, plataforma de origen, servicios incluidos, tamaño, ventana de trabajo, responsable de DNS y sincronización de los últimos datos. No extrapolamos esa mención a todos sus productos ni ofrecemos una garantía propia de interrupción cero.

Para elegir el destino, revisa la comparativa de hosting en Chile, las alternativas VPS y qué incluye la administración. El enlace siguiente lleva al programa chileno; la atribución internacional no está confirmada.

Consultar servicios de HostingPlus →

Preguntas frecuentes sobre migrar hosting y correo

¿Puedo cambiar de hosting sin perder mis correos?

Sí, puedes conservar el servicio actual o migrar sus buzones con un procedimiento compatible. En el segundo caso prepara el destino, copia el historial y sincroniza los mensajes finales antes de retirar el origen. No borres primero los buzones antiguos.

¿Necesito transferir el dominio?

No necesariamente. El dominio puede seguir en el registrador actual y apuntar a otro hosting mediante DNS. Transferirlo es un proceso distinto.

¿Cambiar los MX copia los mensajes antiguos?

No. Los MX indican dónde recibir correo nuevo. El historial exige una migración o exportación independiente.

¿Cuánto tarda cambiar de hosting?

Depende del volumen, la aplicación, el correo, las pruebas y las cachés. La propagación DNS es solo una etapa, no la duración total del trabajo.

¿Un plugin de WordPress migra todo?

Su alcance depende del producto. No asumas que incluye buzones, DNS, servicios externos o los pedidos recibidos después de la copia. Verifica la cobertura y la sincronización final.

Fuentes y alcance de esta guía

Documentación consultada el 11-10-2026. Es una secuencia editorial de planificación, no el resultado de una migración ejecutada ni un servicio de soporte.

• cPanel: servicios y guías de migración.
• cPanel: Email Routing.
• Cloudflare: TTL y caché DNS.
• Microsoft 365: preparar un dominio y sus usuarios.
• Google: migración de infraestructura sin cambiar URL.
• HostingPlus: ficha oficial VPS y alcance declarado.