Cómo migrar el sitio del servidor de MU a otro hosting sin downtime
Migra el sitio de tu servidor de MU Online a un nuevo hosting sin que los jugadores lo noten, con sincronización de archivos, prueba previa y cambio de DNS controlado.
Migrar el sitio del servidor de MU Online a un nuevo hosting es una de esas tareas que asustan a primera vista, porque el miedo es siempre el mismo: que los jugadores caigan en una página fuera de línea, que se pierdan registros o que el sitio vuelva roto en un horario pico. La buena noticia es que,
Migrar el sitio del servidor de MU Online a un nuevo hosting es una de esas tareas que asustan a primera vista, porque el miedo es siempre el mismo: que los jugadores caigan en una página fuera de línea, que se pierdan registros o que el sitio vuelva roto en un horario pico. La buena noticia es que, con planificación, una migración se puede hacer con cero downtime perceptible — el jugador sigue entrando, registrándose y votando mientras cambias el piso bajo sus pies. El secreto no es velocidad, es paralelismo: preparas y validas el sitio entero en el nuevo host antes de mandar a cualquier visitante allí, y solo entonces rediriges el tráfico de forma controlada, manteniendo el entorno antiguo de reserva hasta que baje la polvareda. Este tutorial recorre ese método paso a paso, del inventario inicial al cambio de DNS y al apagado seguro del host antiguo. Los ejemplos asumen un sitio PHP con base de datos, el estándar de los servidores de MU, pero el método vale para cualquier stack. Rutas, paneles y nombres de servicio varían según el hosting, así que adáptalo a tu proveedor.
Requisitos previos
La migración es una operación sobre algo que ya funciona. Si tu sitio todavía no está en línea o estás montando el servidor, empieza por la guía de cómo crear un servidor de MU Online y vuelve aquí cuando necesites cambiar de hosting.
- Acceso completo al host antiguo (archivos, base y configuración).
- Un nuevo hosting contratado y accesible (VPS o hosting compartido con PHP compatible).
- Acceso al panel de DNS del dominio (donde editas registros A/CNAME).
- Acceso al firewall del SQL Server del juego, para liberar el IP del nuevo host.
- Herramienta de transferencia (rsync, SFTP o el gestor de archivos del panel).
- Un periodo de bajo movimiento planificado para el cambio final (madrugada, por ejemplo).
El concepto: paralelismo, no sustitución
El error clásico es tratar la migración como un cambio instantáneo: apagar el viejo, encender el nuevo. Eso garantiza downtime y pánico si algo falla. El método sin downtime funciona al revés — los dos entornos coexisten:
- Montas el sitio completo en el nuevo host, apuntándolo a la misma base del juego.
- Pruebas el nuevo host accediendo por IP directo, sin tocar el DNS.
- Solo cuando el nuevo entorno está 100% validado, apuntas el DNS a él.
- Mantienes el host antiguo encendido durante toda la propagación del DNS.
- Apagas el antiguo solo cuando confirmas que todo el tráfico ya va al nuevo.
Como la base de datos del juego permanece única y en su lugar, no hay riesgo de perder registros — los dos hosts leen y escriben en el mismo lugar.
Paso 1 — Inventario completo
Antes de copiar cualquier cosa, mapea todo lo que el sitio necesita. Un ítem olvidado es lo que rompe la migración:
| Ítem | Dónde verificar | Observación |
|---|---|---|
| Versión de PHP | phpinfo() en el host antiguo | El nuevo host debe tener versión igual o compatible |
| Extensiones PHP | phpinfo() | sqlsrv, pdo_sqlsrv, gd, curl, etc. |
| Credenciales de la base | Archivo de config del sitio | Host, usuario, contraseña, nombre de la base |
| Archivos de subida | Carpeta de assets/uploads | Capturas, avatares, banners |
| Cron jobs | Panel del host | Scripts programados (rankings, votos) |
| Certificado SSL | Panel/Let's Encrypt | Deberá reemitirse en el nuevo host |
Reglas .htaccess | Raíz del sitio | URLs amigables, redirects |
Paso 2 — Reducir el TTL del DNS con antelación
Este es el paso más descuidado y el más importante para el "sin downtime". El TTL (time to live) define por cuánto tiempo los proveedores guardan en caché el IP de tu dominio. Si está en 86400 (24h), el cambio de IP puede tardar un día entero en propagar. Con 24 a 48 horas de antelación, reduce el TTL del registro A a 300 segundos (5 minutos):
; Antes (padrão)
servidorx.com. 86400 IN A 200.100.50.10
; Ajuste 48h antes da migração
servidorx.com. 300 IN A 200.100.50.10Haciendo esto con antelación, cuando finalmente cambies el IP, el cambio propaga en minutos.
Paso 3 — Preparar el nuevo host en paralelo
Con el inventario en mano, monta el nuevo entorno sin tocar el DNS:
- Instala la misma versión de PHP y todas las extensiones listadas en el inventario.
- Copia todos los archivos del sitio. Con acceso SSH en los dos lados, el rsync es el más confiable:
rsync -avz --progress \
-e ssh usuario@host_antigo:/var/www/site/ \
/var/www/site/- Ajusta el archivo de configuración del sitio en el nuevo host. Las credenciales de la base siguen apuntando al SQL Server del juego — que no se mueve —, así que confirma que el nuevo host puede alcanzarlo por la red.
- Libera el IP del nuevo host en el firewall del SQL Server del juego:
New-NetFirewallRule -DisplayName "SQL Site Novo Host" `
-Direction Inbound -Protocol TCP -LocalPort 1433 `
-RemoteAddress 203.0.113.25 -Action Allow- Reemite el certificado SSL para el nuevo host (con Let's Encrypt, genéralo ya apuntando al dominio, validando por DNS si es necesario para no depender aún del cambio de IP).
Paso 4 — Probar el nuevo host antes del cambio
Nunca migres a ciegas. Fuerza a tu propia máquina a ver el dominio en el nuevo IP editando el archivo hosts local, sin alterar el DNS público:
# Windows: C:\Windows\System32\drivers\etc\hosts
# Linux/Mac: /etc/hosts
203.0.113.25 servidorx.com www.servidorx.comAhora, en tu navegador, servidorx.com resuelve al nuevo host, pero solo para ti. Prueba todo:
- La home carga y muestra datos del juego (rankings, online).
- El registro crea cuenta de verdad en la base.
- El login funciona.
- La página de descarga y los votos operan.
- Los cron jobs corren en el nuevo host.
- HTTPS válido, sin alerta de certificado.
Solo avanza cuando todos los flujos pasen. Después, quita la línea del hosts para volver al estado normal.
Paso 5 — El cambio de DNS
Con el nuevo host validado y el TTL ya bajo, haz el cambio en el horario de menor movimiento. En el panel de DNS, cambia el registro A al nuevo IP:
; Troca final
servidorx.com. 300 IN A 203.0.113.25A partir de aquí, los nuevos visitantes empiezan a caer en el nuevo host a medida que el caché de 300s expira. Como la base es la misma, quien todavía cae en el host antiguo durante la propagación también funciona normalmente — nada se pierde.
Paso 6 — Monitorear la propagación
Acompaña la propagación consultando el registro desde varios puntos. Localmente:
nslookup servidorx.com 8.8.8.8
nslookup servidorx.com 1.1.1.1Usa también un verificador de DNS global para revisar múltiples regiones. Cuando todos devuelvan el nuevo IP, la propagación terminó. Mientras tanto, monitorea los logs de ambos hosts para confirmar que el tráfico está migrando y que ningún error aparece en el nuevo.
Paso 7 — Apagar el host antiguo con seguridad
No apagues el host antiguo apenas cambies el DNS. Espera la propagación completa más un margen de seguridad (24 horas es prudente, cubriendo proveedores que ignoran el TTL). Antes de apagar del todo:
- Confirma que los logs del host antiguo dejaron de recibir tráfico relevante.
- Haz un último backup completo de los archivos y de la base antiguos.
- Quita la regla de firewall del SQL Server que liberaba el IP del host antiguo (si ya no se usa).
- Solo entonces cancela o apaga el servicio antiguo.
Después de que todo se estabilice, restaura el TTL del DNS a un valor normal (3600 o 86400) para reducir consultas y aliviar los resolvers.
Errores comunes y soluciones
| Síntoma | Causa probable | Solución |
|---|---|---|
| El sitio oscila entre versión nueva y antigua | Propagación de DNS en curso | Espera a que expire el caché; mantén los dos hosts iguales |
| El nuevo host no conecta a la base del juego | IP no liberado en el firewall | Libera el IP del nuevo host en el puerto del SQL Server |
| Error de extensión PHP ausente | Nueva versión sin sqlsrv/pdo_sqlsrv | Instala las extensiones listadas en el inventario |
| Alerta de certificado en el nuevo host | SSL no reemitido | Genera el certificado para el dominio antes del cambio |
| Los cron jobs se detuvieron | No recreados en el nuevo host | Reconfigura las programaciones en el nuevo panel |
| URLs amigables rotas | .htaccess/rewrite no copiado | Transfiere y valida el .htaccess |
| Downtime largo tras el cambio | TTL alto no reducido antes | Reduce el TTL 24–48h antes la próxima vez |
Caso especial: migrar la base también
Este tutorial asume que la base del juego permanece en su lugar — el escenario más común y el más seguro. Si necesitas mover la base también, el cero downtime se vuelve mucho más difícil, porque no puedes tener escrituras simultáneas en dos bases divergiendo. En ese caso, planifica una ventana de mantenimiento anunciada: pon el sitio en modo mantenimiento, haz el dump final, restaura en la nueva base, apunta el sitio y reabre. No intentes migrar la base en producción sin congelar las escrituras.
Lista de verificación de lanzamiento
- Inventario completo (PHP, extensiones, credenciales, uploads, crons, SSL,
.htaccess) - TTL del DNS reducido a 300s con 24–48h de antelación
- Nuevo host montado con la misma versión de PHP y extensiones
- Archivos sincronizados vía rsync/SFTP
- IP del nuevo host liberado en el firewall del SQL Server del juego
- SSL reemitido y válido en el nuevo host
- Prueba completa vía archivo
hostslocal (registro, login, votos, crons) - Cambio de DNS hecho en horario de bajo movimiento
- Propagación monitoreada con nslookup y verificador global
- Host antiguo mantenido en línea hasta la propagación completa + margen
- Backup final y apagado seguro del host antiguo
- TTL restaurado a valor normal tras estabilizar
Preguntas frecuentes
¿Por qué reducir el TTL del DNS antes de la migración?
Un TTL alto hace que los proveedores mantengan el IP antiguo en caché por horas. Reduciéndolo a 300 segundos con antelación, el cambio al nuevo servidor propaga en minutos, no en horas.
¿El sitio de MU accede a la base del juego directamente?
Sí, en la mayoría de los casos. Por eso el nuevo servidor del sitio necesita poder alcanzar el SQL Server del juego, lo que exige liberar el IP del nuevo host en el firewall de la base.
¿Necesito tirar abajo el sitio durante la migración?
No, ese es el objetivo del método. Preparas y pruebas todo en el nuevo host en paralelo, y solo cambias el DNS cuando el nuevo entorno esté validado, manteniendo el antiguo en línea hasta que termine la propagación.
¿Qué pasa si un jugador se registra durante el cambio de DNS?
Durante la ventana de propagación, los registros pueden caer en el host antiguo o en el nuevo. Como ambos apuntan a la misma base del juego, el dato no se pierde; el riesgo solo existe si migras la base junto, lo que exige congelamiento.
¿Cómo sé que la propagación del DNS terminó?
Consulta el registro en varias localidades con herramientas de verificación de DNS o el comando nslookup. Cuando todas devuelven el nuevo IP, la propagación acabó y puedes apagar el host antiguo.