Cómo migrar una web sin perder datos: checklist paso a paso

La mayoría de las migraciones no fallan por el hosting de destino. Fallan por falta de plan. Esta es la checklist que uso en migraciones de producción, adaptada para que puedas seguirla aunque no vayas a ejecutarla tú mismo — al menos sabrás qué preguntar a quien la haga.

Por qué las migraciones salen mal

Los tres motivos más comunes de una migración fallida:

• No hay plan de rollback. Si algo sale mal a mitad de proceso, no hay forma de volver atrás rápido.
• Se corta el DNS sin preparación previa. El TTL no se ha bajado con antelación, así que el cambio tarda horas o días en propagar, y durante ese tiempo unos usuarios ven la web vieja y otros la nueva.
• Los datos "vivos" durante la migración se pierden. Pedidos, formularios o registros que entran mientras se hace la copia y el corte no quedan sincronizados.

Checklist previa (antes de tocar nada)

• Backup completo verificado — no solo hecho, sino restaurado en un entorno de prueba para confirmar que funciona.
• Inventario de todo lo que depende del entorno actual: cron jobs, certificados SSL, configuraciones de correo (SPF/DKIM/DMARC), integraciones con APIs externas, webhooks.
• Bajar el TTL del DNS a 300 segundos (5 min), al menos 24-48h antes del corte. Esto es lo que más gente olvida, y es lo que determina si el corte real dura 5 minutos o 2 días.
• Documentar credenciales y accesos del origen y el destino en un solo sitio seguro.

Durante la migración

• Clonar el entorno de destino y probarlo en una URL temporal (subdominio o IP directa) antes de tocar el DNS real.
• Verificar la base de datos migrada: no solo que existan las tablas, sino que los datos críticos (usuarios, pedidos, contenido) coincidan en número con el origen.
• Sincronización incremental si el sitio recibe tráfico/pedidos activos: una primera copia completa, y justo antes del corte, una sync de solo lo que ha cambiado desde entonces.
• Comprobar rutas, permalinks y redirecciones — es habitual que cambien las URLs internas al cambiar de servidor o de estructura de carpetas.

El corte (ventana de intervención)

• Elegir una ventana de bajo tráfico para el corte final.
• Poner el sitio de origen en modo mantenimiento justo antes del corte, para evitar que entren datos nuevos que no se van a migrar.
• Cambiar el DNS y monitorizar la propagación activamente (no asumir que "ya está", comprobarlo desde varias ubicaciones/DNS públicos).
• Verificación post-corte: SSL activo, formularios funcionando, pasarela de pago operativa (si aplica), correo entrante/saliente funcionando.

Después de migrar

• Monitorizar logs de errores las primeras 24-48h — muchos problemas de migración no aparecen el primer minuto, aparecen cuando un usuario real hace algo que no se probó (un checkout, un formulario concreto, una integración de terceros).
• Mantener el entorno de origen activo (sin recibir tráfico) durante al menos una semana como plan de contingencia, antes de darlo de baja definitivamente.
• Informe de lo migrado, para tener trazabilidad de qué se movió, cuándo, y qué se verificó.

La pregunta que de verdad importa

No es "¿puedo migrar yo mismo?" — con paciencia, casi cualquiera puede copiar archivos y una base de datos. La pregunta real es: ¿qué pasa si algo falla a mitad de proceso y tienes clientes activos en ese momento? Si la respuesta te genera dudas, ese es exactamente el punto donde tener un rollback probado (no solo planeado) marca la diferencia entre 5 minutos de downtime y un fin de semana perdido recuperando datos.