Plan de migración a la nube: inventario, orden y retorno
Un plan de migración a la nube tiene cuatro partes: inventario, orden del traslado, entorno de pruebas y vía de regreso. Qué causa caídas y cómo evitarlas.
Equipo de rabbitclipPublicación: 6 min. de lectura
En breve
Un plan de migración a la nube consiste en hacer el inventario del sistema actual, ordenar las piezas según lo que depende de qué, probar cada paso sin tocar el sitio en producción y dejar una ruta de regreso a la organización anterior por si algo sale mal. Si a un plan le faltan estos cuatro pasos, el traslado no es una migración sino una apuesta. La señal de un traslado logrado no es la rapidez, sino que los usuarios no noten nada en absoluto.
La mayoría de los problemas de migración no nacen de la dificultad técnica, sino de una pieza olvidada: una tarea programada que corre en el servidor antiguo, una regla de correo o un ajuste que solo conocía una persona. Por eso la parte más valiosa de un plan no es la lista de tareas por hacer, sino un relato honesto de lo que existe.
¿Por dónde se empieza: cómo se elabora un inventario?
Un inventario es una lista escrita de todo lo que se va a trasladar: sitios, aplicaciones, bases de datos, almacenamiento de archivos, tareas programadas, nombres de dominio, certificados SSL, cuentas de correo y conexiones con terceros. Para cada elemento usted anota quién es su responsable, cuán crítico es y de qué depende.
La pregunta que más trabajo hace en esta etapa es qué ocurre si esta pieza se detiene. Si se detiene un formulario de reservas, se pierden ingresos; si se detiene una herramienta interna de informes, un informe llega con un día de retraso. Esa distinción decide el orden del traslado y el tiempo de interrupción que usted puede aceptar.
- Sitios, aplicaciones y las bases de datos que utilizan.
- Tareas programadas y scripts que corren en segundo plano.
- Registros de dominio, ajustes de DNS y certificados.
- Cuentas de correo y los reenvíos asociados a ellas.
- Conexiones con terceros como pagos, mapas y analítica.
¿En qué orden deben trasladarse las piezas?
La regla general es trasladar primero lo que tiene pocas dependencias y poco riesgo. Un entorno de pruebas o una herramienta interna sirven para un primer intento, porque un error cuesta poco y el equipo aprende el proceso. Los sistemas que tocan directamente a los clientes van después, cuando la rutina ya se ha asentado.
Las piezas que dependen unas de otras deben pensarse juntas. Si una aplicación y su base de datos funcionan en lugares distintos, el retraso entre ambas puede causar problemas de velocidad. Por eso trasladar un sistema en un solo paso, con sus piezas relacionadas, suele ser el camino más seguro.
¿Cómo se prueba sin tocar el sitio en producción?
Un entorno de pruebas es una copia construida sobre la nueva infraestructura y aún no abierta a los usuarios. Se toma una copia actual de la base de datos, se ejecuta la aplicación en el nuevo entorno y se prueba a mano cada flujo importante: inicio de sesión, envío de formularios, pago, notificación por correo, subida de archivos.
Después se observa el comportamiento bajo carga. Si el catálogo de productos de un fabricante de suelos recibe muchas visitas por la mañana, esa carga debe simularse también en el entorno de pruebas. Las mediciones de velocidad solo sirven para comparar si se toman de la misma manera antes y después del traslado.
Por último se elige la hora del cambio. Un traslado hecho en el tramo más tranquilo del tráfico reduce el efecto de cualquier contratiempo. Como los cambios de DNS tardan en propagarse, bajar el valor del TTL antes del traslado es un paso preparatorio aparte.
- Montar el nuevo entorno con una copia actual de los datos.
- Probar a mano los flujos de inicio de sesión, formulario, pago y correo.
- Simular el comportamiento en una hora de mucha carga.
- Medir la velocidad de la misma manera antes y después del traslado.
¿Por qué se escribe primero la vía de regreso?
Un plan de reversión es el relato escrito de qué pasos le devuelven a la organización anterior, y cuánto tardan, si algo sale mal durante el traslado. Se prepara antes del traslado, porque pensar con calma cuesta una vez que el problema ha llegado. Mantener el sistema antiguo funcionando sin cambios durante un tiempo tras el traslado es la base de este plan.
Una decisión importante para la reversión es dónde se escriben los datos. Los pedidos o formularios creados en el sistema nuevo tras el traslado pueden perderse si usted vuelve al antiguo. Por eso se acuerda de antemano cómo se mantendrán sincronizados los datos durante la ventana de migración, o cuándo se congelará la escritura.
¿Cuándo es mala elección pasar a la nube?
Si el sistema es pequeño, el tráfico es estable y el hosting actual funciona sin problemas, un traslado a menudo no aporta ninguna ganancia. El esfuerzo del traslado, la carga de gestionar la nueva organización y el riesgo de error permanecen, mientras que el beneficio es incierto. Un traslado necesita una razón: un límite de capacidad, una necesidad de continuidad o un proveedor actual insuficiente.
Trasladar justo antes de una campaña fuerte o de una temporada alta también es mal momento. Para un grupo de spas, las semanas previas a la avalancha de reservas de verano son un periodo en el que el equipo no tendrá tiempo de resolver problemas. Situar el traslado en un periodo tranquilo importa tanto como el plan.
¿Qué errores son frecuentes en una migración?
El error más habitual es saltarse el inventario e ir directamente al traslado. Una pieza olvidada aparece días después del traslado, en un momento que nadie esperaba. El segundo error es probar en el sitio en producción en lugar de en un entorno de pruebas, lo que convierte a sus usuarios en el equipo de pruebas.
El tercer error es apagar el sistema antiguo justo después del traslado. Un sistema antiguo que no se mantiene en paralelo durante un tiempo elimina la opción de volver atrás. El cuarto es dejar el traslado en el conocimiento de una sola persona; si el proceso no está escrito, nadie puede sustituirla cuando está ausente.
- Empezar a trasladar sin inventario.
- Probar en el sitio en producción en lugar de un entorno de pruebas.
- Apagar el sistema antiguo justo después del traslado.
- Dejar el proceso en la memoria de una sola persona.
Un plan de migración a la nube empieza con un inventario, se ordena según las dependencias, se prueba en un entorno aparte y se asegura con una vía de regreso. Cuando se saltan esos cuatro pasos, el riesgo de caída pasa a ser mayor que el traslado mismo. Si desea hablar de si su sistema actual merece la nube y de cómo debería planificarse el traslado, puede concertar una conversación de descubrimiento con rabbitclip.
Preguntas frecuentes
¿Cuánto dura una migración a la nube?
Depende del tamaño del sistema, del número de dependencias y del alcance de las pruebas. Un sitio pequeño puede trasladarse en un día o dos; un sistema formado por muchas piezas enlazadas puede tardar semanas.
¿Se caerá el sitio durante el traslado?
En un traslado bien planificado, los usuarios no notan ninguna caída. El nuevo entorno se monta y se prueba con antelación, y el cambio de DNS se hace en un momento de poco tráfico.
¿Es de verdad necesario un plan de reversión?
Sí. Decidir con calma cuesta una vez que el problema ha llegado. Mantener el sistema antiguo funcionando un tiempo y escribir los pasos de regreso evita que un contratiempo se convierta en una crisis.
¿Debo trasladarlo todo de una vez?
Normalmente no. Empezar por las piezas de bajo riesgo permite aprender el proceso y detectar errores a pequeña escala. Las piezas estrechamente enlazadas, sin embargo, deben trasladarse juntas.
