Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Un plan de migración define el orden, el tiempo y el enfoque específicos para migrar cargas de trabajo a Azure. Este plan convierte las estrategias de migración de alto nivel en secuencias de implementación accionables. Se basa en el plan de adopción de la nube abordando decisiones tácticas como la priorización de cargas de trabajo, la secuenciación de migración y los métodos de transferencia de datos.
Requisitos previos:Plan de adopción de la migración, zona de aterrizaje de Azure
Evaluación de la preparación y las aptitudes de migración
Una evaluación de preparación garantiza que el equipo tenga las aptitudes y el soporte técnico necesarios para ejecutar el plan de migración. En este paso se identifican las brechas de capacidad y se acelera el progreso a través del entrenamiento dirigido o el soporte técnico externo.
Evalúe las aptitudes de Azure del equipo. Revise la experiencia del equipo con los servicios de Azure, las herramientas de migración y la transición. Esta evaluación le ayuda a identificar brechas de conocimiento específicas y a determinar qué formación necesita el equipo para tener éxito.
Contacte asesoría externa cuando sea necesario. Si su equipo carece de experiencia con la migración a la nube, traiga Microsoft o un asociado de Microsoft. Los expertos externos pueden validar la estrategia de migración, recomendar las herramientas adecuadas y ayudar a establecer escalas de tiempo realistas. Esta compatibilidad reduce el riesgo y acelera la migración, especialmente para proyectos complejos o a gran escala.
Elección de la ruta de migración de datos
Una ruta de migración de datos es cómo se mueven los datos de la ubicación actual a Azure. La ruta de acceso correcta garantiza que las transferencias de datos sean seguras, rápidas y rentables. En primer lugar, compruebe qué conexiones de red tiene disponibles, ExpressRoute, VPN o Internet pública para comprender las opciones.
Utilice ExpressRoute cuando esté disponible. ExpressRoute proporciona una conexión privada dedicada a Azure que es más rápida y segura que las conexiones a Internet. Si ya tiene ExpressRoute o planea obtenerlo, use este método para todas las cargas de trabajo. Tenga en cuenta que ExpressRoute requiere tiempo de instalación y tiene costos de transferencia de datos.
Use VPN si ExpressRoute no está disponible. Elija una VPN cuando necesite una transferencia de datos segura, pero no tenga ExpressRoute. Una VPN crea un túnel cifrado a través de Internet en Azure, aunque suele ser más lento que ExpressRoute. Asegúrese de que tiene una instancia de VPN Gateway configurada en Azure antes de empezar.
Use Azure Data Box para grandes cantidades de datos. Data Box es mejor para migraciones sin conexión con muchos datos. Microsoft le envía un dispositivo físico para copiar los datos y, a continuación, lo envía de vuelta. Esta opción evita el uso de la red, pero tarda más tiempo debido al tiempo de envío.
Use la red pública de Internet para datos menos confidenciales. Esta opción funciona cuando los datos no necesitan cifrado y no se puede usar ExpressRoute o Data Box. Aunque este método está disponible en todas partes, es el menos seguro y puede ralentizar sus otras actividades de Internet.
| Ruta de migración de datos | Cuándo usar | Pros | Cons |
|---|---|---|---|
| ExpressRoute | Cualquier carga de trabajo cuando esté disponible | Seguro y rápido | Configuración necesaria, costos de dinero |
| VPN | Transferencias seguras cuando no hay ExpressRoute | Más seguro que la red pública de Internet | Requiere la instalación, más lenta que ExpressRoute. |
| Azure Data Box | Migración sin conexión con grandes cantidades de datos | Mueve datos sin usar la red | Método más lento debido al envío |
| Red pública de Internet | Datos no sensibles y no pueden usar Data Box | Funciona en todas partes | Menos seguro, usa el ancho de banda |
Determinación de la secuencia de migración
La secuenciación de la migración reduce el riesgo y crea la confianza del equipo estableciendo un orden lógico para la migración de cargas de trabajo. La secuencia determina qué cargas de trabajo se mueven primero y cómo se migran los componentes dependientes para evitar interrupciones del servicio. Organice carteras grandes en oleadas de migración. Para obtener instrucciones detalladas sobre el planeamiento de oleadas, consulte Planeamiento de oleadas de migración.
Búsqueda de dependencias
Detecte primero todas las dependencias. Las dependencias entre cargas de trabajo provocan interrupciones del servicio si no se migran juntas. Asigne dependencias internas y externas para detectar estas conexiones antes de crear grupos de migración.
Analice los tipos de dependencia y la importancia crítica. Los distintos tipos de dependencia requieren enfoques de migración diferentes. Distinguir entre estas categorías:
Tipo de dependencia Description Enfoque de migración Dependencias directas Requerir comunicación inmediata y baja latencia entre los componentes. Mueva todos los componentes conectados directamente juntos para mantener el rendimiento y evitar interrupciones. Dependencias indirectas Implique interacciones ocasionales o no críticas entre sistemas. Migre juntas o en ondas independientes si la conexión tolera la latencia o admite el uso híbrido. Dependencias empresariales Dependa de las relaciones organizativas o de administración. Agrupe y migre las cargas de trabajo relacionadas y los sistemas de informes para alinearse con las prioridades empresariales. Agrupar las cargas de trabajo por relaciones de dependencia. Cree grupos basados en bases de datos compartidas, API, servicios de autenticación o conexiones de red. Estos grupos forman la base de las oleadas de migración y garantizan que todos los componentes necesarios para la funcionalidad se muevan juntos. Cuando existe incertidumbre sobre la importancia de la dependencia, agrupe los componentes. Este enfoque conservador proporciona flexibilidad para la separación futura.
Documente sistemáticamente cada grupo de dependencias. Etiquete los recursos en función de sus grupos de dependencias mediante convenciones de nomenclatura coherentes. Documente cada grupo con:
- Nombre de grupo e identificador : identificador único y nombre descriptivo
- Inventario de componentes : todos los elementos de infraestructura, aplicaciones y servicios
- Dependencias críticas : conexiones esenciales que requieren un control especial
- Restricciones de migración : requisitos empresariales, técnicos o de tiempo
Valide la integridad del grupo. Confirme que cada grupo incluye todos los componentes necesarios para que funcionen las aplicaciones, incluida la infraestructura auxiliar, como equilibradores de carga, registros DNS o capas de almacenamiento en caché.
Gestionar operaciones en entornos divididos
Planifique las dependencias inamovibles. Identifique los componentes que deben permanecer en el entorno de origen debido a motivos técnicos o normativos. Documente por qué no se pueden mover, cómo se conectan a otros sistemas y qué datos comparten. Esta documentación le ayuda a crear estrategias para que estos componentes funcionen sin problemas con los sistemas en la nube.
Minimice el tiempo de operación del entorno dividido. Cuando los componentes pueden moverse a la nube más adelante, pero no inmediatamente, documenten sus conexiones y flujos de datos con sistemas en la nube. Cree un plan claro con cronogramas y estrategias de gestión de riesgos para reducir el tiempo de operación de la carga de trabajo en múltiples entornos. Considere la posibilidad de retrasar la migración hasta que más componentes puedan moverse juntos.
Conectar entornos de forma eficaz. Use métodos de integración como puertas de enlace de API, colas de mensajes y sincronización de datos para crear conexiones confiables entre las cargas de trabajo en la nube y los componentes del entorno de origen. Estos enfoques reducen los retrasos, mejoran la seguridad y preparan la manera de mover finalmente los componentes restantes a la nube.
Priorizar las cargas de trabajo para migrar
Revise los detalles de la carga de trabajo. Trabaje con las partes interesadas para revisar los detalles técnicos y empresariales de cada carga de trabajo. Asegúrese de que el tiempo de inactividad o los impactos en los errores se entienda bien y se alinee con las prioridades empresariales actuales. Utilice el plan de adopción de la migración para comprobar detalles como la unidad de negocio, el propietario de la carga de trabajo, las dependencias técnicas y la clasificación de criticidad. Estos detalles ayudan a priorizar y secuenciar cargas de trabajo de forma eficaz.
Priority Valor empresarial Effort Description High High Low Ganancias rápidas: migrar primero para un impacto inmediato Medio-Alto High High Inversiones estratégicas: planifique cuidadosamente con recursos adecuados Medio-Bajo Low Low Candidatos fáciles: rellenar las brechas entre las migraciones principales Low Low High Evitar o aplazar: centrar los recursos en oportunidades de mayor valor Comience con cargas de trabajo más sencillas para reducir el riesgo. Comience a migrar cargas de trabajo menos complejas y que tengan un riesgo menor. Este enfoque ayuda a su equipo a obtener confianza y a refinar los procesos de migración antes de abordar cargas de trabajo más difíciles. Tener como destino herramientas internas, entornos de desarrollo o aplicaciones de bajo uso con arquitecturas independientes y puntos de integración mínimos.
Mueva los entornos no productivos antes que los de producción. Los entornos que no son de producción proporcionan un espacio seguro para probar el proceso de migración completo. Migre entornos de desarrollo, almacenamiento provisional y control de calidad antes de la producción para validar la preparación. Este orden permite a los equipos probar configuraciones, rendimiento y procedimientos de recuperación sin afectar a los usuarios. Use migraciones que no sean de producción para entrenar equipos de operaciones.
Planifique los sistemas críticos después de demostrar el éxito inicial. Las aplicaciones críticas requieren funcionalidades de migración probadas antes de moverlas a Azure. Planee estas migraciones para las fases posteriores cuando su equipo demuestre competencia con los servicios de Azure. Las fechas límite empresariales, como los ciclos de actualización de hardware, pueden requerir que priorice las aplicaciones críticas anteriormente con más medidas de seguridad y períodos de prueba extendidos.
Incluya cargas de trabajo complejas representativas para probar escenarios. Agregue una o dos cargas de trabajo complejas a cada fase inicial para exponer los desafíos a los que se enfrenta con aplicaciones críticas para la misión. Elija cargas de trabajo que representen patrones comunes, como aplicaciones de varios niveles o sistemas dependientes de la base de datos.
Creación de una programación de migración detallada
Establezca fechas de inicio y finalización para cada migración. Incluya el tiempo de búfer para probar y resolver problemas para garantizar una ejecución fluida. Esta programación detallada reduce el riesgo de retrasos y admite la planificación eficaz de recursos.
Alinee las escalas de tiempo con los eventos empresariales. Evite programar migraciones durante períodos empresariales críticos, como cierre financiero, lanzamientos de productos o temporadas vacacionales. Esta alineación reduce el riesgo de interrupción empresarial y garantiza la confianza de las partes interesadas.
Use herramientas de administración de proyectos para realizar un seguimiento del progreso. Use herramientas como Azure DevOps para administrar dependencias, realizar un seguimiento de los hitos y comunicar los cambios de forma eficaz. Estas herramientas proporcionan visibilidad sobre el progreso de la migración y admiten la resolución proactiva de problemas.
Elección del método de migración para cada carga de trabajo
Los métodos de migración se dividen en dos categorías: migración con tiempo de inactividad y migración con casi cero tiempo de inactividad. Elija el mejor método de migración para cada carga de trabajo en función de su tolerancia al tiempo de inactividad y la importancia empresarial.
Elija la migración durante el tiempo de inactividad para las cargas de trabajo que toleran interrupciones planeadas. La migración de tiempo de inactividad es más sencilla y rápida porque no requiere sincronización en tiempo real entre entornos de origen y de destino. Este método funciona bien para cargas de trabajo no críticas, como entornos de desarrollo, sistemas de prueba o aplicaciones con ventanas de mantenimiento programadas. Documente la duración de tiempo de inactividad aceptable para cada carga de trabajo y programe migraciones durante períodos de bajo uso para minimizar los efectos empresariales.
Elija una migración de tiempo de inactividad casi cero para cargas de trabajo críticas. La migración de tiempo de inactividad casi cero garantiza que las cargas de trabajo críticas permanezcan operativas durante la transición a través de técnicas continuas de replicación y transición de datos. Este método es esencial para las aplicaciones orientadas al cliente, los sistemas de transacciones en tiempo real o las cargas de trabajo con contratos estrictos de nivel de servicio. Compruebe que la arquitectura de carga de trabajo admite la replicación continua y que el ancho de banda de red puede controlar la transferencia de datos en tiempo real. Pruebe los procesos de conectividad y replicación en un entorno que no sea de producción para confirmar la preparación de este método de migración.
| Método de migración | Cuándo usar | Pros | Cons |
|---|---|---|---|
| Migración durante el tiempo de inactividad | Cargas de trabajo no críticas, entornos de desarrollo | Proceso más sencillo, ejecución más rápida | Interrupción del servicio necesaria |
| Migración con casi cero tiempo de inactividad | Cargas de trabajo críticas, acuerdos de nivel de servicio estrictos | Interrupción mínima del servicio | Configuración compleja y requiere pruebas |
Definición del plan de reversión
Un plan de reversión permite a los equipos revertir rápidamente los cambios cuando se produce un error en una implementación o se produce un riesgo. Un plan bien definido minimiza el tiempo de inactividad, limita el impacto empresarial y mantiene la confiabilidad del sistema. Establezca siempre criterios y procedimientos de reversión antes de iniciar cualquier migración o implementación.
Definir implementación fallida. Colabore con las partes interesadas de la empresa, los propietarios de cargas de trabajo y los equipos de operaciones para decidir qué se considera un despliegue fallido. Algunos ejemplos son las comprobaciones de estado con errores, el rendimiento deficiente, los problemas de seguridad o las métricas de éxito no cumplidas. Esta definición garantiza que las decisiones de reversión se alineen con la tolerancia al riesgo de su organización. Incluya condiciones específicas que desencadenen una reversión en el plan de implementación, como límites de uso de CPU, umbrales de tiempo de respuesta o tasas de error. Esta evaluación hace que las decisiones de reversión sean claras y coherentes durante los incidentes.
Automatice los pasos de rollback en los pipelines de CI/CD. Use herramientas como Azure Pipelines o Acciones de GitHub para automatizar los procesos de reversión. Por ejemplo, configure canalizaciones para volver a implementar una versión anterior si se produce un error en las comprobaciones de estado.
Cree instrucciones de retroceso específicas para la carga de trabajo. Desarrolle pasos de reversión que coincidan con el tipo de carga de trabajo, el entorno y el método de implementación. Por ejemplo, las implementaciones de infraestructura como código requieren volver a aplicar plantillas anteriores. Las reversiones de aplicaciones implican volver a implementar una imagen de contenedor anterior. Adjunte scripts de reversión, instantáneas de configuración y plantillas de infraestructura como código en su plan de reversión. Estos recursos permiten una ejecución rápida y reducen la dependencia de la intervención manual.
Procedimientos de reversión de pruebas. Simular fallos de implementación en un entorno de preproducción para validar la efectividad de la reversión. Identificar y resolver brechas en la automatización, los permisos o las dependencias. Confirme que la reversión restaura el sistema a un estado estable, conocido como correcto.
Mejora de las estrategias de reversión Después de cada evento de implementación o reversión, realice una retrospectiva para evaluar lo que funcionó y lo que no. Actualice los criterios de reversión, los procedimientos y la automatización en función de las lecciones aprendidas, los cambios arquitectónicos o las nuevas herramientas. Mantenga la documentación para asegurarse de que las estrategias de reversión sigan siendo actuales y eficaces.
Participación de las partes interesadas en el plan de migración
La aprobación de las partes interesadas valida el plan de migración cumple los requisitos empresariales y la tolerancia a riesgos. Debe obtener la aprobación formal antes de ejecutar migraciones.
Documente el plan de migración con justificación empresarial. Cree un plan estructurado que muestre el nombre de la carga de trabajo, el propietario, la importancia, el método de migración, la ventana de tiempo de inactividad y los efectos empresariales. Incluya la justificación de cada enfoque y explique cómo minimiza el riesgo.
Presentar procedimientos de reversión probados. Mostrar planes de reversión específicos con pasos, períodos de tiempo y criterios de éxito. Incluya funcionalidades automatizadas y manuales. Documente los resultados de la prueba de preproducción para demostrar una restauración rápida del servicio.
Valide las programaciones con restricciones empresariales. Revisar los cronogramas con las partes interesadas para evitar periodos críticos de negocio, congelaciones de mantenimiento y picos estacionales. Proporcione opciones alternativas con ventajas y desventajas si existen conflictos.
Obtenga la aprobación formal y la autoridad para revertir cambios. Obtener la aprobación escrita de las partes interesadas para el plan de migración y los procedimientos de reversión. Defina la autoridad de toma de decisiones y establezca canales de comunicación de emergencia.
Defina los criterios de éxito y revise los puntos de control. Establezca métricas medibles, incluidos los puntos de referencia de rendimiento, la validación de la funcionalidad y los criterios de aceptación del usuario. Programe puntos de revisión formales para tomar decisiones de seguir/no seguir.