La mayoría de las migraciones de sitios web y aplicaciones no son difíciles por la tecnología. Son difíciles porque el entorno antiguo ha acumulado años de decisiones no documentadas: un cron job que alguien añadió con prisa, un reenviador de correo del que depende un equipo de ventas, una dirección IP escrita directamente en el callback de un pago.
Esta guía describe un método de migración que mantiene el tiempo de inactividad en el orden de minutos, no de horas, para las pilas web habituales: sitios de contenido, tiendas de comercio electrónico, portales de clientes y aplicaciones de negocio que funcionan en hosting compartido, en un único VPS o en un servidor físico antiguo.
Qué significa realmente un tiempo de inactividad mínimo
El tiempo de inactividad cero es posible, pero normalmente requiere una aplicación capaz de funcionar en dos lugares a la vez con una base de datos compartida o replicada. La mayoría de las pilas heredadas no pueden hacerlo. Un objetivo más honesto es una congelación de escrituras breve y programada: el periodo entre el momento en que se detienen las escrituras en el sistema antiguo y el momento en que se aceptan en el nuevo. Para un sitio con unos pocos gigabytes de datos y un plan bien ensayado, esa ventana suele ser de 5 a 30 minutos.
Defina el objetivo por escrito antes de empezar cualquier trabajo. Indique el congelamiento de escrituras máximo aceptable, la pérdida de datos máxima aceptable (idealmente ninguna) y la hora del día con menos tráfico.
Primero, un inventario completo
El inventario es el mejor indicador de una migración limpia. Recopílelo del sistema en funcionamiento, no de memoria ni de documentación antigua, y asigne un responsable a cada elemento.
- Dominios y DNS. Cada dominio y subdominio, el registrador, el proveedor de DNS autoritativo y una exportación completa de los registros actuales, incluidos los registros TXT usados para verificación.
- Aplicaciones y entornos de ejecución. Versiones de lenguaje (por ejemplo, PHP 8.1 frente a 8.3), servidor web y módulos, extensiones, dependencias de Composer o npm, y cualquier binario compilado.
- Almacenes de datos. Motores de bases de datos y sus versiones, tamaños de las bases de datos, rutas y tamaños del almacenamiento de archivos, cantidad de objetos y almacenes de sesiones o de caché.
- Tareas programadas y en segundo plano. Entradas de cron, workers de colas, scripts de respaldo y cualquier trabajo que se ejecute con una cuenta de usuario específica.
- Integraciones. Pasarelas de pago, webhooks, relays SMTP, APIs que incluyen su IP saliente en listas de permitidos y conexiones de SSO o LDAP.
- Certificados y secretos. Certificados TLS y su método de renovación, claves de API, archivos de entorno y credenciales almacenadas en la configuración.
- Correo electrónico. Buzones, alias, reenvíos, listas de distribución, tamaños de los buzones y los clientes que las personas usan para conectarse.
Primero, busque en el código y en la configuración direcciones IP y rutas de archivo absolutas escritas directamente. Segundo, revise las conexiones salientes durante un día laborable normal (con una herramienta como ss o netstat, o con los logs del firewall) para encontrar integraciones que nadie recordaba.
Prepare el DNS y los tiempos
La caché de DNS es la principal razón por la que los usuarios siguen llegando al servidor antiguo después del cutover. Si su registro A tiene un TTL de 86.400 segundos (24 horas), algunos visitantes pueden llegar a la dirección IP antigua durante un día completo después de que la cambie.
Reduzca a 300 segundos el TTL de cada registro que piense cambiar, y hágalo al menos un TTL antiguo completo antes del cambio, preferiblemente con 48 horas de antelación. Algunos resolvers y proxies corporativos no respetan los TTL cortos, así que cuente de todos modos con una cola de tráfico hacia el servidor antiguo durante varias horas.
Confirme también quién controla las cuentas del registrador y del DNS, que la autenticación de dos factores funciona y que las personas que ejecutan el cutover pueden iniciar sesión.
Sincronice los datos sin paralizar el negocio
El objetivo es mover casi todos los datos mientras el sistema antiguo sigue en funcionamiento, para que la sincronización final durante la congelación de escrituras sea pequeña. Un enlace de 1 Gbps mueve unos 10 TB al día a plena carga, pero las migraciones reales rara vez alcanzan la velocidad de la línea, porque el servidor de origen, los límites del hosting compartido o la gran cantidad de archivos pequeños ralentizan el proceso.
- Archivos. Haga una copia completa inicial con una herramienta como rsync y repita ejecuciones incrementales a diario. Cada ejecución transfiere solo los cambios, así que la pasada final durante el cutover suele tardar desde segundos hasta unos pocos minutos.
- Bases de datos de menos de unos pocos gigabytes. Un volcado y una restauración durante el congelamiento suelen ser aceptables. Cronometre una restauración de prueba para conocer la duración real.
- Bases de datos más grandes o con más actividad. Configure la replicación del servidor antiguo al nuevo, deje que se ponga al día y promueva la réplica en el cutover. Así, el congelamiento se reduce al tiempo necesario para detener las escrituras y confirmar que la réplica está al día.
- Cargas de archivos y contenido de usuarios. Si los usuarios suben archivos continuamente, incluya los directorios de carga en la sincronización final o apunte temporalmente las cargas a un almacenamiento de objetos compartido al que puedan acceder ambos lados.
Verifique los datos, no los dé por buenos. Compare el número de filas de las tablas clave, los checksums o el número de archivos del almacenamiento, y el ID del pedido, la publicación o el registro más reciente en ambos lados.
Migre el correo electrónico como un proyecto independiente
El correo electrónico suele estar en la misma cuenta de hosting compartido que el sitio web, y falla de otra manera. Trátelo como una línea de trabajo aparte, con su propio momento de cutover, aunque el destino sea el mismo proveedor.
Cree primero los buzones en la nueva plataforma y luego copie el correo existente con una herramienta de sincronización IMAP, ejecutando una pasada incremental final después de cambiar los registros MX. Publique los registros SPF, DKIM y DMARC de los nuevos servidores de envío antes del cambio, y mantenga el servidor antiguo aceptando correo durante al menos una semana para que no se rechacen los mensajes de remitentes con DNS desactualizado.
Escriba el plan de cambio y el plan de reversión
Un plan de cutover es un runbook numerado con horarios, responsables y una decisión de seguir o detenerse en cada paso crítico. Ensáyelo al menos una vez sobre una copia en staging, cronometrando cada paso, para que la ventana real no depare sorpresas.
Una secuencia típica es la siguiente: anunciar la ventana, activar una página de mantenimiento o poner la aplicación en modo de solo lectura, ejecutar la sincronización final de archivos y de la base de datos, ejecutar las verificaciones, actualizar los registros DNS, probar el nuevo entorno a través de su nueva dirección y, después, volver a habilitar las escrituras.
Decida de antemano qué condiciones lo activan (por ejemplo, errores en el checkout por encima de una tasa acordada o una verificación de datos fallida) y quién tiene autoridad para ordenarlo. Mantenga el entorno antiguo intacto y en funcionamiento durante 7 a 14 días.
Validar y después optimizar
La validación empieza en el momento en que cambia el DNS y continúa durante varios días. Haga pruebas desde fuera de su red, y desde más de un país si sus usuarios son internacionales.
- Verificaciones funcionales. Página de inicio, inicio de sesión, búsqueda, formularios, checkout y cualquier transacción crítica para el negocio, ejecutados de extremo a extremo con cuentas de prueba.
- Verificaciones técnicas. TLS válido en cada nombre de host, redirecciones correctas, sin advertencias de contenido mixto, códigos de estado HTTP correctos en un rastreo de las URL clave y logs de errores limpios.
- Trabajo en segundo plano. Confirme que los cron jobs se ejecutaron según lo programado, que las colas se vacían, que los respaldos se completaron y que el correo saliente se entrega.
- Integraciones. Pida a los socios que actualicen sus listas de IP permitidas y luego confirme que los callbacks de pago y los webhooks llegan al nuevo entorno.
Las migraciones suelen empezar con un dimensionamiento conservador, así que revise las métricas de CPU, memoria y disco tras una o dos semanas de tráfico real y ajuste el tamaño hacia arriba o hacia abajo. Active la caché de objetos (por ejemplo, Redis) y una CDN para los recursos estáticos, ajuste la configuración de memoria de la base de datos al nuevo hardware y defina los umbrales de alerta a partir de las líneas base observadas en lugar de los valores predeterminados. Por último, haga una restauración de prueba desde el nuevo sistema de respaldo.
Lista de verificación de migración paso a paso
- De dos a cuatro semanas antes. Complete el inventario, asigne responsables, defina el congelamiento de escrituras y los objetivos de pérdida de datos, y elija la ventana de cutover.
- Dos semanas antes. Aprovisione el nuevo entorno, iguale las versiones de los entornos de ejecución, despliegue la aplicación en staging y haga una copia completa inicial de los datos.
- Una semana antes. Ensaye el cutover en staging, cronometre cada paso, finalice el runbook y los criterios de reversión, y confirme el acceso al registrador y al DNS.
- Cuarenta y ocho horas antes. Reduzca los TTL a 300 segundos, inicie sincronizaciones incrementales diarias o la replicación de la base de datos, y avise a los usuarios y socios.
- Día del cutover. Active la página de mantenimiento, ejecute la sincronización final, ejecute las verificaciones de datos, cambie los registros DNS y MX, valide a través de la nueva dirección y vuelva a habilitar las escrituras.
- Primeras 72 horas. Supervise los errores y el rendimiento, ejecute verificaciones funcionales a diario, sincronice el correo restante y mantenga lista la ruta de reversión.
- Al cabo de dos semanas. Ajuste el tamaño de los recursos, active la caché y la CDN, pruebe una restauración completa, devuelva los TTL a sus valores normales y desmantele el entorno anterior.
Cómo puede ayudar Vonahost
La nube gestionada de Vonahost funciona en la plataforma propia de Vonahost, en AWS o en Google Cloud, con CDN, respaldos, SSL, monitoreo, entornos de staging, Redis y Elasticsearch incluidos. Usted elige el país donde funciona cada servidor, y los datos no se trasladan sin su aprobación.
Si está planificando la salida de un hosting compartido o de un servidor antiguo, Vonahost puede revisar su inventario y proponer un entorno de destino. Cada propuesta indica la configuración, la ubicación, las responsabilidades de cada parte y el precio mensual en dólares estadounidenses, para que el alcance de la migración quede claro antes de empezar el trabajo.