Cargando páginas…

Planificar una migración cloud: qué decidir antes de trasladar sus sistemas

Antes de trasladar una aplicación a la nube, decida qué debe mejorar, qué sistemas tienen que seguir conectados y cómo recuperará el servicio si no puede completar la transición. Esas decisiones darán forma al plan de migración.

Una propuesta de migración puede parecer completa si enumera los servidores y un destino. Las preguntas más difíciles se refieren al trabajo que esos servidores permiten realizar. ¿Puede el personal seguir procesando pedidos? ¿Cuándo se ejecuta una exportación programada? ¿Quién comprueba los registros después del traslado? Un plan de migración cloud debe vincular las decisiones de infraestructura con estas actividades cotidianas. La secuencia siguiente permite convertir un traslado general en un trabajo que se puede revisar.

En esta página

Defina la mejora operativa

Sustituya «migrar a la nube» por una razón que se pueda evaluar. Quizá las versiones dependan de un único servidor configurado manualmente, o un periodo de alta actividad exija una capacidad que el entorno actual no ofrece. Documente el comportamiento presente antes de especificar el futuro entorno. Sin esa referencia, resulta difícil saber si el traslado resolvió el problema original o simplemente cambió el lugar donde ocurre.

  • Identifique el flujo de trabajo afectado y a su responsable.
  • Describa una mejora observable, como un proceso de despliegue repetible.
  • Enumere las restricciones que debe respetar el traslado.

Trace las conexiones de cada carga de trabajo

Para cada aplicación, enumere su base de datos, almacenamiento de archivos, tareas programadas, servicios externos y requisitos de acceso. Pida a las personas que la operan que revisen el mapa. Un informe nocturno o una conexión con un proveedor pueden pasar desapercibidos en un inventario de servidores. Marque qué dependencias deben trasladarse juntas y qué conexiones pueden mantenerse durante una transición por etapas.

Elija un enfoque de migración para cada aplicación

Decisión ilustrativa: un portal de clientes utiliza un entorno de ejecución con soporte, pero comparte una base de datos con una aplicación contable antigua. Migrar primero el portal solo podría ser razonable si la conexión con la base de datos que permanece cumple los requisitos acordados de acceso y rendimiento. En caso contrario, traslade juntas las cargas de trabajo conectadas o resuelva antes la dependencia. Compare una migración directa, cambios específicos y un nuevo desarrollo según las necesidades de esta aplicación; no es necesario aplicar un único enfoque a todo el conjunto de sistemas.

Diseñe cómo se operará el nuevo entorno

Asigne responsables para los accesos, despliegues, alertas, copias de seguridad y revisiones del gasto. Estime la demanda con la información de uso disponible, incluidos los periodos de menor actividad y los picos. Examine cómo cambia la estimación cuando crece el almacenamiento o se transfieren datos entre servicios. Una conversación útil sobre costes explica sus supuestos y qué se monitorizará después del lanzamiento, en lugar de tratar la primera estimación como una factura operativa fija.

  • ¿Quién puede cambiar la configuración de producción?
  • ¿Quién responde cuando falla una tarea?
  • ¿Cómo se comprobará la restauración de las copias de seguridad?

Defina cuándo revertir antes del cambio de entorno

Para el portal del ejemplo, acuerde cómo verificará el equipo el inicio de sesión, el envío de pedidos y los recuentos de registros antes de abrir el nuevo entorno. Defina qué fallos detendrán la transición y quién tomará esa decisión. Si los usuarios pueden crear registros nuevos tras el cambio, no basta con devolver el tráfico al servidor antiguo: esos registros necesitan un plan de tratamiento acordado. Ensaye la secuencia, incluido el punto a partir del cual revertir exige trabajo adicional sobre los datos.

Cierre la migración con comprobaciones operativas

Después del traslado, revise los flujos de trabajo, las tareas programadas, las alertas y los patrones de uso frente a la referencia acordada. Asigne un responsable a cada incidencia pendiente. Retire el entorno antiguo solo cuando el equipo haya completado las comprobaciones de transición y decidido qué datos o configuración deben conservarse. Mantenga el mapa de aplicaciones y las instrucciones de recuperación a disposición de quienes vayan a mantener el servicio.