Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Mejores prácticas para migraciones grandes Las grandes migraciones pueden convertirse en un desafío, según los factores que rigen el funcionamiento de una organización. En esta sección se describen algunos de los factores clave que pueden simplificar las grandes migraciones si se abordan durante las fases iniciales del esfuerzo y se hace un seguimiento a lo largo del proyecto. Las siguientes prácticas recomendadas para migraciones grandes se basan en los datos recopilados de otros clientes. Las mejores prácticas se dividen en tres categorías: + People + Tecnología + Processes # Perspectiva de las personas Esta sección se centra en las siguientes áreas clave de la perspectiva de las personas: + Apoyo ejecutivo: identificar a un líder de un solo hilo que esté capacitado para tomar decisiones + Colaboración y propiedad en equipo: colaboración entre varios equipos + Capacitación: capacita proactivamente a los equipos sobre las distintas herramientas ## Apoyo ejecutivo **Contents** + [Identifique un líder de un solo hilo](#leader) + [Alinee al equipo de liderazgo sénior](#align-leadership) ### Identifique un líder de un solo hilo Al iniciar una migración de gran envergadura, es importante identificar a un líder técnico de un solo subproceso que se dedique al cien por cien al proyecto y sea responsable. Ese líder está capacitado para tomar decisiones, ayudar a evitar los compartimentos aislados y agilizar los flujos de trabajo manteniendo prioridades coherentes. Un importante cliente internacional dedicado a la migración pudo pasar de tener un servidor por semana al principio del programa a más de 80 servidores por semana a principios del segundo mes. El pleno apoyo del CIO como líder de un solo subproceso fue fundamental para la rápida ampliación de los servidores que se estaban migrando. El CIO asistió a las reuniones semanales con el equipo de migración para garantizar la escalabilidad y la resolución de los problemas en tiempo real, lo que aceleró la velocidad de la migración. ### Alinee al equipo de liderazgo sénior Es importante alinear los distintos equipos con respecto a los criterios de éxito de la migración. Si bien un equipo pequeño y dedicado puede planificar e implementar la migración, surgen desafíos a la hora de definir la estrategia y realizar actividades periféricas. Estos posibles obstáculos pueden requerir acciones o escalamientos por parte de diferentes áreas de la organización de TI, incluidas las siguientes: + Usuarios + Aplicaciones + Red + Seguridad + Infraestructura + Proveedores externos La acción directa de los propietarios de las aplicaciones, el liderazgo, la alineación y un claro ascenso al líder de un solo subproceso son cada vez más importantes. ## Colaboración y propiedad en equipo **Contents** + [Cree un equipo multifuncional de habilitación de la nube](#cross-function) + [Defina con antelación los requisitos para los equipos y las personas ajenas al equipo principal de migración](#define-reqs) + [Valide que no haya problemas de licencia al migrar las cargas de trabajo](#licensing) ### Cree un equipo multifuncional de habilitación de la nube **Contents** Un primer paso fundamental en un gran proyecto de migración es permitir que la organización trabaje en la nube. Para lograrlo, recomendamos crear un [motor de habilitación de la nube](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf) (CEE). La CEE es un equipo capacitado y responsable que se centra en la preparación operativa de la organización para las migraciones a. AWS La CEE debe ser un equipo multifuncional que incluya representantes de la infraestructura, las aplicaciones, las operaciones y la seguridad. El equipo tiene las siguientes responsabilidades: + Desarrollo de políticas + Definir e implementar las herramientas, los procesos y las arquitecturas que establecerán el modelo de operaciones en la nube de la organización + Seguir facilitando la alineación de las partes interesadas en todas las áreas que representan Un cliente del sector sanitario no comenzó con una CEE. Sin embargo, mediante las migraciones piloto iniciales, se identificó la brecha. En vísperas de la fecha límite definitiva para la migración, con plazos muy estrictos, el equipo instaló una sala de guerra *migratoria*. En la sala de guerra contra la migración, las partes interesadas de la infraestructura, la seguridad, las aplicaciones y las empresas podían ayudar a resolver los problemas. ### Defina con antelación los requisitos para los equipos y las personas ajenas al equipo principal de migración Identifique los equipos y las personas que están fuera del programa principal y defina su participación durante las fases de planificación de la migración. Para facilitar el impulso de la migración durante las etapas posteriores, preste especial atención a la participación de los equipos de aplicaciones. Serán necesarios sus conocimientos sobre la aplicación, su capacidad para diagnosticar problemas y la necesidad de aprobar la transición. Si bien la migración estará dirigida por un equipo central, es probable que los equipos de aplicaciones participen en la validación del plan de migración y en las pruebas durante la transición. Los clientes suelen abordar la migración a la nube como un proyecto de infraestructura y no como una migración de aplicaciones. Esto puede provocar problemas durante la migración. Recomendamos tener en cuenta la participación necesaria del equipo de aplicaciones a la hora de seleccionar una estrategia de migración. Por ejemplo, una estrategia de rehospedaje requiere menos participación del equipo de aplicaciones en comparación con una estrategia de replataforma o refactorización en la que se está cambiando una mayor parte del panorama de las aplicaciones. Si la disponibilidad de los propietarios de la aplicación es limitada, considere la posibilidad de utilizar estrategias de realojamiento o replataforma en lugar de refactorizar, reubicar o recomprar. ### Valide que no haya problemas de licencia al migrar las cargas de trabajo Las licencias pueden cambiar al migrar los productos corporativos listos para usar a la nube. Es posible que sus acuerdos de licencia se centren en su entorno local. Por ejemplo, una licencia puede ser por CPU o estar vinculada a una dirección MAC específica. Como alternativa, es posible que los acuerdos de licencia no incluyan el derecho a alojar en un entorno de nube pública. Sin embargo, la renegociación de las licencias con los proveedores puede implicar plazos de entrega prolongados y supone un gran obstáculo para la migración. Recomendamos colaborar con sus equipos de aprovisionamiento o administración de proveedores tan pronto como se defina el alcance de la migración. Las licencias también pueden influir en la arquitectura objetivo y en los patrones de migración. ## Formación **Contents** + [Capacite a los equipos sobre nuevas herramientas y procesos](#tools-training) ### Capacite a los equipos sobre nuevas herramientas y procesos Una vez definida la estrategia de migración, invierta tiempo en comprender qué formación podría ser necesaria para la migración y para su modelo operativo objetivo. Durante la migración, es probable que utilice herramientas nuevas para su organización AWS Database Migration Service, por ejemplo. La formación proactiva de los equipos reduce los retrasos que se producen durante las fases de migración. Recomendamos buscar métodos activos de transferencia de conocimientos que brinden la oportunidad de experimentar con las herramientas de forma práctica. Por ejemplo, AWS Professional Services impartió varias sesiones de formación a Cloud Migration Factory para tres AWS socios integradores de sistemas (SI) responsables de una migración importante. Esto garantizó que el equipo tuviera una familiaridad básica al pasar a la fase de migración. También ayudó a identificar a expertos en la materia (SMEs) que podrían servir como primera línea de escalamiento dentro de cada equipo de SI AWS Partner. # Perspectiva tecnológica La tecnología proporciona una base excelente para acelerar las grandes migraciones. Por ejemplo, la solución Cloud Migration Factory se centra en cómo end-to-end automatizar las migraciones. En esta sección, se analizan algunas de las mejores prácticas para usar la tecnología a fin de lograr la escala y la velocidad requeridas, en consonancia con el alcance, la estrategia y los plazos. El principio general es analizar las áreas de automatización siempre que sea posible. Si dispone de miles de servidores, realizar las tareas manualmente puede resultar un esfuerzo costoso y lento. Para realizar una migración, normalmente se utilizan varias herramientas, como las siguientes: + Discovery + Implementación de la migración + Base de datos de gestión de la configuración (CMDB) + Hoja de cálculo de inventario + Administración de proyectos Estas herramientas se utilizan en las diferentes etapas de las migraciones, desde la evaluación y la movilización hasta la implementación. La selección de estas herramientas depende de los objetivos y plazos empresariales. Una vez planificadas las fases de migración, el siguiente paso es garantizar que el equipo de migración tenga las habilidades necesarias para utilizar las herramientas que necesitará. Si un equipo carece de las habilidades o la experiencia, planifique capacitaciones específicas para aumentar el conjunto de habilidades. Si es posible, organice eventos en los que los equipos puedan adquirir experiencia con las herramientas de migración en un entorno seguro. Por ejemplo, ¿hay servidores de laboratorio o de laboratorio que los equipos puedan migrar para experimentar con las herramientas? Alternativamente, ¿es aceptable que las cargas de trabajo de desarrollo iniciales se utilicen con fines de aprendizaje? ## Automatización, seguimiento e integración de herramientas **Contents** + [Automatice el descubrimiento de la migración para reducir el tiempo necesario](#discovery) + [Automatice las tareas repetitivas](#repeating) + [Automatice el seguimiento y los informes para acelerar la toma de decisiones](#decision) + [Explore las herramientas que pueden facilitar su migración](#tooling) ### Automatice el descubrimiento de la migración para reducir el tiempo necesario La mayoría de los grandes programas de migración comienzan por comprender el alcance de la migración (qué debe migrarse) y por desarrollar una estrategia (cómo se migrará). El descubrimiento es un aspecto importante de esto. Los puntos de metadatos necesarios se capturan para formar un árbol de decisiones sobre la estrategia de migración. Para migrar las cargas de trabajo a buen ritmo, debe identificar e importar los metadatos de migración necesarios a sus procesos de implementación, como una fábrica de migraciones. Un mecanismo totalmente automatizado para extraer, transformar y cargar (ETL) los metadatos de la migración reduce considerablemente el tiempo y el nivel de esfuerzo que implica el proceso de descubrimiento. Un cliente desarrolló un proceso de ingesta de datos totalmente automatizado para su fábrica de migraciones. El plan de migración con todos los metadatos de migración se alojó y mantuvo en una hoja de cálculo en Microsoft SharePoint. Cuando se hacían cambios en la fuente, se iniciaba una AWS Lambda función para cargar los datos en la fábrica de migración sin intervención manual. Este proceso automatizado de entrada de datos ayudó al cliente a reducir el trabajo manual, minimizar los errores humanos y acelerar su velocidad. Pudieron migrar más de 1000 servidores a AWS. ### Automatice las tareas repetitivas En la fase de implementación de la migración, muchos procesos pequeños deben repetirse con frecuencia. Al utilizar AWS Application Migration Service (MGN), por ejemplo, debe instalar el agente en cada servidor que esté incluido en el ámbito de la migración. Crear una fábrica de migraciones que se adapte a sus requisitos empresariales y técnicos específicos es la forma más eficaz de lograr la eficiencia y la velocidad necesarias para realizar una migración a gran escala con éxito. Una fábrica de migración proporciona un marco de integración y organización que utiliza un conjunto de datos estandarizado para acelerar la migración. Una vez identificadas todas las tareas, dedique tiempo a automatizar todas las tareas manuales que se puedan automatizar junto con los manuales de instrucciones prescriptivos. La solución [Cloud Migration Factory](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html) es un ejemplo de ello. Cloud Migration Factory está diseñada para proporcionar las bases de automatización de la migración sobre las que puede automatizar aspectos específicos de su organización. Por ejemplo, es posible que desee actualizar un indicador en su CMDB para indicar que los servidores locales ahora se pueden retirar del servicio. En este escenario, podrías crear una automatización que realice esta tarea al final de la oleada de migración. Cloud Migration Factory tiene un almacén de metadatos centralizado con todos los metadatos de la oleada, de las aplicaciones y del servidor. El script de automatización puede conectarse a Cloud Migration Factory para obtener una lista de los servidores de esa oleada y realizar las acciones correspondientes. Cloud Migration Factory es compatible [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html). ### Automatice el seguimiento y los informes para acelerar la toma de decisiones Recomendamos crear un panel de informes de migración automatizado para rastrear y reportar los datos en tiempo real, incluidos los indicadores clave de rendimiento (KPIs) del programa. Los proyectos de migración involucran a partes interesadas de toda la organización, incluidas las siguientes: + Equipos de aplicaciones + Evaluadores + Equipos de desmantelamiento + Arquitectos + Equipos de infraestructura + Liderazgo Para desempeñar sus funciones, estas partes interesadas necesitan datos en tiempo real. Por ejemplo, los equipos de red deben conocer las próximas oleadas de migración para comprender el impacto en la conexión compartida entre los recursos locales y AWS. Los equipos de liderazgo quieren saber en qué parte de la migración se ha completado. Disponer de una transmisión automática y fiable de los datos en tiempo real evita los errores de comunicación y proporciona una base sobre la que se pueden tomar decisiones. Un importante cliente del sector sanitario estaba intentando cerrar su centro de datos con una fecha límite próxima. Dada la escala y la complejidad, inicialmente se dedicó una cantidad significativa de tiempo a rastrear y comunicar el estado de la migración entre las partes interesadas. Posteriormente, el equipo de migración utilizó [Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html) para crear paneles automatizados que visualizaban los datos, lo que simplificaba considerablemente el seguimiento y las comunicaciones y, al mismo tiempo, aumentaba la velocidad de migración. ### Explore las herramientas que pueden facilitar su migración Elegir las herramientas adecuadas para la migración no es fácil, especialmente si nadie de su organización ha gestionado antes una migración de gran envergadura. Recomendamos dedicar tiempo a elegir las herramientas adecuadas para respaldar la migración. Esta exploración puede implicar el coste de una licencia, pero puede suponer una relación costo-beneficio si se tiene en cuenta una iniciativa más amplia. Como alternativa, es posible que descubra que las herramientas integradas en su organización pueden ofrecer un resultado similar. Por ejemplo, es posible que ya tenga implementadas en todo su entorno herramientas de monitoreo del rendimiento de las aplicaciones, que pueden proporcionarle información de descubrimiento completa. Al principio, un cliente de tecnología se mostró reacio a utilizar herramientas de descubrimiento automatizadas durante su migración debido a la falta de familiaridad. Como resultado, un AWS socio de SI tenía que organizar entre 5 y 10 horas de reuniones por aplicación para descubrir el entorno manualmente, incluidos los nombres de los servidores, las versiones del sistema operativo y las dependencias. Se estimó que si se hubieran utilizado las herramientas de descubrimiento, el esfuerzo de descubrimiento podría haberse reducido en más de 1000 horas. ## Requisitos previos y validación posterior a la migración **Contents** + [Construye la landing zone durante la fase previa a la migración](#landing-zone) + [Describa las actividades previas](#outline) + [Implemente controles posteriores a la migración para seguir mejorando](#post-checks) ### Construye la landing zone durante la fase previa a la migración Recomendamos crear el entorno de AWS destino, o landing zone, con antelación, en lugar de crear las nubes privadas virtuales (VPCs) y las subredes de destino durante la ola de migración. Construir una landing zone bien diseñada es un requisito previo para la migración. La landing zone debe incluir controles de monitoreo, gobernanza, operativos y de seguridad. Crear y validar la landing zone antes de la migración minimiza la incertidumbre que conlleva la ejecución de las cargas de trabajo en un entorno nuevo. Una vez establecida la landing zone, las partes interesadas pueden centrarse en migrar las cargas de trabajo sin preocuparse por los aspectos gestionados a nivel de cuenta o VPC. ### Describa las actividades previas Además de la landing zone, es importante alinear otros requisitos técnicos previos a la migración, especialmente los procesos con plazos de entrega prolongados. Por ejemplo, realice los cambios necesarios en el firewall para permitir que los datos se repliquen de forma local a otra. AWS La comunicación temprana de los requisitos técnicos previos ayuda a preparar y asignar los recursos necesarios. Es habitual que las migraciones se detengan porque no se cumplen los requisitos previos. Esto no solo afecta a la ola de migración en curso, sino que también podría retrasar las fechas de todas las migraciones futuras mientras se soluciona el problema. Una empresa de servicios financieros tenía la intención de realizar una migración masiva a AWS varios centros de datos con el objetivo de desocuparlos. Sin embargo, su ancho de banda estaba disponible entre los locales y no AWS era suficiente para la velocidad que pretendían. Lamentablemente, el aumento del ancho de banda requería una nueva conexión y tenía un plazo de entrega de tres meses. Esto significó que la velocidad de migración estuvo limitada durante los primeros tres meses. ### Implemente controles posteriores a la migración para seguir mejorando Por último, recuerde implementar las validaciones posteriores a la migración, como la integración de las operaciones, la optimización de costos y las comprobaciones de gobierno y cumplimiento. La validación posterior a la migración incluye la evaluación de las cargas de trabajo previamente migradas para descubrir las lecciones técnicas aprendidas que deberían aplicarse a las oleadas futuras. Además, se trata de una gran oportunidad para implementar operaciones de control de costes. Por ejemplo, durante la migración, puede decidir ajustar el tamaño de las AWS instancias a su entorno local para reducir la necesidad de realizar pruebas de rendimiento. Ahora que las pruebas ya no se encuentran en la ruta crítica de cierre del centro de datos, puede utilizar Amazon CloudWatch para evaluar la utilización de las instancias y determinar si una instancia de menor tamaño sería adecuada. Para ilustrar la importancia de esta fase, un importante cliente de tecnología estaba realizando una migración importante, pero inicialmente no incluyó las validaciones posteriores a la migración. Tras migrar más de 100 servidores, identificaron que el AWS Systems Manager agente (agente SSM) no estaba configurado correctamente. Todos los servidores migrados anteriormente tuvieron que corregirse y la migración se estancó. El cliente también se dio cuenta de que las instancias eran cinco veces más grandes que las estimaciones iniciales, por lo que implementó un punto de control de costos al final de cada oleada de migración. # Perspectiva del proceso Los procesos aportan coherencia, pero también evolucionan y son susceptibles de cambiar porque cada proyecto es único. A medida que ejecute el proceso repetidamente, identificará las brechas y el margen de mejora que, a medida que vaya fallando, aprendiendo, adoptando e iterando, pueden traducirse en enormes beneficios. Estos cambios pueden generar nuevas ideas o innovaciones que el proyecto y la empresa puedan aprovechar en el futuro, lo que proporciona un catalizador para el crecimiento que aporta calidad y confianza al equipo. Los procesos de migración pueden ser complejos, ya que cruzan tecnologías y límites que antes no estaban relacionados. Esta perspectiva proporciona procesos y orientación sobre los requisitos específicos para las grandes migraciones. ## Preparándose para una migración de gran envergadura En las siguientes secciones se describen los principios básicos necesarios para garantizar que el proceso de migración comience con una orientación clara y con la aceptación de las partes interesadas, lo que será fundamental para su éxito. **Contents** + [Defina los impulsores del negocio y comunique el cronograma, el alcance y la estrategia](#bus-drivers) + [Defina una ruta de escalación clara para ayudar a eliminar los obstáculos](#escalation) + [Minimice los cambios innecesarios](#change) + [Documente y end-to-end procese con antelación](#end-to-end) + [Documente los patrones y artefactos de migración estándar](#artifacts) + [Establezca una fuente única de información fiable para los metadatos y el estado de la migración](#metadata) ### Defina los impulsores del negocio y comunique el cronograma, el alcance y la estrategia Cuando se acerque a una gran migración a AWS, descubrirá rápidamente que existen numerosas formas de migrar sus servidores. Por ejemplo, podría hacer lo siguiente: + Realoje las cargas de trabajo mediante. [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) + Coloque su aplicación en contenedores y hospéjela en la plataforma de contenedores gestionados [Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) (Amazon ECS) o [Amazon Elastic Kubernetes Service (Amazon](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) EKS). + Rediseñe su carga de trabajo para convertirla en una aplicación totalmente sin servidores. Para determinar la ruta de migración correcta, es importante tomar en cuenta los factores que impulsan su empresa. Si su objetivo final es aumentar la agilidad empresarial, podría preferir los dos segundos patrones, que implican más niveles de transformación. Si su objetivo es desocupar un centro de datos antes de fin de año, puede optar por realojar las cargas de trabajo debido a la velocidad que proporciona el realojamiento. Una migración de gran envergadura suele implicar a una amplia gama de partes interesadas, entre las que se incluyen las siguientes: + Responsables de la aplicación + Equipos de red + Administradores de base de datos + Patrocinadores ejecutivos Es fundamental identificar los factores empresariales que impulsan la migración e incluir esa lista en un documento, como el acta constitutiva del proyecto, al que puedan acceder los miembros del programa de migración. Además, cree indicadores clave de rendimiento (KPIs) que se ajusten estrechamente a sus objetivos de negocio. Por ejemplo, un cliente quería migrar 2000 servidores en un plazo de 12 meses para lograr su objetivo empresarial, es decir, dejar su centro de datos desocupado. Sin embargo, sus equipos de seguridad no estaban alineados con este objetivo. El resultado fueron varios meses de debates técnicos sobre si no cumplir con la fecha de cierre del centro de datos y modernizar aún más las aplicaciones o realojarlas inicialmente para permitir el cierre puntual del centro de datos y, posteriormente, modernizar las aplicaciones. AWS ### Defina una ruta de escalación clara para ayudar a eliminar los obstáculos Los grandes programas de migración a la nube suelen implicar a una amplia gama de partes interesadas. Al fin y al cabo, es posible que esté cambiando las aplicaciones que han estado alojadas en las instalaciones durante varias décadas. Es habitual que cada una de las partes interesadas tenga prioridades contradictorias. Si bien todas las prioridades pueden generar valor, es probable que el programa tenga un presupuesto limitado y un objetivo objetivo definido. Gestionar las distintas partes interesadas y centrarse en los resultados empresariales objetivo puede resultar difícil. Este desafío se agrava si se multiplica por los cientos o miles de aplicaciones incluidas en el ámbito de la migración. Además, es probable que las partes interesadas dependan de diferentes equipos de liderazgo, que tienen otras prioridades. Con esto en mente, además de documentar con claridad los resultados empresariales previstos, es importante definir una matriz de escalamiento clara que ayude a eliminar los obstáculos. Esto puede ahorrar una cantidad significativa de tiempo y ayudar a alinear a los distintos equipos hacia un objetivo común. Un ejemplo que lo demuestra es el de una empresa de servicios financieros cuyo objetivo era desocupar su centro de datos principal en un plazo de 12 meses. No había un mandato claro ni una ruta de escalamiento clara, por lo que las partes interesadas diseñaron las rutas de migración deseadas, independientemente de las limitaciones de tiempo y presupuesto. Tras el ascenso al CIO, se estableció un mandato claro y se proporcionó un mecanismo para solicitar las decisiones necesarias. ### Minimice los cambios innecesarios El cambio es bueno, pero más cambios implican más riesgos. Cuando se aprueben los argumentos comerciales que justifican la migración a gran escala, lo más probable es que esta iniciativa se base en un resultado empresarial objetivo, como la desocupación de un centro de datos en una fecha específica. Si bien es habitual que los tecnólogos quieran reescribir todo para aprovechar al máximo los AWS servicios, es posible que este no sea su objetivo empresarial. Un cliente se centró en migrar durante dos años toda la infraestructura web de la empresa a. AWS Crearon una regla de dos semanas como mecanismo para evitar que los equipos de aplicaciones pasaran meses reescribiendo sus aplicaciones. Al utilizar la regla de las dos semanas, el cliente pudo mantener una migración a largo plazo con una cadencia constante cuando hubo que mover cientos de aplicaciones en un período de varios años. Para obtener más información, consulte la entrada del blog La [regla de las dos semanas: refactoriza tus aplicaciones para](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/) la nube en 10 días. Recomendamos minimizar cualquier cambio que no esté alineado con el resultado empresarial. En su lugar, cree mecanismos para gestionar estos cambios adicionales en futuros proyectos. ### Documente y end-to-end procese con antelación Documente el proceso de migración completo y la asignación de la propiedad en las primeras etapas de un programa de migración de gran envergadura. Esta documentación es importante para informar a todas las partes interesadas sobre cómo se llevará a cabo la migración y sus funciones y responsabilidades. La documentación también le ayudará a entender dónde pueden producirse los problemas y a proporcionarle actualizaciones e iteraciones del proceso a medida que avance en las migraciones. Durante el desarrollo del proyecto de migración, asegúrese de que se entiendan todos los procesos existentes y de que los puntos de integración y las dependencias estén documentados con claridad. Incluya los lugares en los que sea necesaria la colaboración con los propietarios de los procesos externos, incluidas las solicitudes de cambio, las solicitudes de servicio, el soporte de los proveedores y el soporte de redes y firewalls. Una vez entendido el proceso, recomendamos documentar la propiedad en una matriz responsable, responsable, consultada e informada (RACI) para hacer un seguimiento de las diferentes actividades. Para finalizar el proceso, establezca un plan de cuenta regresiva identificando los plazos necesarios para cada paso de la migración. Por lo general, el plan de cuenta regresiva funciona en sentido inverso a partir de la fecha y hora de transición de la migración de la carga de trabajo. Este enfoque de documentación funcionó bien para una empresa multinacional de electrodomésticos que migró a su empresa AWS con éxito en menos de un año y abandonó cuatro centros de datos. Contaban con seis equipos organizativos diferentes y con la participación de varios terceros, lo que supuso una sobrecarga de gestión que se tradujo en back-and-forth decisiones y demoras en la implementación. El equipo de servicios AWS profesionales, junto con el cliente y sus terceros, identificaron los procesos clave de las actividades de migración y los documentaron con los respectivos propietarios. Todos los equipos involucrados compartieron y acordaron la matriz RACI resultante. Al utilizar la matriz RACI y una matriz de escalamiento, el cliente eliminó los obstáculos y los problemas que generaban los retrasos. Luego pudieron salir de los centros de datos antes de lo previsto. En otro ejemplo del uso de RACI y matrices de escalamiento, una empresa de seguros pudo salir del centro de datos en menos de 4 meses. El cliente entendió e implementó un modelo de responsabilidad compartida, y se siguió una matriz RACI detallada para hacer un seguimiento del progreso de cada proceso y actividad a lo largo de la migración. Como resultado, el cliente pudo migrar más de 350 servidores en las primeras 12 semanas de implementación. ### Documente los patrones y artefactos de migración estándar Piense en ello como crear moldes para la implementación. Las referencias, la documentación, los manuales y los patrones reutilizables son la clave para escalar. Estos registran la experiencia, el aprendizaje, las dificultades, los problemas y las soluciones que los futuros proyectos de migración pueden reutilizar y evitar, lo que acelera significativamente la migración. Los patrones y artefactos también son una inversión que ayudará a mejorar el proceso y guiará los proyectos futuros. Por ejemplo, un cliente estaba realizando una migración de un año de duración en la que tres AWS socios de SI diferentes estaban migrando las aplicaciones. En las primeras etapas, cada AWS socio utilizaba sus propios estándares, manuales y artefactos. Esto suponía una gran carga para los equipos de clientes, ya que se les podía presentar la misma información de diferentes maneras. Tras estos primeros esfuerzos, el cliente estableció la propiedad central de toda la documentación y los artefactos que se utilizarían en la migración, con un proceso para enviar los cambios recomendados. Entre estos activos se incluyen los siguientes: + Un proceso de migración estándar y listas de verificación + Estándares de estilo y formato de diagramas de red + Estándares de arquitectura y seguridad de las aplicaciones basados en la criticidad empresarial Además, las modificaciones de cualquiera de estos documentos y normas se enviaban semanalmente a todos los equipos, y cada socio tenía que confirmar la recepción y el cumplimiento de las modificaciones. Esto mejoró considerablemente la comunicación y la coherencia del proyecto de migración y, cuando otra unidad de negocio emprendió un gran esfuerzo de migración independiente, ese equipo pudo adoptar el proceso y los documentos existentes, lo que aceleró considerablemente su éxito. ### Establezca una fuente única de información fiable para los metadatos y el estado de la migración Cuando se trata de planificar una migración de gran envergadura, es importante establecer una fuente fiable para mantener a los distintos equipos alineados y poder tomar decisiones basadas en datos. Al iniciar este proceso, es posible que encuentre numerosas fuentes de datos que puede utilizar, como la base de datos de gestión de la configuración (CMDB), las herramientas de supervisión del rendimiento de las aplicaciones, las listas de inventario, etc. Como alternativa, puede darse cuenta de que hay pocas fuentes de datos y debe crear mecanismos para capturar los datos necesarios. Por ejemplo, es posible que necesite utilizar herramientas de descubrimiento para descubrir información técnica y encuestar a los líderes de TI para obtener información empresarial. Es importante agrupar las distintas fuentes de datos en un único conjunto de datos que pueda utilizar para la migración. A continuación, puede utilizar la única fuente de información fiable para realizar un seguimiento de la migración durante la implementación. Por ejemplo, puede realizar un seguimiento de los servidores que se han migrado. Un cliente de servicios financieros que quería migrar todas las cargas de trabajo AWS se centró en planificar la migración con el conjunto de datos que se le había proporcionado. Este conjunto de datos tenía brechas clave, como la criticidad empresarial y la información sobre las dependencias, por lo que el programa inició un ejercicio de descubrimiento. En otro ejemplo, una empresa del mismo sector pasó a implementar una ola de migración basándose en el out-of-date conocimiento de su inventario de infraestructuras de servidores. Rápidamente empezaron a ver disminuir las cifras de migración porque los datos eran incorrectos. En este caso, no se entendía a los propietarios de las aplicaciones, lo que significaba que no podían encontrar los evaluadores a tiempo. Además, los datos no estaban alineados con el desmantelamiento que habían llevado a cabo sus equipos de aplicaciones, por lo que los servidores funcionaban sin ser utilizados con fines comerciales. ## ¿Ejecutando una migración de gran tamaño? Una vez establecidos los resultados empresariales y comunicado la estrategia a las partes interesadas, puede empezar a planificar cómo dividir el alcance de la gran migración en eventos u oleadas de migración sostenible. Los siguientes ejemplos proporcionan una guía clave para elaborar el plan de oleada. **Contents** + [Planifique las oleadas de migración con antelación para garantizar un flujo constante](#plan-waves) + [Mantenga la implementación y la planificación de las oleadas como procesos y equipos separados](#separate) + [Comience poco a poco para obtener excelentes resultados](#start-small) + [Minimice la cantidad de ventanas transitadas](#cutover-numbers) + [Falla rápido, aplica la experiencia e itera](#iterate) + [No olvides la retrospectiva](#retrospective) ### Planifique las oleadas de migración con antelación para garantizar un flujo constante Planificar la migración es una de las fases más importantes del programa. Va de la mano con el dicho «si no planificas, planeas fallar». Planificar las oleadas de migración con antelación permite que el proyecto avance con rapidez a medida que el equipo se vuelve más proactivo ante la situación de la migración. Ayuda a que el proyecto se amplíe con mayor facilidad y mejora la toma de decisiones y la previsión a medida que las demandas del proyecto aumentan y se vuelven complejas. Planificar con antelación también mejora la capacidad del equipo para adaptarse a los cambios. Por ejemplo, un importante cliente de servicios financieros estaba trabajando en un programa de salida de un centro de datos. Inicialmente, el cliente planificó las oleadas de migración de forma secuencial, completando una oleada antes de empezar a planificar la siguiente. Este enfoque permitió reducir el tiempo de preparación. Cuando se informó a las partes interesadas de que se estaban migrando sus aplicaciones AWS, aún les quedaban varios pasos por realizar antes de iniciar la migración. Esto supuso importantes retrasos en el programa. Cuando el cliente se dio cuenta de ello, implementó un flujo de planificación de la migración holístico y centrado en el futuro, en el que las oleadas de migración se planificaron con varios meses de antelación. Esto proporcionó suficiente antelación para que los equipos de aplicaciones realizaran sus actividades previas a la migración, como la notificación a los AWS socios, el análisis de licencias, etc. A continuación, podrían eliminar esas tareas de la ruta crítica del programa. ### Mantenga la implementación y la planificación de las oleadas como procesos y equipos separados Cuando los equipos de planificación e implementación de olas están separados, los dos procesos pueden funcionar en paralelo. Con la comunicación y la coordinación, se evita ralentizar la migración porque no hay suficientes servidores o aplicaciones preparados para alcanzar la velocidad esperada. Por ejemplo, es posible que el equipo de migración necesite migrar 30 servidores cada semana, pero en la oleada actual solo hay 10 servidores preparados. Este desafío suele deberse a lo siguiente: + El equipo de implementación de la migración no participó en la planificación de las olas y los datos recopilados en la fase de planificación de las olas no están completos. El equipo de implementación de la migración debe recopilar más datos del servidor antes de iniciar la oleada. + La implementación de la migración está programada para comenzar inmediatamente después de la planificación de la oleada, sin ningún margen intermedio. Es fundamental planificar las oleadas con antelación y crear un espacio intermedio entre la preparación y el inicio de la implementación de la oleada. También es importante asegurarse de que el equipo de planificación de la oleada y el equipo de migración trabajen juntos para recopilar los datos correctos y evitar tener que volver a trabajar. ### Comience poco a poco para obtener excelentes resultados Planifique empezar poco a poco y aumente la velocidad de migración con cada oleada subsiguiente. La oleada inicial debería consistir en una sola aplicación pequeña, con menos de 10 servidores. Añada aplicaciones y servidores adicionales en las sucesivas oleadas, aumentando así su velocidad de migración máxima. Al priorizar las aplicaciones menos complejas o riesgosas y aumentar la velocidad según un cronograma, el equipo tiene tiempo para adaptarse al trabajo conjunto y aprender el proceso. Además, el equipo puede identificar e implementar mejoras en los procesos con cada oleada, lo que puede mejorar sustancialmente la velocidad de las oleadas posteriores. Un cliente estaba migrando más de 1300 servidores en un año. Al comenzar con una migración piloto y algunas oleadas más pequeñas, el equipo de migración pudo identificar varias formas de mejorar las migraciones posteriores. Por ejemplo, identificaron antes los nuevos segmentos de la red de los centros de datos. Trabajaron con su equipo de firewall al principio del proceso para establecer reglas de firewall que permitieran la comunicación con las herramientas de migración. Esto ayudó a evitar demoras innecesarias en futuras oleadas. Además, el equipo pudo desarrollar scripts que les ayudaran a automatizar más sus procesos de descubrimiento y transición con cada oleada. Empezar poco a poco ayudó al equipo a centrarse en las primeras mejoras de los procesos y aumentó considerablemente su confianza. ### Minimice la cantidad de ventanas transitadas Las migraciones masivas requieren un enfoque disciplinado para impulsar la escala. Ser demasiado flexible en algunas áreas es contrario a la pauta para las grandes migraciones. Al limitar el número de períodos de transición semanales, el tiempo dedicado a las actividades de transición tiene un mayor valor. Por ejemplo, si el período de transición es demasiado flexible, podría terminar con 20 transiciones con cinco servidores cada una. En su lugar, podría tener dos transiciones con 50 servidores cada una. Como el tiempo y el esfuerzo de cada transición son similares, disponer de menos transiciones y de mayor tamaño reduce la carga operativa que supone la programación y limita las demoras innecesarias. Una gran empresa de tecnología estaba intentando abandonar algunos centros de datos arrendados antes de que expirara el contrato. No cumplir con el vencimiento se traduciría en plazos de renovación costosos y a corto plazo. Al principio de la migración, a los equipos de aplicaciones se les permitía dictar el calendario de migración hasta el último minuto, lo que incluía optar por no participar en la migración por cualquier motivo solo unos días antes de la transición. Esto provocó numerosos retrasos en las primeras etapas del proyecto. A menudo, el cliente tenía que negociar con otros equipos de solicitudes en el último momento para rellenar la solicitud. Con el tiempo, el cliente aumentó su disciplina de planificación, pero este error inicial provocó un estrés constante para el equipo de migración. Los retrasos en el cronograma general hicieron que algunas aplicaciones no pudieran salir de los centros de datos a tiempo. ### Falla rápido, aplica la experiencia e itera Al principio, cada migración tiene dificultades. Fracasar pronto ayuda al equipo a aprender, a entender los obstáculos y a aplicar las lecciones aprendidas a oleadas más grandes. Se espera que las dos primeras oleadas de una migración sean lentas por las siguientes razones: + Los miembros del equipo se están adaptando unos a otros y al proceso. + Las grandes migraciones suelen implicar a muchas herramientas y personas diferentes. + Integrar, probar, fallar, aprender y mejorar continuamente el end-to-end proceso lleva tiempo. Los problemas son comunes y se esperan durante las dos primeras oleadas. Es importante entender esto y comunicarlo a toda la organización, ya que es posible que a algunos equipos no les guste probar cosas nuevas y fracasar. El fracaso puede desanimar al equipo y convertirse en un obstáculo para futuras migraciones. Asegurarse de que todos entiendan que los problemas iniciales son parte del trabajo y animar a todos a intentarlo y fallar es clave para una migración exitosa. Una empresa tenía previsto migrar más de 10 000 servidores en un plazo de 24 a 36 meses. Para lograr ese objetivo, necesitaban migrar casi 300 servidores al mes. Sin embargo, eso no significa que hayan migrado 300 servidores desde el primer día. Las dos primeras oleadas fueron de aprendizaje para que el equipo pudiera entender cómo funcionaban las cosas y quién tenía permisos para hacer qué. También identificaron integraciones que mejorarían el proceso, como la integración con CMDB y. CyberArk Utilizaron las oleadas de aprendizaje para fallar, mejorar y volver a fallar, perfeccionando el proceso y la automatización. Después de 6 meses, pudieron migrar más de 120 servidores cada semana. ### No olvides la retrospectiva Esta es una parte importante de un proceso ágil. Es el lugar donde el equipo se comunica, se ajusta, aprende, se pone de acuerdo y avanza. Una retrospectiva, en el nivel más básico, consiste en mirar hacia atrás, analizar lo que ha sucedido, determinar qué ha ido bien y qué es lo que hay que mejorar. Luego, se pueden construir mejoras sobre la base de esas discusiones. Las retrospectivas envuelven alguna formalidad o proceso en torno a la idea de las lecciones aprendidas. Las retrospectivas son importantes porque, para lograr la escala y la velocidad necesarias para que las grandes migraciones tengan éxito, los procesos, las herramientas y los equipos deben evolucionar y mejorar constantemente. Las retrospectivas pueden desempeñar un papel importante en este sentido. Las sesiones tradicionales sobre las lecciones aprendidas no se llevan a cabo hasta el final de un programa, por lo que, a menudo, estas lecciones no se revisan al comienzo de la próxima ola de migración. En el caso de las grandes migraciones, las lecciones aprendidas deben aplicarse a la siguiente oleada y deben ser una parte clave del proceso de planificación de la oleada. En el caso de un cliente, se realizaron retrospectivas semanales para analizar y documentar las lecciones aprendidas de las transiciones. En estas sesiones, descubrieron áreas en las que había margen para la racionalización desde el punto de vista del proceso o la automatización. Esto dio lugar a la implementación de un cronograma de cuenta regresiva con actividades, propietarios y scripts de automatización específicos para minimizar las tareas manuales, incluida la validación de herramientas de terceros y la instalación de CloudWatch agentes de Amazon, durante la transición. En otra gran empresa de tecnología, se realizaron retrospectivas periódicas con el equipo para identificar los problemas relacionados con las oleadas de migración anteriores. Esto se tradujo en mejoras en los procesos, los scripts y la automatización, que redujeron el tiempo medio de migración en un 40 por ciento a lo largo del programa. ## Consideraciones adicionales Un programa de migración de gran envergadura debe tener en cuenta muchas áreas. En las siguientes secciones se ofrecen ideas sobre otros aspectos que deben tenerse en cuenta. **Contents** + [Limpie sobre la marcha](#clean-up) + [Implemente varias fases para cualquier transformación adicional](#phases) ### Limpie sobre la marcha Una migración no se considera exitosa si cuesta 10 veces lo esperado, y el proyecto no está completo hasta que se cancelen y se limpien los recursos utilizados para la migración. Esta limpieza debe formar parte de la actividad posterior a la migración. Garantiza que no deje recursos y servicios no utilizados en su entorno, lo que aumentará los costos. La limpieza posterior a la migración también es una buena práctica de seguridad para prevenir las amenazas y vulnerabilidades que exponen su entorno. Dos resultados clave de la migración a ese entorno Nube de AWS son el ahorro de costes y la seguridad. Dejar los recursos sin utilizar puede frustrar el propósito empresarial de migrar a la nube. Los recursos más comunes que no se limpian son los siguientes: + Datos de prueba + Pruebe las bases de datos + Pruebe las cuentas, incluidas las reglas de firewall, los grupos de seguridad y las direcciones IP de la lista de control de acceso a la red (ACL de red) + Puertos aprovisionados para realizar pruebas + Volúmenes de Amazon Elastic Block Store (Amazon EBS) + Snapshots + Replicación (por ejemplo, detener la replicación de datos de una ubicación local a otra) AWS + Archivos que consumen espacio (como las copias de seguridad temporales de las bases de datos que se utilizan para migrar) + Instancias que alojan las herramientas de migración En un ejemplo de malas prácticas de limpieza, SI AWS Partners no eliminaba los agentes de replicación tras una migración exitosa. Una AWS auditoría descubrió que los servidores de replicación y los volúmenes de EBS que ya se habían migrado costaban 20 000 dólares (USD) al mes. Para mitigar el problema, AWS Professional Services creó un proceso de auditoría automatizado que notificaba a SI AWS Partners cuando los servidores obsoletos seguían siendo replicados. De este modo, AWS los socios de SI podían tomar medidas en caso de instancias obsoletas o no utilizadas. Para las futuras migraciones, se adoptó un proceso para definir un período de hiperatención posterior a la migración de 48 horas a fin de garantizar una adopción de la plataforma sin problemas. A continuación, el equipo de infraestructura del cliente presentó una solicitud de desmantelamiento de los servidores locales. Se informó de que, una vez aprobada la solicitud de desmantelamiento, los servidores de la oleada correspondiente se retirarían de la consola del servicio de migración de aplicaciones. ### Implemente varias fases para cualquier transformación adicional Al realizar una migración de gran envergadura, es importante centrarse en su objetivo principal, como el cierre del centro de datos o la transformación de la infraestructura. En migraciones más pequeñas, la ampliación del alcance puede tener un impacto mínimo. Sin embargo, unos pocos días de esfuerzo adicional multiplicados por posibles miles de servidores pueden añadir una cantidad significativa de tiempo al programa. Además, los cambios adicionales también pueden requerir actualizaciones de la documentación, los procesos y la formación de los equipos de soporte. Para evitar una posible ampliación del alcance, puede implementar un enfoque de varias fases en la migración. Por ejemplo, si su objetivo era desocupar un centro de datos, la fase 1 podría incluir únicamente realojar la carga de trabajo lo más rápido posible. AWS Tras reorganizar una carga de trabajo, la fase 2 puede implementar actividades de transformación sin poner en riesgo el resultado empresarial previsto. Por ejemplo, un cliente tenía previsto salir de su centro de datos en 12 meses. Sin embargo, su migración abarcó otras actividades de transformación, como la implementación de nuevas herramientas de monitoreo del rendimiento de las aplicaciones y la actualización de los sistemas operativos. La migración incluía más de 1000 servidores, por lo que estas actividades supusieron un retraso significativo en la migración. Además, este enfoque requería capacitación en el uso de las nuevas herramientas. Más tarde, el cliente decidió implementar un enfoque de múltiples fases con un enfoque inicial en el realojamiento. Esto aumentó su velocidad de migración y redujo el riesgo de no cumplir con la fecha de cierre del centro de datos.