Cómo migrar un sitio web o app a un nuevo servidor cloud
Para migrar a un servidor cloud con seguridad, deja intacto el servidor antiguo hasta que el nuevo haya atendido tráfico real. Esta guía es un plan para un sitio web, una tienda o una aplicación: tres checklists (antes, cambio y reversión), comandos que puedes adaptar y límites honestos sobre el tiempo de inactividad. Primero dimensiona el destino con la guía de dimensionamiento de servidores cloud y elige la región con la guía de ubicaciones en Europa.
Elige el método de migración
Cuatro métodos cubren casi cualquier mudanza. Muchos proyectos combinan dos.
| Método | Ideal para | Riesgo principal |
|---|---|---|
| rsync de archivos | Sitios estáticos, subidas, código de la app | Los datos cambian durante la copia, hace falta una sincronización final |
| Imagen o restauración de backup | Mismo sistema operativo y disposición, restauración probada | Controladores y nombres de red antiguos, más datos que mover |
| Redespliegue de la app | Contenedores y código en git | Se olvida el estado oculto del disco antiguo |
| Replicación de base de datos | Bases grandes o muy activas | Esfuerzo de configuración y límites de versión |
Empieza con un servidor cloud desde EUR 15.00/mes, comprobado 2026-10 y ensaya allí todo el plan.
Checklist previa a la migración
- Inventario - lista servicios, puertos, tareas cron, ajustes de correo, certificados, reglas de firewall y todos los nombres que apuntan a la IP antigua.
- Estado oculto - busca archivos fuera de la raíz web: subidas, colas, sesiones, licencias, secretos en variables de entorno.
- Backups - haz una copia completa del servidor antiguo y restáurala una vez en otro sitio, porque un backup sin probar es solo una esperanza.
- Acceso - solo claves SSH, un firewall y un usuario de despliegue sin root en el nuevo servidor.
- Instantánea - crea una instantánea del servidor nuevo antes de la primera sincronización real, para que un error cueste minutos.
Copia archivos y datos
Los ejemplos usan la dirección de documentación 203.0.113.10 como servidor nuevo. Sustituye nombres y rutas por los tuyos. Los pasos 1 y 2 se pueden repetir sin riesgo; el paso 5 solo se ejecuta con el sitio antiguo en modo de solo lectura.
# 1. Bulk copy while the old server keeps serving (repeat any time)
rsync -aHAX --numeric-ids --info=progress2 \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 2. Database dump and restore (MySQL / MariaDB shown)
mysqldump --single-transaction --routines --triggers appdb \
| gzip | ssh deploy@203.0.113.10 'gunzip | mysql appdb'
# 3. Test the new server under the real hostname, DNS untouched
curl -sS --resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null -w '%{http_code}\n'
# 4. Check the TTL resolvers will honour
dig +noall +answer example.com A
# 5. Final sync after the old site is read-only
rsync -aHAX --numeric-ids --delete \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
La opción --delete borra en el destino los archivos que ya no existen en el origen. Úsala solo en la última ejecución y solo si tienes claro qué lado es el maestro.
Prueba primero con el archivo hosts
Antes de cambiar el DNS, haz que tu propio ordenador resuelva el sitio hacia el servidor nuevo. Añade una línea al archivo hosts (/etc/hosts, o C:\Windows\System32\drivers\etc\hosts en Windows): 203.0.113.10 example.com www.example.com. La opción --resolve de curl (paso 3) hace lo mismo para una sola petición. Después elimina la línea, o estarás probando el servidor nuevo durante semanas sin darte cuenta.
Baja el TTL del DNS y haz el cambio
Baja el TTL de los registros A y AAAA a unos 300 segundos, al menos un periodo completo del TTL antiguo antes de la mudanza. Si no, los resolvers conservan la dirección antigua tanto como diga el TTL anterior. Algunos resolvers ignoran un TTL corto, así que espera una cola de visitantes en la IP antigua durante horas (una estimación, no una medición).
Checklist del cambio:
- TTL - el valor reducido está activo y el antiguo ya caducó.
- Solo lectura - el sitio antiguo está en mantenimiento o en solo lectura.
- Sincronización final - último volcado de la base y paso 5 del código anterior hechos.
- DNS - los registros A y AAAA apuntan a la IP nueva; los de correo no cambian salvo que el correo también se mude.
- Prueba rápida - inicio de sesión, pedido, subida, correo, cron y certificado verificados con el nombre público.
- Servidor antiguo - déjalo encendido, accesible y sin tocar.
Checklist de reversión
- Umbral - decide de antemano qué cuenta como fallo, por ejemplo pagos fallidos o una tasa de 5xx, y quién decide.
- DNS de vuelta - apunta los registros a la IP antigua; con un TTL bajo la mayoría vuelve en minutos u horas.
- Escrituras - reabre el sitio antiguo. Si el nuevo aceptó pedidos o subidas desde el cambio, expórtalos primero y repítelos en el antiguo.
Qué exige de verdad el cero tiempo de inactividad
El cero tiempo de inactividad depende de la arquitectura de tu aplicación y no se promete para ningún proyecto. Requiere una app sin estado, una base de datos que replique o acepte escrituras en ambos lados, almacenamiento compartido o replicado y un cambio probado. Un sitio clásico con una sola base suele tener una breve ventana de solo lectura de minutos.
Después de la mudanza
Vigila durante al menos una semana los registros de errores, el disco, la memoria, los tiempos de respuesta y la entrega de correo. Vuelve a subir el TTL del DNS cuando todo esté estable. Retira el servidor antiguo solo cuando haya pasado un ciclo completo de backups en el nuevo; un backup semanal está incluido en cada preset. Prueba antes de comprometerte con la checklist de prueba; puede ser posible una prueba corta escribiendo a sales@dcxv.com, a criterio de DCXV y sin garantía.
Configura el servidor cloud de destino o pregunta a un ingeniero sobre la migración.
