La migración de un sitio web puede parecer tres acciones sencillas: copiar archivos, importar la base de datos y cambiar el DNS. Los proyectos reales fallan en los detalles ocultos detrás de esas tres frases: tareas cron, buzones, claves API, extensiones de PHP, registros DNS, uploads, checkout y datos que siguen cambiando durante la propia migración.
Por eso prefiero tratar una migración como una línea de tiempo corta y no como un único evento.
Si estás migrando a SERVER1, elservicio de migración de hostingcubre el flujo de trabajo relacionado con archivos, bases de datos, correo y validación posterior al lanzamiento; aun así, el alcance exacto debe acordarse para cada proyecto.
T−7 días - crea un inventario antes de tocar nada
Enumera todas las dependencias del entorno anterior
- dominios y subdominios;
- bases de datos y usuarios;
- buzones y DNS relacionado con el correo;
- certificados SSL;
- cron y tareas programadas;
- versiones del runtime y extensiones;
- APIs externas, callbacks de pago y listas de IP permitidas.
Si una dependencia no aparece en esta lista, probablemente sea exactamente el tipo de detalle que se recuerda después del cambio.
Antes de cerrar la elección del entorno de destino, revisa los criterios paraelegir un plan de hostingpara que la carga migrada no empiece su nueva vida limitada por recursos.
T−1 día - el nuevo VPS ya debe poder probarse
Todavía no cambies el DNS
Prueba el entorno nuevo mediante una modificación del archivo hosts o un hostname de staging. Comprueba login, formularios, uploads, checkout, tareas en segundo plano y correo saliente. Compara la configuración del runtime y los permisos de archivo con el servidor anterior.
En migraciones de WordPress, entenderWordPress Toolkittambién puede ser útil cuando Plesk forma parte del nuevo entorno.
Al planificar el cambio, comprender las causas y el impacto delas caídas de un sitio webayuda a definir una ventana de mantenimiento realista.
T0 - día del cambio
Primero la sincronización final; después, el DNS
En un sitio dinámico los datos siguen cambiando después de la primera copia. Una tienda puede recibir un pedido nuevo, un usuario puede subir un archivo o un administrador puede editar contenido. Por eso se necesita una sincronización final o una breve ventana de mantenimiento antes del cambio.
Los cambios de DNS vienen después. Ambos entornos deben permanecer preparados durante la propagación, porque temporalmente distintos usuarios pueden llegar a servidores diferentes.
T+1 día - todavía no apagues el servidor anterior
Prueba las funciones de negocio, no solo la página de inicio
Revisa logs del servidor web, errores de la aplicación, entrega de correo, tareas programadas, callbacks de pago, SSL y analítica. Mantén el hosting anterior disponible durante un breve periodo como fallback hasta que el nuevo entorno sea claramente estable.
Define la condición de rollback antes de la migración
Si el checkout falla, los datos no cuadran o una integración crítica no puede estabilizarse dentro de la ventana acordada, devuelve el tráfico al entorno anterior y corrige el problema sin presión.
Una regla de rollback acordada de antemano evita decisiones emocionales durante el cambio.
Un proveedor deVPS administradopuede ayudar con la migración, pero aclara el alcance: ¿solo el sitio web o también correo, DNS y tareas específicas de la aplicación? Una buena migración no termina cuando cambia el DNS, sino cuando el nuevo entorno ha sido verificado y la ruta de rollback ya no es necesaria.
