Migrar WordPress a un VPS sin perder correo ni DNS
Cómo trasladar un sitio de WordPress de un hosting compartido a un VPS sin perder el correo ni el DNS
Mover WordPress de un hosting compartido a un servidor privado virtual (VPS) puede darte más control sobre PHP, los recursos del servidor y la configuración. También puede interrumpir el correo o enviar a los visitantes al lugar equivocado si tratas el traslado como una simple copia de archivos. La clave está en separar el sitio web de los servicios que ya dependen de tu dominio.
Si estás investigando cómo migrar un sitio de WordPress de un hosting compartido a un VPS, empieza por averiguar qué servicios ofrece realmente tu proveedor actual. Puedes tener el dominio registrado con una empresa, el DNS con otra, el correo con una tercera y WordPress con una cuarta. No hace falta trasladar todos esos servicios a la vez; así podrás migrar WordPress sin perder el correo ni el DNS.
1. Define el alcance del traslado: separa el sitio web de los servicios que se quedan
Anota dónde están los archivos y la base de datos de WordPress y luego identifica qué proveedor se encarga de cada servicio relacionado. Comprueba quién registra el dominio, quién gestiona el DNS y el correo, y si tienes otros servicios independientes, como una CDN o almacenamiento de imágenes. El panel de control del hosting puede mostrar parte de esta información, pero los servidores de nombres y los registros DNS del dominio indican adónde se dirige realmente el tráfico.
Por ejemplo, un sitio puede estar alojado en un hosting compartido, tener el DNS gestionado con Cloudflare y usar Google Workspace para el correo del equipo. En ese caso, trasladar WordPress a un VPS no implica cambiar de proveedor de dominio ni de correo. Normalmente basta con modificar los registros que dirigen el tráfico web y dejar intactos los registros de correo.
Antes de cambiar nada, prepara un inventario sencillo. Anota el destino web actual, los servidores de nombres y los registros relacionados con el correo que conozcas. Si no sabes si un registro corresponde al correo, consulta con el proveedor o revisa sus instrucciones de configuración en vez de eliminarlo. Si falta un registro de correo, los mensajes entrantes podrían dejar de llegar aunque el sitio web funcione con normalidad.
2. Identifica dependencias que una copia básica del sitio podría pasar por alto
Una copia de seguridad de WordPress puede incluir los archivos y la base de datos del sitio, pero no necesariamente todos los servicios de los que depende. Comprueba las tareas programadas, la configuración del correo saliente, el almacenamiento externo, las redirecciones, la configuración de SSL y cualquier ajuste específico del servidor. Por ejemplo, un sitio de membresías podría depender de una tarea programada para dar de baja cuentas, mientras que una tienda podría enviar avisos de pedidos mediante un servicio SMTP externo.
Revisa las tareas programadas en el panel de control del hosting y en los plugins de WordPress. El sistema de tareas integrado de WordPress puede ejecutarse cuando alguien visita una página; en cambio, una tarea cron del servidor puede llamar a un script específico según un horario. Anota el comando, la frecuencia y la zona horaria de cada tarea. Si no configuras una tarea cron equivalente en el VPS, una tarea que se ejecutaba cada hora en el hosting anterior podría dejar de funcionar tras el traslado.
Comprueba cómo envía correos el sitio. Anota si utiliza el servidor de correo del hosting, un plugin SMTP o un servicio de correo transaccional, y confirma qué dirección usa como remitente. Si el servidor de correo lo proporcionaba el hosting anterior, es posible que la misma configuración no funcione desde el VPS. Consulta con el proveedor de correo si restringe las conexiones o requiere un método de autenticación específico.
Haz también una lista del almacenamiento externo y de los ajustes del servidor. Puede que un plugin de medios guarde los archivos en un almacenamiento de objetos en vez de hacerlo en el directorio de subidas de WordPress. El sitio podría depender de una versión concreta de PHP, de ciertas extensiones de PHP, de reglas de reescritura o de algún ajuste en .htaccess. Conserva una copia de esos datos: intentar adivinarlos después del lanzamiento puede convertir un pequeño problema de compatibilidad en una interrupción prolongada.
3. Prepara el VPS según las necesidades reales del sitio
Elige una configuración de VPS que se ajuste a las necesidades observadas del sitio y decide cómo atenderá las solicitudes web. Entre las opciones habituales están Apache y Nginx, pero la más adecuada depende del sitio actual y de la capacidad del administrador para mantenerla. Antes de instalar el entorno de producción, comprueba que la versión de PHP y las extensiones sean compatibles con el código, los plugins y el tema del sitio.
Configura la base de datos, el servidor web y el intérprete de PHP. Después, ajusta la propiedad y los permisos de los archivos para que WordPress pueda leerlos y escribir solo donde sea necesario. No des permisos de escritura a todos los archivos solo para eliminar un error. Restringe el acceso de administración, activa un cortafuegos y configura copias de seguridad que incluyan tanto la base de datos como los archivos del sitio.
Prueba el VPS antes de transferir el sitio activo. Comprueba que el servidor web pueda mostrar una página básica, que PHP funcione correctamente y que la base de datos acepte una conexión de prueba. Anota las versiones instaladas y los archivos de configuración. Así tendrás una referencia concreta para comparar si algún plugin se comporta de forma distinta en el servidor nuevo.
4. Transfiere los archivos y la base de datos sin modificar el sitio activo
Crea una copia completa de los archivos y la base de datos de WordPress, y mantén el sitio original disponible para los visitantes mientras trabajas. Un plugin de migración puede empaquetar el sitio, mientras que las herramientas de línea de comandos o una copia de seguridad del proveedor pueden ofrecerte más control. Sea cual sea el método, comprueba que la copia incluya la base de datos, los archivos subidos, los temas, los plugins y cualquier archivo de configuración personalizado.
Si el sitio recibe cambios con frecuencia, planifica cómo gestionar los nuevos pedidos, comentarios o publicaciones creados después de la primera copia. Una opción es hacer una copia inicial y probarla en privado; luego, repetir la transferencia de la base de datos durante un breve periodo de mantenimiento. Si tienes una tienda, evita aceptar pedidos en las dos copias: es más difícil corregir pedidos duplicados o perdidos que anunciar una pausa breve.
Transfiere los archivos y la base de datos al VPS y, si hace falta, actualiza la configuración de WordPress con el nombre, el usuario, la contraseña y el host de la nueva base de datos. Guarda de forma segura los valores antiguos y los nuevos. Si cambian el dominio o las rutas de los archivos, actualiza la configuración del sitio con cuidado; una búsqueda y reemplazo general puede dañar los datos serializados de la base de datos si no los gestiona correctamente.
Todavía no dirijas el DNS público al VPS. Mientras compruebas la copia privada, el hosting anterior debe seguir siendo el destino público. El servidor nuevo no debe recibir actividad real de clientes hasta que estés listo para completar el cambio.
5. Haz pruebas privadas antes de cambiar el DNS público
Usa una modificación del archivo hosts de tu equipo o un nombre de host temporal de pruebas para dirigir el navegador al VPS sin cambiar el DNS público. La modificación del archivo hosts solo afecta al dispositivo en el que la haces, por lo que resulta útil para revisar el sitio nuevo antes de que lo vean otros visitantes. Elimina la entrada cuando termines las pruebas para no confundir la ruta privada con la pública.
Prueba tanto la parte pública como el panel de WordPress. Revisa la página de inicio de sesión, una selección representativa de páginas importantes, las búsquedas, los formularios, las subidas, las redirecciones y cualquier función de pago o de membresía que utilice el sitio. Envía un formulario de prueba y comprueba adónde llega el mensaje. Si el sitio envía correos, verifica que se entreguen y que no acaben en la carpeta de spam: que aparezca una confirmación en pantalla no demuestra que el correo se haya enviado.
Comprueba las tareas programadas y las integraciones que acceden al sitio desde el exterior. Por ejemplo, un servicio de pagos puede enviar notificaciones a una URL concreta, mientras que un servicio de monitorización puede esperar una respuesta específica. Comprueba también que HTTPS funcione en el VPS. Es posible que el nombre de host de pruebas no coincida con el certificado de producción, así que verifica el plan del certificado definitivo antes de dirigir a los visitantes al servidor nuevo.
Revisa las redirecciones y las URL canónicas del dominio de producción. Si el sitio tiene una tasa de rebote alta, una página de destino rota o una redirección defectuosa podría empeorar el problema; en esta guía se explica qué se considera una buena tasa de rebote en un sitio web y cómo interpretar esta métrica. Durante las pruebas de migración, céntrate en detectar fallos concretos, como un formulario que devuelve un error o una imagen subida que no aparece.
6. Cambia el DNS con un plan para el correo y la reversión
Antes de modificar el DNS, guarda los registros actuales y anota exactamente cuáles vas a cambiar para la web. Si el sitio usa un registro A, cambia su destino a la dirección del VPS. Si el nombre de host web utiliza un CNAME, modifica ese registro según corresponda. Conserva los registros de correo, incluidos los registros MX y los registros TXT usados para autenticar el correo, salvo que vayas a cambiar de proveedor de correo deliberadamente. Este paso es fundamental para configurar DNS y correo al cambiar WordPress a un VPS sin afectar los servicios que deben permanecer con su proveedor actual.
Reducir el tiempo de vida (TTL) del DNS antes del traslado puede ayudar a que algunos servidores DNS adopten el nuevo destino más rápido, pero no garantiza un cambio inmediato en todo el mundo. Antes de editar los registros, revisa la configuración DNS actual y las recomendaciones del proveedor. Si usas un proxy o una CDN, confirma si la dirección del servidor de origen debe apuntar directamente al VPS y si el modo SSL del proxy es compatible con el certificado instalado allí.
Elige un horario para el cambio en el que puedas vigilar el sitio y responder a cualquier problema. Modifica los registros web previstos y luego comprueba el dominio desde más de una red o con varios servicios de consulta DNS. Deja por escrito las instrucciones para revertir el cambio: restaura el destino web anterior, indica quién puede hacer el cambio y conserva el acceso a la cuenta del hosting antiguo. No elimines el sitio anterior mientras las cachés DNS todavía puedan enviar visitantes allí.
Comprueba el correo por separado durante el cambio. Envía un mensaje desde una cuenta externa a una dirección del dominio y, si es posible, responde desde esa dirección. Si el correo deja de funcionar, compara los registros DNS actuales con la copia guardada antes de hacer otros cambios. Un traslado de servidor web no debería requerir que elimines los registros de correo.
7. Comprueba la nueva configuración después del lanzamiento
Cuando el tráfico público llegue al VPS, comprueba HTTPS, las páginas importantes, los formularios, el inicio de sesión y cualquier proceso relacionado con los ingresos. Revisa tanto los registros de WordPress como los del servidor para detectar errores de PHP, accesos denegados a archivos, conexiones fallidas con la base de datos o solicitudes repetidas a URL inexistentes. La página de inicio puede parecer normal aunque un error silencioso de un plugin haya dejado fuera de servicio el formulario de contacto.
Confirma que las copias de seguridad se ejecuten en el VPS y que sepas cómo restaurarlas. Comprueba el destino de las copias y verifica que una copia reciente incluya tanto la base de datos como los archivos. Configura la monitorización de disponibilidad y de vencimiento del certificado, y confirma que el correo siga funcionando en ambos sentidos. Haz estas comprobaciones antes de cancelar el plan de hosting anterior.
Mantén activo el hosting anterior hasta que el sitio nuevo haya superado las comprobaciones que definiste y los cambios DNS correspondientes se hayan propagado. Conserva una copia final de los archivos y la base de datos antiguos según tu política de conservación. Cuando el VPS ya sirva el sitio, el correo funcione y los pasos de recuperación estén documentados, podrás decidir cuándo cerrar la cuenta antigua sin tener que adivinar qué servicios seguía ofreciendo.
