Tips para migrar tu VPS de proveedor

Llevas meses notando lo mismo. La web tarda un poco más de lo que debería.

El soporte tarda días en responder o directamente no lo hace. El precio ha subido sin que hayan mejorado nada. Y tú, mientras tanto, justificando ante tus clientes, o ante ti mismo, que «el hosting a veces va así».

No va así. O no debería.
Cambiar de proveedor VPS da respeto. Es normal.

Hay algo de «y si la lío» flotando en el aire cada vez que lo piensas.
Pero la realidad es que una migración bien planificada es una de las decisiones más rentables que puedes tomar para tu proyecto.

El problema no es migrar: el problema es migrar sin saber exactamente qué estás haciendo.

Antes de mover nada: el diagnóstico que no debes saltarte

El error más frecuente en una migración de VPS es empezar por el final: contratar el nuevo servidor y ponerse a copiar archivos. Parece lo lógico, pero suele ser lo que provoca los problemas.

Antes de tocar nada en tu entorno actual, necesitas tener claras estas cuatro cosas:

1. Qué tienes exactamente en el servidor actual

No solo los sitios web visibles.
También los cronjobs, los procesos en segundo plano, las conexiones a APIs externas, los correos configurados, los certificados SSL y cómo están montados.

Haz un inventario real. Más de un equipo se ha llevado la sorpresa de que un servicio crítico corría en el servidor antiguo y nadie lo había documentado.

2. Cuál es tu ventana de mantenimiento tolerable

¿Puedes permitirte 2 horas de caída un domingo a las 3 de la madrugada?
¿O tu negocio no puede bajar el telón ni 15 minutos?
La respuesta a esto condiciona completamente la estrategia de migración que debes usar.

3. Cuál es el estado real de tu software

Si tienes WordPress en 5.2 con plugins sin actualizar desde 2021, este es el momento de modernizar antes de migrar, no después. Una migración es la oportunidad perfecta para llegar al nuevo VPS WordPress con tu casa en orden.

4. Qué problema estás resolviendo con el cambio

Si cambias porque el servidor es lento, asegúrate de que la lentitud es del servidor y no de tu código.

Si cambias porque el soporte es malo, verifica las valoraciones reales del nuevo proveedor. Si cambias por precio, calcula el coste total incluyendo el tiempo de gestión que vas a invertir.

La primera vez que migré un VPS lo hice a lo bruto: copié los archivos, cambié el DNS y recé. La web funcionó, pero el correo dejó de llegar durante tres días.
La segunda vez lo hice con un check-list. Fueron tres horas de trabajo tranquilo versus tres días de apagafuegos.
Marcos R. — Desarrollador freelance.

La migración en sí: los tips que marcan la diferencia

Hay cosas que todos los tutoriales de migración te dicen (hacer backup, probar en staging…) y hay cosas que solo aprendes habiéndote equivocado.

Aquí van ambas:

TIP 01 — Configura el nuevo servidor antes de tocar el antiguo

El nuevo VPS tiene que estar 100% funcional con tus aplicaciones corriendo antes de redirigir ni un solo usuario.

Esto parece obvio, pero la presión de «ya lo termino cuando esté en producción» hace que mucha gente se salte este paso.

No lo hagas.

TIP 02 — Replica el entorno con exactitud quirúrgica

Misma versión de PHP, mismas extensiones, misma configuración de MySQL, mismo servidor web (Apache o Nginx).

Las diferencias de versión son el origen del 80% de los errores post-migración.
Si tu app funciona con PHP 8.1, no migres a un servidor con PHP 8.3 sin haberlo probado antes.

TIP 03 — Usa rsync, no el panel de control

Copiar archivos desde el panel de control del hosting suele ser lento, incompleto y propenso a errores de permisos.

rsync sobre SSH es la herramienta estándar para esto: permite copias incrementales, verifica integridad y es mucho más rápido.
Si no estás cómodo con rsync, un buen proveedor puede gestionarlo por ti.

TIP 04 — Haz la copia de base de datos en frío cuando sea posible

Lo ideal es poner el sitio en modo mantenimiento, hacer el dump de la base de datos, restaurarlo en el nuevo servidor y verificar integridad antes de levantar el sitio de nuevo.

Si no puedes poner el sitio en mantenimiento, usa replicación en tiempo real, pero ten claro que es una operación más delicada.

TIP 05 — Verifica todo antes de cambiar el DNS

Apunta tu dominio al nuevo servidor modificando el archivo hosts de tu ordenador (no el DNS público) y navega por toda la web como si fueras un usuario.

Prueba el formulario de contacto, la pasarela de pago si tienes tienda, el correo, los redirects.
Todo.
Si algo falla aquí, tienes tiempo de arreglarlo sin que nadie lo note.

«Llevábamos dos años aguantando un proveedor que prometía el 99,9% de uptime y nos metía caídas cada dos por tres. Cuando finalmente migramos a un VPS con datacenter en Madrid, la diferencia fue inmediata: el TTFB bajó de 800ms a menos de 150ms.
Eso se traduce directamente en posicionamiento y en conversión.«
Silvia M. — Responsable técnica de una agencia digital en Madrid

El DNS: el momento más crítico y el más infravalorado

Si hay un punto donde las migraciones se complican innecesariamente, es el cambio de DNS.

Y la razón es siempre la misma: no entender cómo funciona la propagación.

Cuando cambias los nameservers o los registros A de tu dominio, el cambio no es instantáneo.

Puede tardar entre 1 y 48 horas en propagarse completamente por todos los servidores DNS del mundo. Durante ese tiempo, algunos usuarios verán el servidor antiguo y otros el nuevo.

La estrategia del TTL bajo

48-72 horas antes de la migración, reduce el TTL de tus registros DNS a 300 segundos (5 minutos).

Cuando hagas el cambio definitivo, la propagación será prácticamente instantánea. Después de la migración exitosa, vuelve a subir el TTL a 3600 o más.

Durante la ventana de propagación, tanto el servidor antiguo como el nuevo deben estar activos y sirviendo la misma versión del sitio.
Si tienes una tienda o cualquier aplicación con base de datos, asegúrate de que los datos se sincronizan entre ambos o mantén el servidor antiguo en modo solo lectura para evitar inconsistencias.

Una práctica muy recomendable es monitorizar la propagación con herramientas como DNSChecker o whatsmydns.net, que te muestran en tiempo real desde qué ubicaciones ya se está sirviendo el nuevo servidor.

Cosas que poca gente comenta (y que descubres a las 2 de la mañana)

Esta sección es la que más vale la pena.
Son los problemas que no aparecen en los tutoriales porque generalmente surgen en proyectos reales con configuraciones reales.

Los correos electrónicos: el gran olvidado

Si tienes correo configurado en tu dominio (cuentas de empresa, correo transaccional de la tienda…), la migración del correo es una operación completamente independiente de la migración del hosting.

Necesita su propio plan: cambiar los registros MX, migrar los buzones, verificar que los registros SPF, DKIM y DMARC están correctamente configurados en el nuevo servidor.

Si no lo haces bien, tus emails llegarán a spam o directamente no llegarán.

Los certificados SSL

Let’s Encrypt genera certificados vinculados al servidor, no al dominio.
Al migrar, necesitas emitir un certificado nuevo en el servidor destino.

Si usas cPanel o Plesk, esto es automático. Si gestionas el servidor directamente, asegúrate de tener Certbot configurado y de que el nuevo certificado se emite correctamente antes de forzar HTTPS.

Las IP en listas blancas de terceros

Si tu aplicación se conecta a APIs externas (pasarelas de pago, CRMs, herramientas de analítica con filtros por IP…), esas APIs posiblemente tienen tu IP actual en lista blanca. Cuando cambies de servidor, la IP cambia, y esas conexiones fallarán hasta que actualices las listas blancas en todos los servicios externos.

Identifica todas estas dependencias antes de migrar.

Las diferencias de configuración entre proveedores

Cada proveedor tiene sus propias configuraciones por defecto: límites de memoria de PHP, timeouts, configuración de OPCache, versiones de librerías del sistema.

Un sitio que funciona perfectamente en un servidor puede dar errores crípticos en otro con una configuración diferente. Revisa los logs de error el primer día con atención.

El backup del servidor antiguo no es el backup de tu migración

Haz una copia de seguridad completa justo antes de la migración, pero guárdala en un lugar externo a ambos servidores.

No en el antiguo (que vas a dar de baja) y no solo en el nuevo (que podría tener problemas). Un servicio de almacenamiento externo como S3 o Backblaze es la red de seguridad real.

«Tardé dos semanas en planificar la migración y cuatro horas en ejecutarla. El tiempo de planificación fue la inversión más rentable del año. La tienda no estuvo caída ni un minuto: puse un modo mantenimiento durante 45 minutos por la noche, y cuando los clientes se levantaron por la mañana todo funcionaba sobre el nuevo servidor.«
David C. — Propietario de tienda WooCommerce.

La semana después: aún no puedes relajarte del todo

La migración técnica es el 70% del trabajo.
El 30% restante está en los días posteriores, que mucha gente descuida porque siente que «ya está hecho».

Monitorización intensiva los primeros 7 días

Activa alertas de uptime (Uptime Robot tiene un plan gratuito más que suficiente para empezar), revisa los logs de PHP diariamente y compara el rendimiento con herramientas como GTmetrix o PageSpeed Insights.

Si algo ha empeorado respecto al servidor antiguo, quieres saberlo antes de que lo note un cliente.

Verifica el SEO activamente

Un cambio de servidor no debería afectar al posicionamiento si la migración se ha hecho bien, pero monitoriza Search Console durante las primeras semanas.

Si detectas caídas de rastreo o errores de cobertura nuevos, actúa rápido. El TTFB mejorado del nuevo servidor debería empezar a reflejarse en las métricas de Core Web Vitals en 2-4 semanas.

Revisa el funcionamiento del correo transaccional

Haz pruebas reales de envío desde la aplicación: formularios de contacto, emails de confirmación de pedido, recuperación de contraseña.

Comprueba que los correos llegan a la bandeja de entrada y no al spam, y que los registros de autenticación (SPF, DKIM) están correctamente configurados.

Mantén acceso al servidor antiguo durante 30 días

No des de baja el servidor antiguo el mismo día de la migración.
Mantenlo activo un mínimo de 30 días, aunque no esté sirviendo tráfico. Es tu red de seguridad por si aparece algún archivo o dato que no se migró correctamente.

Lista de comprobación: la migración completa

• Inventario completo de servicios en el servidor actual.
• Ventana de mantenimiento definida y comunicada.
• Software auditado y actualizado antes de migrar.
• Nuevo servidor configurado y probado en modo staging.
• TTL de DNS reducido 48-72h antes de la migración.
• Archivos copiados con rsync y permisos verificados.
• Base de datos migrada y verificada con checksums.
• Certificados SSL emitidos en el nuevo servidor.
• Correo y registros MX/SPF/DKIM configurados.
• IPs en listas blancas de terceros actualizadas.
• Prueba completa del sitio con archivo hosts antes del DNS.
• DNS cambiado y propagación monitorizada.
• Backup externo almacenado antes de dar de baja el servidor antiguo.
• Monitorización de uptime y logs activada.
• Servidor antiguo mantenido activo 30 días como seguro.

¿Prefieres que lo hagamos nosotros?

En FactoríaDigital gestionamos migraciones de VPS de principio a fin: planificación, ejecución, verificación y soporte post-migración. Con datacenter en Madrid, soporte en castellano y un equipo que entiende el impacto que tiene el servidor en el SEO y el rendimiento de tu negocio.

Habla con nosotros →

Última actualización: marzo de 2026