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. # Análisis de cartera y planificación de la migración Esta etapa de la evaluación se centra en completar el descubrimiento y el análisis a nivel de cartera que se inició en la sección de descubrimiento y planificación inicial de la [cartera.](portfolio-discovery-initial-planning.md) El objetivo es iterar y establecer una línea base para la cartera inicial de aplicaciones e infraestructura. Esta base de referencia incluye la identificación de todas las dependencias, la iteración de los modelos de racionalización para la migración, la creación de un modelo de negocio detallado y la elaboración de un plan para la oleada de migración. Como resultado, la fidelidad de los datos requerida es mayor. Esta etapa requerirá una inversión de tiempo. Para acelerar los resultados de la evaluación, recomendamos utilizar tantas fuentes de datos programáticas, como herramientas de descubrimiento, como sea posible. Los resultados principales de esta etapa incluyen los siguientes: + Un inventario de aplicaciones e infraestructuras de alta fidelidad + Una estrategia de migración de alto nivel para cada aplicación + Un plan de oleada de migración de alta confianza + Un caso de negocio detallado # Comprensión de los requisitos completos de los datos de evaluación En la siguiente tabla se describe la información necesaria para obtener una visión completa de la cartera de aplicaciones de la migración y su infraestructura asociada. En las tablas se utilizan las siguientes abreviaturas: + R, si es necesario + O, para opcional + N/A, si no se aplica **Aplicaciones** | **Nombre de atributo** | **Descripción** | **Inventario y priorización** | **Caso de negocio detallado** | **Nivel de fidelidad recomendado (mínimo)** | | --- | --- | --- | --- | --- | | Identificador único | Por ejemplo, el identificador de la aplicación. Suele estar disponible en sistemas de control e inventarios internos existentes CMDBs o de otro tipo. Considere la posibilidad de IDs crearlos únicos siempre que no estén definidos en su organización. | R | R | Alto | | Nombre de la aplicación | Nombre por el que su organización conoce esta aplicación. Incluya el nombre del proveedor comercial off-the-shelf (COTS) y del producto cuando proceda. | R | R | Alto | | ¿Es COTS? | Sí o no. Ya sea una aplicación comercial o un desarrollo interno | R | R | Alto | | Producto y versión de COTS | Nombre y versión del producto de software comercial | R | R | Alto | | Description (Descripción) | Función y contexto de la aplicación principal | R | R | Alto | | Criticidad | Por ejemplo, una aplicación estratégica o generadora de ingresos, o que respalde una función crítica | R | R | Alto | | Tipo | Por ejemplo, base de datos, gestión de relaciones con los clientes (CRM), aplicación web, multimedia o servicio compartido de TI | R | R | Alto | | Entorno | Por ejemplo, producción, preproducción, desarrollo, pruebas o entorno aislado | R | R | Alto | | Cumplimiento y normativa | Marcos aplicables a la carga de trabajo (por ejemplo, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) y requisitos normativos | R | R | Alto | | Dependencias | Dependencias ascendentes y descendentes de aplicaciones o servicios internos y externos. Dependencias no técnicas, como los elementos operativos (por ejemplo, los ciclos de mantenimiento). | R | O | Alto | | Mapeo de infraestructuras | Mapeo de los activos and/or virtuales físicos que componen la aplicación | R | R | Alto | | Licencia | Tipo de licencia de software básico (por ejemplo, Microsoft SQL Server Enterprise) | R | R | Medio-alto | | Costo | Costos de la licencia de software, las operaciones y el mantenimiento del software | N/A | R | Medio-alto | | Unidad de negocio | Por ejemplo, marketing, finanzas, ventas | R | R | Alto | | Datos del propietario | Información de contacto del propietario de la aplicación | R | R | Alto | | Información de DR | Componentes de recuperación ante desastres | R | R | Alto | | Estrategia de migración | Por ejemplo, una de las 6 R para migrar a AWS | R | R | Alto | | Tickets de soporte | De 12 a 24 meses de datos para ayudar a evaluar el impacto financiero y en la productividad de las interrupciones, las ralentizaciones, la limitación de las transacciones y los sobreplazos de entrega | O | R | Medio | **Infraestructura** | **Nombre de atributo** | **Descripción** | **Inventario y priorización** | **Argumentos comerciales** | **Nivel de fidelidad recomendado (mínimo)** | | --- | --- | --- | --- | --- | | Identificador único | Por ejemplo, el ID del servidor. Suele estar disponible en sistemas de control e inventarios internos existentes CMDBs o de otro tipo. Considere la posibilidad de IDs crearlos únicos siempre que no estén definidos en su organización. | R | R | Alto | | Nombre de la red | Nombre del activo en la red (por ejemplo, nombre de host) | R | R | Alto | | Nombre DNS (nombre de dominio completo o FQDN) | Nombre de DNS | R | O | Alto | | Dirección IP y máscara de red | Direcciones IP and/or públicas internas | R | R | Alto | | Tipo de activo | Por ejemplo, servidor físico o virtual, hipervisor, contenedor, dispositivo o instancia de base de datos | R | R | Alto | | Product name (Nombre del producto) | Proveedor comercial y nombre del producto (por ejemplo VMware ESXi, IBM Power Systems, Exadata) | R | R | Alto | | Sistema operativo | Por ejemplo, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Alto | | Configuración | CPU asignada, número de núcleos, subprocesos por núcleo, memoria total, almacenamiento, tarjetas de red | R | R | Alto | | Uso | Cantidad máxima y media de CPU, memoria y almacenamiento. Rendimiento de las instancias de base de datos. | R | R | Alto | | Licencia | Tipo de licencia básica (por ejemplo, RHEL Standard) | R | R | Alto | | ¿Es una infraestructura compartida? | Sí o No para indicar los servicios de infraestructura que proporcionan servicios compartidos, como el proveedor de autenticación, los sistemas de monitoreo, los servicios de respaldo y servicios similares | R | R | Alto | | Mapeo de aplicaciones | Aplicaciones o componentes de aplicaciones que se ejecutan en esta infraestructura | R | R | Alto | | Costo | Los costes totales de los servidores básicos incluyen el hardware, el mantenimiento, las operaciones, el almacenamiento (SAN, NAS, Object), la licencia del sistema operativo, el espacio compartido en los racks y los gastos generales del centro de datos | N/A | R | Medio-alto | | Volumen estimado de transferencia de datos (entrada/salida) | Por ejemplo, por activo de infraestructura por día durante un período de 30 días | O | R | Medio | **Redes** | **Nombre de atributo** | **Descripción** | **Inventario y priorización** | **Argumentos comerciales** | **Nivel de fidelidad recomendado (mínimo)** | | --- | --- | --- | --- | --- | | Tamaño de la tubería (Mb/s), redundancy (Y/N) | Especificaciones actuales del enlace WAN (por ejemplo, 1000 Mb/s de redundancia) | R | R | Medio-alto | | Utilización del enlace | Utilización máxima y media, transferencia de datos salientes (GB/mes) | R | R | Medio-alto | | Latencia (ms) | Latencia actual entre las ubicaciones conectadas. | R | O | Alto | | Costo | Coste actual por mes | N/A | R | Medio-alto | **Migración** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/application-portfolio-assessment-guide/understanding-complete-assessment-data-requirements.html) # Establecer una base para la cartera de aplicaciones Para crear planes de oleadas de migración fiables, debe establecer una base para la cartera de aplicaciones y su infraestructura asociada. Una base de referencia de la cartera proporciona una visión integral del alcance de la migración, incluidas las dependencias técnicas y la estrategia de migración. La base de referencia de la cartera proporciona claridad sobre qué aplicaciones están incluidas en el ámbito de la migración y permite recopilar los datos descritos en la sección [Comprensión completa de los requisitos en materia de datos de evaluación](understanding-complete-assessment-data-requirements.md). Del mismo modo, toda la infraestructura asociada (computación, redes de almacenamiento) se entiende y se asigna a las aplicaciones. Las dependencias técnicas se pueden describir en cuatro categorías: + **A pplication-to-infrastructure** Las dependencias establecen el vínculo entre el software y el hardware físico o virtual. Por ejemplo, existe una dependencia entre una aplicación de CRM y las máquinas virtuales en las que está instalada. + Las dependencias entre **los componentes de la aplicación** describen cómo interactúan los componentes que se ejecutan en diferentes activos de infraestructura. Un ejemplo de dependencia entre un componente de una aplicación es una interfaz web que se ejecuta en máquinas virtuales, con una capa de aplicación que se ejecuta en una máquina virtual diferente y una base de datos que se ejecuta en un clúster de bases de datos. + pplication-to-applicationLas dependencias **a** se refieren a la interacción entre aplicaciones o componentes de aplicaciones con otras aplicaciones o sus componentes. Un ejemplo de application-to-application dependencia es una aplicación de procesamiento de pagos y una aplicación de administración de existencias. Estas aplicaciones son independientes, pero interactúan constantemente mediante operaciones de API definidas. + Application-to-infrastructure las dependencias de los **servicios** son application-to-application dependencias técnicas, dado que el servicio de infraestructura es en sí mismo una aplicación. Sin embargo, recomendamos clasificarlos por separado. La razón principal es que los servicios de infraestructura suelen ser compartidos por muchas aplicaciones, por lo que tienen un largo historial de dependencias. También suelen seguir una estrategia y un patrón de migración diferentes. Por ejemplo, un equilibrador de cargas puede contener grupos de equilibrio para varias aplicaciones. Lo que importa es la dependencia del grupo, que es probable que se migre de forma individual, junto con la aplicación dependiente, mientras que el propio balanceador de cargas se conserva o se retira. Además, la individualización application-to-infrastructure de las dependencias de los servicios ayuda a evitar grupos de dependencias falsos. Un grupo de dependencias falsas se produce cuando se agrupan varias aplicaciones empresariales, lo que implica que tienen una dependencia común a un servicio de infraestructura que deben migrarse al mismo tiempo. Por ejemplo, es probable que los servicios de autenticación, como Active Directory, estén asociados a grandes grupos de aplicaciones. La clave es abordar estas aplicaciones de forma individual y abordar la dependencia habilitando el servicio, por ejemplo AWS Directory Service for Microsoft Active Directory, en el entorno de nube. Cuando establezca una línea base para la cartera, le recomendamos que confirme una estrategia de migración para cada componente de la aplicación. La estrategia de migración será una de las 6 R de la migración (consulte la sección [Iteración de la estrategia de migración de las 6 R](iterating-6-rs-migration-strategy-selection.md)). En la base de referencia de la cartera, se debe asociar una de las 6 R a cada solicitud. También se debe asociar una estrategia de 6 R a cada uno de los componentes de la infraestructura de la aplicación. Para establecer una versión de referencia de la cartera, que incluya las dependencias y las estrategias de migración, utilice herramientas de descubrimiento automatizadas (consulte [Evaluación de la necesidad de herramientas de descubrimiento](understanding-initial-assessment-data-requirements.md#discovery-tooling)). Complemente los datos con la información recopilada de las principales partes interesadas, como los propietarios de las aplicaciones y los equipos de infraestructura. Siga recopilando datos hasta obtener un inventario completo de la cartera que cumpla con los atributos y el nivel de fidelidad descritos en la [sección de requisitos de datos](understanding-complete-assessment-data-requirements.md) para esta etapa. El conjunto de datos resultante será fundamental para impulsar la migración. Tenga en cuenta que, según el alcance de su migración y las herramientas disponibles, esta actividad puede tardar varias semanas en completarse. # Iterar los criterios de priorización Antes de crear planes de oleadas de migración, le recomendamos que repita los criterios de priorización de las aplicaciones para pasar de la selección de aplicaciones piloto a la planificación de la oleada a largo plazo. [En las secciones anteriores, introdujimos un criterio de priorización predeterminado que daría prioridad a las aplicaciones sencillas preparadas para la nube (consulte Priorización de las aplicaciones).](prioritization-and-migration-strategy.md#prioritizing-applications) Esto se debe a que, en las primeras etapas, recomendamos empezar con aplicaciones no críticas para refinar los procesos de migración e incorporar las lecciones aprendidas. Sin embargo, en esta etapa, y para crear planes a largo plazo, el orden en que se migran las aplicaciones debe ajustarse a los factores que impulsan el negocio. La aplicación de los nuevos criterios generará una nueva clasificación de las aplicaciones que será un elemento clave para la planificación de las olas. Revise los puntos de datos disponibles en la cartera de aplicaciones y seleccione los atributos que determinarán la priorización de las aplicaciones en función de los factores empresariales. En primer lugar, valide los factores que impulsan su empresa (consulte [Impulsores empresariales y principios rectores técnicos](business-drivers-technical-guiding-principles.md)). A continuación, en función de los factores que impulsan su negocio, seleccione los atributos que ayudarán a priorizar las aplicaciones para la migración. La siguiente tabla muestra ejemplos de criterios de priorización alineados con los impulsores empresariales de la innovación. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html) La siguiente tabla muestra ejemplos de criterios de priorización alineados con los impulsores del negocio para una rápida reducción de costos. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html) Pruebe los criterios de priorización y repítelos hasta que esté generalmente de acuerdo con el resultado. Se necesitan al menos tres o cuatro iteraciones para obtener una versión de referencia. # Iterar la selección de la estrategia de migración de las 6 R En esta etapa, le recomendamos que itere y evolucione el árbol de decisiones de las 6 R. La sección [Determinación del tipo R para la migración](prioritization-and-migration-strategy.md#migration-r-type) introdujo un árbol de decisiones predeterminado. Recomendamos revisar el árbol teniendo en cuenta lo aprendido a lo largo de la migración de las aplicaciones piloto iniciales y asegurarse de que sigue ajustándose a las tendencias empresariales, los criterios de priorización y las circunstancias específicas del usuario. Valide el árbol de decisiones con aplicaciones de muestra y compruebe que sigue produciendo la estrategia esperada. De lo contrario, actualice la lógica en consecuencia. El árbol resultante será clave para establecer las bases de referencia para la cartera de aplicaciones y para asignar las estrategias de migración a cada componente de la aplicación. Como se describió en la [sección anterior de las 6 R](prioritization-and-migration-strategy.md#migration-r-type), las 6 R también se aplican a la infraestructura, y es igualmente importante asignarlas en consecuencia. Si bien un componente de aplicación determinado tendrá una estrategia de migración, a nivel de infraestructura, cada activo de infraestructura seguirá una estrategia de migración determinada que puede ser diferente de la estrategia establecida para el componente de aplicación al que da soporte. Recuerde que el árbol de decisiones de las 6 R se aplica únicamente a los componentes de la aplicación. La estrategia de migración de la infraestructura se deriva de la estrategia elegida para la aplicación. Por ejemplo, en el caso de un componente de la aplicación que se vaya a cambiar de plataforma, se podría retirar la infraestructura actual que lo aloja. Asegúrese de que las estrategias de migración se asignen a cada componente de la aplicación y a su infraestructura asociada. Esta información será un factor clave a la hora de estimar el esfuerzo, la capacidad y las habilidades necesarias, y a la hora de crear planes para la oleada de migración. Para obtener más información sobre cómo determinar las 6 R, consulta las [recomendaciones de AWS Migration Hub estrategia](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). # Planificación de olas En la planificación de oleadas, un grupo de dependencias es un conjunto de aplicaciones e infraestructuras que tienen dependencias técnicas y no técnicas que no se pueden resolver. Debido a estas dependencias, las aplicaciones y la infraestructura de un grupo de dependencias se deben migrar al mismo tiempo o en una fecha específica. Por ejemplo, es probable que una aplicación que se ejecuta en una máquina virtual y una base de datos que se ejecuta en una máquina virtual independiente, donde hay requisitos de baja latencia o volúmenes de tráfico elevados y consultas complejas, se migren juntas en lugar de utilizar un componente en la nube y el otro de forma local. Del mismo modo, las aplicaciones independientes que interactúan a través de una API con requisitos similares de baja latencia también se migrarán al mismo tiempo. Las oleadas de migración suelen durar de 4 a 8 semanas y pueden contener uno o más eventos de migración. Los grupos de dependencia se combinan en oleadas para que una oleada pueda contener uno o más grupos de dependencia. La oleada también contiene otras actividades que son necesarias para la migración. Estas incluyen la configuración de la AWS infraestructura (como la zona de aterrizaje, la seguridad y las operaciones), las herramientas de migración y las actividades de migración, como la replicación de datos, la planificación de cortes, las pruebas y el soporte posterior a la migración. Para medir el éxito y hacer un seguimiento del progreso, las olas deben estar alineadas con los resultados y los impulsores del negocio. Esto también influirá en la duración de la onda y en los grupos de dependencia que contiene una ola. La finalización de una oleada debe reflejar un logro mensurable. La planificación de una ola también puede combinar otros factores, como los principios rectores técnicos. Por ejemplo, las olas se pueden definir por entorno (por ejemplo, desarrollo, prueba, producción) o por estrategia de migración (por ejemplo, oleada de realojamiento, oleada de replataforma). Para crear planes de oleadas de migración eficaces y fiables, debe obtener una visión completa de la cartera de aplicaciones, la infraestructura asociada (computación, almacenamiento, redes), el mapeo de dependencias y la estrategia de migración. La sección sobre el [establecimiento de una base para la cartera de aplicaciones](baseline-application-portfolio.md) describió cuatro categorías de dependencias técnicas. Estas dependencias contribuyen a la creación de oleadas de migración y a la definición de grupos de dependencia. Los grupos de dependencia vendrán determinados por la criticidad de la dependencia. Además, se deben considerar las dependencias no técnicas. Por ejemplo, los calendarios de publicación de las aplicaciones, los plazos de mantenimiento y las fechas comerciales clave, como el procesamiento a finales de mes o al final del trimestre, influirán en el plan de expansión. Determine si la dependencia es *suave* o *dura*. Una dependencia flexible es una relación entre dos o más activos, o entre un activo y una restricción, que no depende de la ubicación de los componentes. Por ejemplo, dos sistemas que funcionan en la misma red local (o en la misma infraestructura) se pueden separar moviendo uno de esos sistemas a la nube y el otro permanece en las instalaciones. Otro ejemplo es un sistema que se puede migrar durante un período de mantenimiento sin que ello afecte a las actividades de mantenimiento. Una dependencia estricta es una relación entre dos o más activos, o entre un activo y una restricción, que depende de la ubicación. Por ejemplo, dos sistemas que funcionan en la misma red local y que dependen en gran medida de la baja latencia para la comunicación entre el servidor de aplicaciones y el servidor de bases de datos, tienen una fuerte dependencia. Mover solo uno de estos sistemas a la nube provocaría problemas de funcionalidad o rendimiento que no se pueden resolver. Del mismo modo, motivos no técnicos, como la disponibilidad de recursos (por ejemplo, el equipo que realiza la migración) o las limitaciones operativas, como los períodos de mantenimiento en los que solo se pueden migrar dos sistemas en un período de tiempo determinado, podrían crear una fuerte dependencia para estos activos. Para crear un plan de oleada de migración, determine sus grupos de dependencias analizando las dependencias, idealmente a partir de una fuente de datos de gran confianza, como herramientas de descubrimiento especializadas, y combine esta información con los criterios de priorización de las aplicaciones y las circunstancias operativas. Las aplicaciones que ocupen los primeros puestos de la clasificación de prioridades deberían estar orientadas a las oleadas de migración iniciales. Determine la capacidad de la oleada (la cantidad de aplicaciones que puede contener una oleada) en función de la disponibilidad de los recursos, la tolerancia al riesgo, las limitaciones empresariales y técnicas, la experiencia y las habilidades. Considere la posibilidad de trabajar con socios especializados en servicios AWS profesionales o en materia de AWS migración, que pueden proporcionarle especialistas que lo ayuden durante todo el proceso. Los criterios de priorización son una indicación inicial del orden en el que trasladará sus aplicaciones a la nube. Sin embargo, los grupos de dependencias serán los determinantes reales de las aplicaciones que se trasladarán en un momento dado. Esto se debe a que las aplicaciones que se clasifican como de alta prioridad pueden depender en gran medida de las aplicaciones que se encuentran en la mitad o en la parte inferior de la clasificación. La estrategia de migración también influirá en la composición de una ola. Por ejemplo, una aplicación de alta prioridad que requiere una estrategia de refactorización que puede requerir varias semanas o meses de análisis, diseño, pruebas y preparativos probablemente pase a una fase posterior. ## Crear un plan de oleada Un requisito previo para migrar una oleada de aplicaciones son los datos de la cartera de aplicaciones y la evaluación detallada de las aplicaciones del grupo de aplicaciones que se migrarán en la oleada. La evaluación detallada debe incluir la lista de aplicaciones de la oleada, los detalles de la infraestructura asociada, un diseño objetivo y una estrategia de migración para cada aplicación. Establecer la propiedad y el gobierno de la oleada es clave para gestionar y hacer un seguimiento del trabajo de la oleada, las dependencias de los programas, la gestión de los cambios, los problemas y los riesgos. Asegúrese de que exista un marco de gobierno para gestionar el plan. Para delinear el plan de oleaje, comience con una construcción de oleaje predeterminada. ¿Qué ocurre dentro de una ola? Una vez definida la entrada inicial, la onda puede comenzar. Por lo general, las actividades serán: 1. Perfeccione el plan de transición. Esta actividad debería describir los manuales y las medidas que se deben tomar en el momento de la migración, incluida la coordinación con otros equipos internos y externos. 1. Perfeccione el plan de reversión. ¿Qué se debe hacer para anular las aplicaciones si las cosas salen mal? 1. Prepare la infraestructura de destino. Por ejemplo, puede crear o ampliar la zona de AWS aterrizaje (seguridad Cuenta de AWS, redes, servicios de infraestructura u otra infraestructura de apoyo). 1. Pruebe la infraestructura de destino. 1. Utilice las herramientas de migración. Por ejemplo, instale agentes de replicación e inicie la transferencia de datos. 1. Lleve a cabo un plan de transición y ejecute los simulacros. Agrupe a todos los miembros del equipo participantes y revise todos los pasos con antelación. 1. Supervise la replicación de datos y las implementaciones de infraestructura. 1. Confirme que la infraestructura y las aplicaciones están listas para operar en AWS. 1. Confirme la preparación para la seguridad. 1. Confirme los requisitos normativos y de conformidad (por ejemplo, la validación de la carga de trabajo antes y después de la migración), si procede. 1. Migre las aplicaciones AWS y realice las pruebas previas a la puesta en marcha. 1. Proporcione soporte posterior a la migración durante un período de tiempo, como 3 días, cuando los equipos de operaciones y de migración estén totalmente disponibles para resolver los problemas y aplicar las optimizaciones. 1. Realice una revisión posterior a la migración. Documente las lecciones aprendidas e incorpórelas a las olas del futuro. 1. Cierre la ola confirmando el traspaso operativo y obteniendo métricas para la elaboración de informes. La duración de cada una de estas actividades dependerá de la complejidad del alcance, la capacidad de la ola, las personas involucradas y sus circunstancias únicas. Siempre que sea posible, es preferible utilizar oleadas más pequeñas, ya que reducirán el impacto de cualquier retraso o bloqueo de la migración. Determina, con tus equipos, cuál será la duración predeterminada de una oleada. A continuación, proceda a analizar las fechas para crear una estructura inicial de alto nivel de oleadas vacías (sin ninguna aplicación asignada todavía). Tenga en cuenta las siguientes preguntas: + ¿Cuál es la duración total del programa de migración? + ¿Cuáles son los plazos? + ¿Hay fechas de salida fijas de los centros de datos? + ¿Hay fechas de finalización de los contratos de colocación? + ¿Cuáles son los ciclos de actualización de las aplicaciones y la infraestructura? + ¿Cuáles son los ciclos de mantenimiento y lanzamiento de las aplicaciones? + ¿Hay alguna fecha en la que deban evitarse las migraciones (por ejemplo, los ciclos de lanzamiento y mantenimiento, fin de año, días festivos, procesamiento de fin de mes)? Con estas consideraciones, trace las olas en un plan. Para acelerar el proceso de migración, recomendamos superponer las oleadas siempre que sea posible. La clave de la superposición de ondas es definir y considerar lo que ocurre dentro de una ola. Por lo general, las actividades de despliegue, la validación de la infraestructura de destino y la sincronización de datos se llevan a cabo durante la primera mitad de una oleada. La segunda mitad se centrará en la migración, las pruebas y el traspaso operativo propiamente dichos. Esto significa que participan diferentes equipos en cada mitad del proceso y que se puede obtener cierta eficiencia. Por ejemplo, tan pronto como el equipo implicado en la preparación de la infraestructura objetivo haya completado su trabajo, podrá empezar a trabajar en los requisitos de la próxima oleada. En general, es preferible que la mayoría de las olas tengan una longitud y una estructura similares para facilitar un enfoque de migración similar al de una fábrica. Sin embargo, durante el proceso de planificación de las olas, el tamaño de una ola determinada puede ampliarse para cumplir con las dependencias o los requisitos operativos. A continuación, en función de los grupos de dependencias que se hayan identificado, determine el tamaño máximo de una ola en términos del número de grupos de dependencias que puede contener. El tamaño de la ola suele estar determinado por el apetito por el riesgo (por ejemplo, cuánto cambio paralelo se puede tolerar) y la disponibilidad de recursos (por ejemplo, cuánto cambio paralelo se puede realizar con los recursos, las habilidades y el presupuesto disponibles). Sin embargo, durante la planificación temprana, no se deje limitar por las necesidades y la disponibilidad de los recursos. Las ondas que contienen más de un grupo de dependencias se pueden descomponer en ondas más pequeñas en futuras iteraciones. Una vez confirmados los grupos de dependencias de una oleada determinada, revise los requisitos de recursos para migrar la oleada. Considere ajustar el tamaño de la onda (la cantidad de grupos de dependencias que contiene) en función de las necesidades de recursos. Esto podría provocar olas más pequeñas o más grandes. Repite el plan de olas según sea necesario hasta que se hayan definido todas las olas. ## Gestionar el cambio La cartera de aplicaciones y la infraestructura asociada cambiarán durante el ciclo de vida de los programas de migración. Los programas de migración de larga duración coexisten con la evolución y los cambios normales de la empresa. Las aplicaciones siguen evolucionando a medida que esperan ser migradas. Se agregan o quitan servidores y la nueva infraestructura se implementa en las instalaciones. Se espera que el alcance de una oleada o grupo de dependencias requiera cambios. Los cambios son necesarios, especialmente cuando, cuando se acerca la fecha de migración, se identifica una dependencia previamente desconocida o se incluye un nuevo servidor en el inventario. A veces, esto puede ocurrir durante la propia migración. Los cambios de alcance afectan a los grupos y oleadas de dependencias. Para gestionar los cambios y minimizar el impacto, es importante establecer un mecanismo de control del alcance. Un mecanismo de control del cambio de ámbito requiere la definición de una única fuente de información veraz para el ámbito. Podría ser una herramienta para administrar el ámbito o un archivo, hoja de cálculo o base de datos .csv, tal como se define en la gobernanza del programa de migración. Debe identificar los cambios, analizar el impacto y comunicarlos a las partes interesadas pertinentes para que puedan tomar medidas. Como resultado, el plan de oleaje se iterará. # Modelo de negocio detallado En esta etapa, recomendamos validar y ampliar el alcance del modelo de negocio para proporcionar un mayor nivel de detalle que respalde el programa de transformación. El modelo de negocio orientativo inicial, que se elaboró rápidamente, está diseñado para ofrecer la confianza suficiente para invertir en las etapas fundamentales y en el siguiente nivel de planificación detallada. La elaboración de un modelo de negocio detallado apoya este proceso de planificación de las siguientes maneras: + Proporcionar análisis financieros que sirvan de base para tomar decisiones sobre lo que se debe migrar y modernizar, las opciones que se deben seleccionar y la forma de escalonar y priorizar el trabajo + Validar, refinar y desarrollar el argumento financiero direccional original mediante un nuevo examen detallado: + El potencial de reducción de costos de infraestructura + La productividad interna de la TI y cualquier eficiencia de las operaciones subcontratadas + Las estimaciones de las inversiones necesarias para la configuración, migración y modernización del programa + Identificar, estimar la escala y configurar el proceso para rastrear los demás factores de valor que aporta la migración En el modelo de negocio detallado, debe establecer lo siguiente: + La base objetiva sobre la que garantizar el mandato y la inversión necesarios para implementar al menos la primera fase de la migración + La expectativa de desempeño financiero mínima de referencia para el programa + Claridad sobre la base financiera sobre la que se toman las diversas decisiones de diseño y priorización de la migración, de modo que, cuando las circunstancias y las personas cambien a lo largo del programa, los nuevos líderes puedan tomar decisiones informadas. + Una vez que los datos de uso iniciales estén disponibles a medida que las cargas de trabajo se migren y comiencen a funcionar, se analizarán las áreas incrementales de optimización de costos + Estimaciones del valor que la transformación de la nube aporta a la empresa al aumentar la resiliencia y la agilidad + Las métricas y las suposiciones asociadas KPIs se utilizan para estimar el rendimiento financiero derivado de una mejora de la resiliencia y la agilidad, que luego constituyen la base de referencia para impulsar la obtención de los principales beneficios del programa ## Determine los escenarios necesarios para el caso Al elaborar el modelo de negocio detallado, normalmente es necesario desarrollar varios escenarios para respaldar los distintos fines para los que se utiliza el modelo de negocio. **Escenario de cambio mínimo**: para evaluar la expectativa mínima de rendimiento financiero, prepare un escenario que asuma el cambio mínimo esperado en el status quo. Este escenario, en el peor de los casos, es un apoyo útil a la hora de obtener el mandato de invertir en la migración. Este escenario modela el grado mínimo esperado de crecimiento de la capacidad y los cambios mínimos para quality-of-service atender otras necesidades, como la disponibilidad y la resiliencia. El menor cambio genera el menor costo y la menor ineficiencia de recursos para el modelo operativo actual. **Escenario más probable**: para fundamentar la estrategia del programa y las decisiones de priorización, prepare el escenario que refleje lo que la empresa espera que suceda. Este escenario debería incluir el probable aumento o reducción de la utilización máxima y los costos de actualización para satisfacer la demanda empresarial de altos niveles de calidad de servicio (especialmente de disponibilidad y resiliencia). **Otros escenarios específicos**: cuando aún sea necesario hacer una suposición que pueda tener un gran impacto en el modelo de negocio, desarrolle escenarios tanto para los que la suposición sea cierta como para los que no. Sin embargo, recomendamos mantener el número de estos escenarios alternativos al mínimo absoluto. Crear más de tres o cuatro escenarios en total ralentiza el progreso y resulta caro, confuso y difícil de mantener. Siempre que sea posible, realice experimentos y trabaje para eliminar suposiciones más amplias. ## Valide y perfeccione el modelo de costes de infraestructura y migración Una vez que haya completado el análisis de la cartera y preparado el diseño y el tamaño del objetivo Servicios de AWS, ajuste las estimaciones de los costes de funcionamiento para el modelo operativo actual (COM) y el modelo operativo futuro (FOM) AWS para cada escenario. Por lo general, es necesario refinar las estimaciones para lo siguiente: + **Costes de la infraestructura COM** del hipervisor, el servidor host, el servidor básico, el almacenamiento, el dispositivo de red, las actualizaciones del hardware del dispositivo de seguridad, la instalación y el mantenimiento. Calcúlelos con los precios reales y los niveles de descuento para la capacidad necesaria para el escenario. + Los **costos de los centros de datos y las instalaciones compartidas de COM**, incluidos el espacio, la refrigeración, la alimentación, los racks, el sistema de alimentación ininterrumpida (UPS), el cableado y los sistemas de seguridad física, dimensionados para el crecimiento y especificados para cumplir con la capacidad, y los niveles de alta disponibilidad y recuperación ante desastres (DR) para el escenario. + **Los costos de los servicios de red COM**, incluidos los costos de los enlaces WAN, las redes de entrega de contenido y las redes privadas virtuales (VPNs), se calculan utilizando los precios contratados para las necesidades de conectividad, ancho de banda, rendimiento y latencia del escenario. + **Los costos del software de infraestructura y aplicaciones COM** se basan en los contratos existentes para cubrir el aumento o la reducción del uso según el escenario. + **Los costos de los servicios AWS públicos de FOM**, incluidos el soporte técnico y los servicios gestionados, según sea necesario, se basan en la refinada arquitectura de servicios, el tamaño de las instancias, el modelo de precios preferido, el uso esperado y la volatilidad del uso. + **Las licencias de aplicaciones FOM** se basan en el diseño final de la aplicación, la configuración de la infraestructura en la que se ejecutan las aplicaciones, el crecimiento a lo largo del tiempo y las normas de transferibilidad de las licencias. + **Estimaciones de los costos de migración y modernización de FOM**, ajustadas para reflejar el plan de migración de referencia para el escenario y detalladas para proporcionar los costos de cada carga de trabajo, especialmente de las que se deben volver a configurar, volver a comprar o refactorizar. + **Los costos de desmantelamiento del FOM**, incluidas las estimaciones de los costos de cancelación de activos y rescisión anticipada de contratos, revisados para reflejar el momento de desmantelamiento en el plan de migración de referencia, la verificación de qué activos se pueden reutilizar y qué activos se pueden cambiar para minimizar las amortizaciones y el costo de enajenación de los activos físicos y los medios. + **Los costos de ejecución paralela de la migración** se refinaron para reflejar el momento de cada transición de migración y cada desmantelamiento de los servicios existentes. ## Perfeccione la productividad de TI y las operaciones de TI y apoye el modelo de valor de la eficiencia Al igual que con el modelo de negocio direccional, existen dos enfoques principales para refinar y desarrollar el modelo de valor en torno a las operaciones y el soporte de TI. El enfoque que elija depende de si la COM se gestiona internamente o con contratistas o servicios subcontratados: *Mejora de la productividad del equipo interno* Cuando las operaciones y el soporte de TI se gestionan internamente, el modelo empresarial se centra en lo siguiente: + Identificar y cuantificar los beneficios de productividad derivados de la migración y de cualquier automatización operativa incluida en el ámbito + Validar que el tiempo libre para el equipo interno se pueda destinar de manera fácil y productiva a otras actividades que suelen ser de mayor valor, lo que brinda oportunidades de progreso y una mayor recompensa para el equipo y más valor para la organización Evalúe cuánto tiempo dedica cada miembro de cada rol del equipo a sus distintas actividades habituales y obtenga orientación sobre la reducción prevista de la carga de trabajo para las distintas actividades. La siguiente tabla proporciona una guía inicial sobre los niveles típicos de reducción de la carga de trabajo por actividad para las tareas que consumen la mayor parte de las operaciones de TI y el esfuerzo de apoyo a las distintas funciones del equipo. La tabla incluye una descripción de cómo se logra la productividad. **nota** Las actividades enumeradas suelen ser realizadas por miembros del equipo que desempeñan diferentes funciones, por lo que el ahorro de productividad que supone cada tarea debe evaluarse teniendo en cuenta todas las funciones del equipo. Por ejemplo, en los equipos de operaciones de TI organizados por torre de infraestructura (por ejemplo, computación, almacenamiento y redes), la planificación y el presupuesto de los gastos de capital pueden ser habituales para los líderes de cada torre. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html) La siguiente tabla muestra los ahorros esperados para cada nivel de reducción de la carga de trabajo. | **Nivel** | **Previsto** | | --- | --- | | Muy alta | 85% - 100% | | Alto | 60% - 90% | | Medio | 30% - 70% | | Bajo | 10% - 35% | | Minimal | 0% - 10% | Estas métricas proporcionan un punto de partida para evaluar las ganancias de productividad e incluirlas en el modelo de negocio detallado. Los aumentos de productividad reales varían en función de la situación específica. Puede resultar útil calcular los ahorros de productividad tanto en el punto medio como en el extremo inferior de los rangos para estimar escenarios típicos y conservadores. A medida que el programa avanza, resulta útil recopilar datos reales sobre el tiempo dedicado a cada actividad por función. Esos datos crean una base mejorada para estimar las operaciones y respaldan los costos de los nuevos proyectos y la expansión de los servicios. *Las operaciones de TI subcontratadas y la reducción de los costos de soporte* [Cuando las operaciones y el soporte de TI se subcontratan o gestionan principalmente con contratistas, la asignación de costos para el futuro modelo operativo (FOM) se puede preparar solicitando cotizaciones a los AWS socios que ofrecen soluciones de servicios gestionados, incluida la AWS dirigida por socios (AMS AWS Managed Services ).](https://aws.amazon.com/managed-services/partners/) También puede ponerse en contacto con su gestor de AWS cuentas y solicitar directamente el precio de AMS, tal y como se describe en la subsección sobre cómo incorporar la [optimización de los costes operativos, incluida en](directional-business-case.md#building-operational-cost-optimization) la sección [Creación de un](directional-business-case.md) modelo de negocio orientado. Para obtener un modelo de negocio detallado, sustituya cualquier cifra de referencia por una cotización basada en la lista de materiales revisada AWS y el consumo de servicio previsto, el paquete AMS y cualquier opción necesaria, así como el nivel de servicio necesario. El costo tendrá un componente de implementación único y una tasa de ejecución basada en el consumo. Incluya las operaciones de TI restantes, el soporte que deba contratarse para cualquier servicio al que no se vaya a AWS migrar y un costo único en caso de que se produzca alguna penalización contractual (por ejemplo, por rescisión anticipada). ## Desarrolle el modelo de valor de la resiliencia Además AWS, puede crear una amplia gama de arquitecturas de alta disponibilidad, recuperación ante desastres y tolerantes a errores. Los precios basados en el consumo significan que los servicios solo se cobran cuando se utilizan. En conjunto, estos dos factores proporcionan una rentabilidad excepcional en aras de la resiliencia. Además, AWS los clientes lo han estado utilizando para mejorar la resiliencia de sus cargas de trabajo. La [encuesta de IDC de 2018](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) ofrece ejemplos de clientes participantes que logran reducir en un 73 por ciento las interrupciones al año, reducir en un 58 por ciento el tiempo medio de recuperación (MTTR) y reducir en un 94 por ciento la pérdida de productividad. La misma encuesta mostró que los beneficios financieros derivados de una mayor resiliencia eran un 50 por ciento superiores a los beneficios de reducción de costos de la infraestructura de TI. Además, se logra una mayor resiliencia mediante la modernización del ciclo de vida del desarrollo del software para las aplicaciones. Cuando se CI/CD introducen procesos de automatización de pruebas para aumentar la agilidad empresarial, los defectos del software se detectan en una fase más temprana del ciclo de desarrollo, lo que reduce considerablemente los costes de mantenimiento del software. **Para evaluar e incluir este valor en el modelo de negocio, primero trabaje con los propietarios de las empresas de aplicaciones para hacerse una idea de las *ventajas totales que ofrece* cada carga de trabajo que se vaya a migrar.**Esto podría incluir los siguientes elementos: + El número, la duración media y la naturaleza de las interrupciones del servicio: + Entre los ejemplos de interrupciones del servicio se incluyen las interrupciones del servicio, la ralentización del rendimiento, el exceso de tiempo planificado por lotes y de mantenimiento, los errores en las funciones clave y la limitación del acceso durante los períodos de mayor actividad. + Impacto en los ingresos por las interrupciones de los servicios generadores de ingresos, como los sistemas de comercio electrónico: + El número probable de transacciones que no se puedan completar debido a la interrupción del servicio, en función del tiempo de interrupción y las tasas de transacción + Valor promedio de cada transacción afectada + El coste adicional que supone para los ingenieros ayudar a resolver los defectos en los sistemas de producción en comparación con el coste de descubrirlos en una fase más temprana del proceso de desarrollo + Impacto en la productividad de los usuarios internos y en el coste del tiempo perdido A continuación, evalúe la reducción esperada y más conservadora del tiempo perdido debido a las interrupciones del servicio**** que debería producir el aumento de la resiliencia. Por ejemplo, considere la posibilidad de incluir los siguientes elementos: + Reducción del número de interrupciones y del MTTR mediante arquitecturas de alta disponibilidad y una mejora del objetivo de tiempo de recuperación (RTO) y del objetivo de punto de recuperación (RPO) + Reducción de las ralentizaciones, eliminación de la limitación de la capacidad y prevención de sobrecargas en el procesamiento por lotes, gracias a funciones como el escalado automático + Se ha reducido el número de errores en las aplicaciones que solo se descubren en la fase de producción, mediante la implementación de CI/CD procesos y las pruebas de regresión automatizadas en la infraestructura, estructurada y degradada para minimizar los costes Combínelos para obtener la cartera de aplicaciones que se van a migrar y modernizar, y calcule las cifras de valor empresarial esperadas y más conservadoras para cada año del caso. Los beneficios deberían aumentar de acuerdo con el calendario de migración y, posteriormente, aumentar su volumen en función de las expectativas de crecimiento del uso de las aplicaciones participantes. ## Desarrolle el modelo de valor de la agilidad empresarial La agilidad empresarial es la razón principal por la que AWS los clientes migran al AWS. La [encuesta de 2018 de IDC](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) AWS a los clientes indicó que, para ellos, los beneficios de la agilidad empresarial representaron el 47 por ciento del total de los beneficios medidos y más de cinco veces los beneficios derivados de la reducción de los costos de infraestructura. Predecir con precisión todos los beneficios de agilidad empresarial que se derivarán de cualquier transformación es todo un desafío. Sin embargo, al centrarse en las aplicaciones que admiten un gran número de usuarios o que son fuentes de diferenciación empresarial, puede modelar e incluir una parte importante de este beneficio en el modelo de negocio detallado básico. A medida que avance la migración, perfeccione y amplíe gradualmente el modelo de valor de la agilidad empresarial a medida que se vayan cuantificando más beneficios. Esto hace que el modelo de negocio siga siendo relevante, de modo que se pueda utilizar como la principal herramienta de apoyo a la toma de decisiones con la que dirigir el programa. Para crear el modelo de valor de la agilidad empresarial, utilice la siguiente guía: + Seleccione las cargas de trabajo que tengan la oportunidad de impulsar la mayor mejora del rendimiento empresarial, como: + Cargas de trabajo generadoras de ingresos + Cargas de trabajo de operaciones empresariales con posibilidades de aumentar la eficiencia y reducir los costes de la empresa + Herramientas de productividad empresarial compatibles con grandes bases de usuarios + Para obtener cargas de trabajo que generen ingresos y eficiencia, haga lo siguiente: + Realice una evaluación realista y más conservadora del crecimiento de los ingresos o la eficiencia operativa que cabría esperar que generaran las actualizaciones de aplicaciones importantes y secundarias. + Calcule el aumento del número de versiones principales y secundarias por año que permite AWS aumentar la velocidad de desarrollo de las aplicaciones y reducir el tiempo de implementación de la infraestructura. En el informe de IDC se proporcionan algunas métricas de referencia al respecto. + Calcule las expectativas de beneficios realistas y más conservadoras. Haga un mapeo a lo largo del período considerado, teniendo en cuenta la posibilidad de alcanzar la máxima eficiencia algún tiempo después de que se hayan migrado las cargas de trabajo respectivas. + Para las herramientas de productividad empresarial, haga lo siguiente: + Realice una evaluación realista y más conservadora del ahorro de tiempo que cabría esperar que generaran las actualizaciones de aplicaciones importantes y secundarias. + Calcule el costo promedio del tiempo y el esfuerzo de las personas en la base de usuarios afectada. + Utilice las cifras para aumentar la frecuencia de las publicaciones principales y secundarias y calcule los beneficios a lo largo del plazo del modelo de negocio. Como el aumento de la productividad de los desarrolladores y la reducción del tiempo de lanzamiento no requieren recursos adicionales, añada las líneas de beneficios netos para cada carga de trabajo al modelo de flujo de caja del modelo de viabilidad para incluirlas en los cálculos del flujo de caja descontado, el VAN, el ROI, el MIRR y la amortización.