Checklist de migración: qué saber antes de mover nada
Las migraciones que acaban mal casi nunca fallan al copiar datos. Fallan porque aparece una dependencia que nadie apuntó, o porque el plan de vuelta se improvisó a las tres de la mañana. Esta guía es la lista que usamos nosotros, publicada para que la uses aunque no trabajes con nosotros.
El inventario va primero
Antes de decidir a dónde vas, documenta qué tienes. No como diagrama de arquitectura idealizado, sino como lista honesta de lo que hay encendido hoy.
- Servidores: sistema operativo, versión, función real (no la del nombre del host) y quién lo administra.
- Aplicaciones: cuáles se usan, quién las usa y cuáles llevan meses sin abrirse.
- Dependencias: qué habla con qué. La aplicación que nadie recordaba suele aparecer aquí.
- Licencias y certificados: qué caduca, qué está ligado a hardware y qué es transferible.
- Tareas programadas e integraciones con terceros: son las que se rompen en silencio.
Clasifica por criticidad, no por tamaño
El servidor más grande no es el más importante. La pregunta correcta por sistema es doble: ¿cuánta información puedes perder? y ¿cuánto tiempo puedes estar sin él antes de que duela de verdad?
Esas dos respuestas son el RPO y el RTO de cada sistema, y condicionan el orden de la migración y la estrategia de copias. Si aún no los tienes definidos, la guía de RPO y RTO de este centro explica cómo fijarlos sin autoengaño.
La ventana de corte
El corte se diseña, no se sufre. Con días de antelación: baja el TTL del DNS para que el cambio propague en minutos y no en horas, congela los cambios en los sistemas afectados y avisa a los usuarios con fecha y hora.
Y antes del corte real, un ensayo: una migración de prueba sobre datos reales te dice cuánto tarda de verdad y qué se rompe, cuando todavía no importa.
El plan de vuelta se escribe antes
Define el criterio go/no-go por escrito: qué tiene que funcionar, a qué hora se evalúa y quién decide. Si a esa hora no se cumple, se vuelve al entorno original — que sigue intacto precisamente porque el plan lo exigía.
Un plan de vuelta que se improvisa durante el incidente no es un plan: es una esperanza con prisa.
Qué probar antes de dar el corte por bueno
- Accesos: usuarios reales entrando por el camino real, no el administrador desde la consola.
- Los procesos de negocio críticos de punta a punta: un pedido, una factura, una nómina.
- Rendimiento comparado: mide antes de migrar para poder comparar después con datos.
- Las copias del entorno nuevo: la primera restauración de prueba, la primera semana.
- La monitorización: que alguien se entere si algo falla el segundo día, no el visitante.
Los errores que más vemos
- Migrar todo de golpe en una sola ventana, cuando el orden por criticidad permitía hacerlo por fases.
- No medir el rendimiento previo: sin línea base, cualquier lentitud posterior es una discusión sin datos.
- Dejar las integraciones de terceros para el final: pasarelas, bancos y APIs tienen sus propios plazos.
- Tratar el DNS como un detalle: un TTL de 24 horas convierte un corte limpio en un día de deriva.
- No definir quién decide el go/no-go: a las 3:00 todo el mundo opina y nadie decide.
Cómo encaja esto si trabajamos juntos
Nuestro proceso empieza por un discovery que produce exactamente este inventario, con criticidad y dependencias documentadas. La migración se ejecuta con ensayo, ventana pactada y plan de vuelta escrito — y si tu entorno actual ya está bien montado, el discovery lo dirá también.