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.
# Tarea 4: Definir el proceso de análisis profundo de la aplicación
Ahora que ha terminado de establecer las reglas y los procesos para la priorización de las aplicaciones, realice un análisis profundo de las aplicaciones que le ayudará a refinar la prioridad de cada aplicación. Realiza el análisis profundo de la aplicación en una aplicación a la vez, en orden de mayor a menor prioridad. En el caso de proyectos con varios equipos de cartera, cada equipo puede realizar un análisis exhaustivo de la aplicación en una aplicación diferente al mismo tiempo.
Durante el análisis profundo, es posible que se produzcan algunos problemas inesperados, como las dependencias, que afecten a la complejidad de la migración de la aplicación. Cuando esto suceda, debe modificar los criterios de puntuación de complejidad que definió en el paso anterior y actualizar la hoja de puntuación en consecuencia para obtener puntuaciones de complejidad más precisas para futuras aplicaciones. A continuación, puede actualizar las prioridades de la aplicación utilizando las nuevas puntuaciones de complejidad.
Esta tarea consta de los siguientes pasos:
+ [Paso 1: Definir el proceso del taller de solicitud](#deep-dive-1)
+ [Paso 2: Definir el proceso de mapeo de la aplicación](#deep-dive-2)
+ [Paso 3: (opcional) Defina el estado objetivo de la aplicación](#deep-dive-3)
+ [Paso 4: Finalice el proceso de análisis profundo de la aplicación](#deep-dive-4)
## Paso 1: Definir el proceso del taller de solicitud
El proceso del taller es uno de los enfoques más eficientes para profundizar en la aplicación. Con este proceso, colaboras con las partes interesadas, los propietarios de las aplicaciones y el equipo del portafolio para evaluar y analizar la aplicación. El objetivo es comprender claramente el estado actual de la aplicación, incluida su arquitectura, su finalidad empresarial, sus dependencias y su entorno. A continuación, utilice esta información detallada sobre el tamaño y la complejidad de la aplicación para diseñar el estado objetivo de la aplicación.
Cada taller suele durar de 1 a 8 horas, aunque es posible que necesite más tiempo para aplicaciones de alta complejidad. También puede dividir el taller en varias reuniones, según la disponibilidad de los recursos, sus preferencias y el tamaño y la complejidad de la aplicación.
### Identifique los resultados esperados
Antes de llevar a cabo un taller de aplicación, debe establecer una agenda y definir los resultados esperados del taller, o la información que debe recopilar en el taller. Esto permite a los participantes del taller prepararse para el taller, ayuda a mantener la reunión dentro del objetivo previsto y garantiza que, al final del taller, dispongas de toda la información necesaria para priorizar, planificar y migrar la aplicación.
Le recomendamos que defina un conjunto estándar de resultados esperados y los documente en su manual de priorización de aplicaciones. Al preparar un taller, utilice los resultados esperados estándar y añada otros nuevos para la aplicación específica.
Defina el conjunto estándar de resultados esperados para los talleres de aplicación de la siguiente manera:
1. Abra el manual de priorización de aplicaciones.
1. En la sección de *resultados esperados del taller de aplicación*, establezca un conjunto estándar de resultados esperados para los talleres de aplicación. Al preparar un taller, puede personalizarlos para adaptarlos a las necesidades específicas de la aplicación.
1. Guarde el manual de priorización de aplicaciones.
1. Mantenga los resultados esperados en el manual de priorización de aplicaciones. A medida que lleve a cabo talleres de aplicación y continúe con la evaluación de la cartera y la planificación de la oleada, podría identificar los nuevos resultados esperados o refinar los resultados existentes.
Los siguientes son ejemplos de los resultados esperados del taller de aplicación.
****
| Priority (Prioridad) | Resultado esperado del taller de aplicación |
| --- | --- |
| 1 | Comprensión clara de la arquitectura actual de la aplicación, incluidos los servidores asociados, las dependencias, el entorno y el nivel de la aplicación. |
| 2 | El equipo recopiló los metadatos para respaldar el diseño de la arquitectura de destino. Se requieren los siguientes metadatos:[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 3 | El cuestionario para el propietario de la solicitud está completo y se han respondido todas las preguntas clave. |
| 4 | El equipo ha recopilado toda la documentación de la aplicación, como la guía del usuario, la documentación sobre la arquitectura de la aplicación, la documentación de pruebas, la documentación de diseño y la documentación de la interfaz de programación de aplicaciones (API). |
### Defina las reglas del taller de aplicaciones
Antes de llevar a cabo un taller de aplicación, debe definir las reglas que regirán su taller. Las normas habituales incluyen la duración del taller, las herramientas que podrían necesitarse en el taller y cualquier consideración de programación o fecha límite que deba tenerse en cuenta. Esto ayuda a mantener la reunión dentro del plazo previsto y garantiza que las decisiones que se tomen en el taller se ajusten al calendario de migración.
Le recomendamos que documente las reglas del taller de aplicaciones en su manual de priorización de aplicaciones.
Defina las reglas del taller de aplicaciones de la siguiente manera:
1. Abra el manual de priorización de aplicaciones.
1. En la sección de *reglas del taller de aplicación*, defina las reglas que rigen sus talleres.
1. Guarde el manual de priorización de aplicaciones.
1. Mantenga las reglas en el manual de priorización de aplicaciones. A medida que organice talleres de aplicación y continúe con la evaluación de la cartera y la planificación de la oleada, podría identificar nuevas reglas o perfeccionar las existentes.
Los siguientes son ejemplos de reglas para el taller de aplicación.
****
| Priority (Prioridad) | Regla del taller |
| --- | --- |
| 1 | Los talleres deben programarse para un máximo de 2 horas por sesión los martes y jueves. |
| 2 | Hay una congelación programada de la infraestructura del 1 de diciembre al 15 de enero. |
| 3 | Hay un taller práctico sobre herramientas de migración. |
| 4 | El contrato del centro de datos vencerá el 31 de marzo. Las cargas de trabajo deben evacuarse antes del 31 de marzo para evitar sanciones y costosas extensiones de contratos. |
| 5 | Se conservarán la solicitud biométrica y la solicitud de hora y asistencia. |
### Defina el proceso de solicitud al taller
Es importante que defina un proceso estándar para llevar a cabo los talleres de solicitud. Esto garantiza una experiencia coherente y establece expectativas para los participantes del taller, lo que puede mejorar la eficiencia del taller.
El proceso del taller de solicitud consta de tres etapas:
+ **Prepárese para el taller**: prepararse para el taller ayuda a garantizar que la sesión se desarrolle sin problemas y a que los participantes sepan lo que se espera. Para prepararse para el taller, debe establecer una agenda y definir los resultados esperados, identificar a los participantes, las herramientas y la información necesaria para el taller, y programar el taller. Al programar el taller con al menos una semana de antelación, el equipo tendrá tiempo para programar su calendario, prepararse para el taller y recopilar cualquier información útil.
+ **Organizar el taller**: al realizar el taller, limite la discusión a los puntos de la agenda y asegúrese de cumplir con los resultados esperados. Anote los temas que considere útiles pero que no estén incluidos en su agenda. Puede resultar útil grabar el taller.
+ **Finalice los resultados del taller**: una vez finalizado el taller, su equipo debe tener una idea clara del estado actual de la aplicación y de los posibles problemas, riesgos, desafíos y obstáculos que podrían afectar a la priorización y la migración. Las tareas habituales después del taller incluyen: volver a priorizar la aplicación, redactar el futuro estado de la aplicación y actualizar el manual con los resultados, las reglas o los cambios de proceso esperados que puedan ser útiles en el próximo taller.
La *plantilla del manual para la priorización de las solicitudes* incluye un step-by-step proceso estándar para preparar, llevar a cabo y finalizar un taller sobre aplicaciones. Defina el proceso del taller de solicitud de la siguiente manera:
1. Abra el manual de priorización de aplicaciones.
1. En la sección sobre el *proceso del taller de aplicaciones*, modifique el proceso estándar para adaptarlo a las necesidades de su caso de uso.
1. Guarde el manual de priorización de aplicaciones.
1. Mantenga el proceso en el manual de priorización de aplicaciones. A medida que realice talleres de aplicación, puede identificar los cambios que desee realizar en este proceso.
### Paso a paso: criterios de salida
+ Ha definido la agenda del taller y los recursos y artefactos necesarios para apoyar el taller.
+ Ha definido el resultado esperado del taller y ha identificado la información que debe recopilar en el taller.
+ Ha realizado una prueba del proceso del taller y cuenta con la información necesaria para respaldar el mapeo de aplicaciones y diseñar el estado objetivo.
+ Ha documentado lo siguiente en su manual de priorización de aplicaciones:
+ Resultados esperados del taller de aplicación
+ Reglas del taller de aplicación
+ Proceso del taller de solicitud
## Paso 2: Definir el proceso de mapeo de la aplicación
El *mapeo de aplicaciones* es el proceso de asignar cada aplicación a un patrón de migración, que usted identificó y validó. [Paso 4: Validar los patrones de migración](discovery.md#discovery-4) En este paso, defina las reglas que utilizará para evaluar la aplicación. A continuación, defina el proceso que utilizará para evaluar cada solicitud. Al asignar cada aplicación al caso de uso del patrón de migración, podrá identificar la herramienta de migración, las habilidades necesarias para completar la migración y la complejidad del patrón de migración.
No siempre se migra una aplicación a un patrón único. Para obtener más información sobre cuándo podría necesitar varios patrones para la misma aplicación, consulte [Defina el proceso de mapeo de la aplicación](#deep-dive-2-process) más adelante en esta sección.
### Reglas de mapeo de aplicaciones
Las reglas de mapeo de aplicaciones ayudan a evaluar la aplicación e identificar el patrón de migración adecuado. Cada regla consta de cualquier información que deba utilizar para evaluar la solicitud y cumplir los criterios del patrón.
En las [plantillas del manual de estrategias del portafolio](samples/portfolio-playbook-templates.zip), la *plantilla Runbook para la priorización de las aplicaciones* incluye una sección para documentar las reglas de mapeo de las aplicaciones. Defina su proceso de la siguiente manera:
1. Abra el manual de priorización de aplicaciones.
1. En la sección *Reglas de mapeo de aplicaciones, defina las reglas* de mapeo de aplicaciones.
1. Guarde el manual de priorización de aplicaciones.
1. Mantenga las reglas en el manual de priorización de aplicaciones.
La siguiente tabla proporciona ejemplos de reglas de mapeo de aplicaciones.
**nota**
El patrón IDs y los nombres de esta tabla corresponden a los patrones de muestra de[Paso 4: Validar los patrones de migración](discovery.md#discovery-4). Utilice el patrón IDs y los nombres que definió en el manual de priorización de aplicaciones.
****
| Priority (Prioridad) | Regla de mapeo |
| --- | --- |
| 1 | Con los datos de utilización o las herramientas de supervisión, identifique si la aplicación es una aplicación zombi o inactiva. Si la aplicación es una aplicación zombi o inactiva, elija el *patrón 8: retire la aplicación* y, a continuación, apague los servidores de la pila de aplicaciones. |
| 2 | Identifique si la migración de esta aplicación a la nube proporciona valor empresarial. Las aplicaciones que se utilizan únicamente de forma local y que no se comparten entre sucursales o ubicaciones geográficas, como las aplicaciones de horario y asistencia, normalmente no necesitan migrarse a la nube. Si la migración de esta aplicación no proporciona valor empresarial, elija *Pattern 9: Retain on premises*. |
| 3 | Identifique si el sistema operativo (SO) de la aplicación es compatible con los servicios de AWS migración AWS, un proveedor o su herramienta de migración de realojamiento y, a continuación, haga lo siguiente:[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 4 | Identifique si la aplicación tiene una versión de software como servicio (SaaS) o equivalente y, a continuación, evalúe los beneficios y los costos de migrar a esta nueva plataforma. Si se cumplen estos criterios, elija el *Patrón 10: Recompra y actualización a SaaS*. |
| 5 | Identifique si las bases de datos locales de la aplicación se pueden migrar a un servicio homogéneo en la nube, como la migración de una base de datos Oracle local a Amazon RDS for Oracle o la migración de una base de datos MySQL local a una base de datos Amazon Aurora MySQL Compatible Edition. Si se cumplen estos criterios, utilice *Pattern 2: Replatform to Amazon RDS mediante AWS DMS y*. AWS SCT |
| 6 | Identifique si la aplicación utiliza Microsoft.NET Core (.NET 5 o.NET 6), Java, PHP u otro lenguaje de programación de código abierto y si la aplicación está alojada en Microsoft Windows Server. Evalúe si el costo de la replataforma es justificable. Si se cumplen estos criterios, elija *Pattern 7: Replatform from Windows to Linux on Amazon EC2*. |
| 7 | Identifique el almacenamiento de archivos local y compartido local del que depende su aplicación y, a continuación, determine si debe incluirse en la migración. Si se debe migrar el almacenamiento de archivos local y compartido, elija *Pattern 4: Replatform to Amazon EFS using AWS DataSync o AWS Transfer Family*. |
| 8 | Identifique si los servidores de la aplicación son servidores de mainframe o de rango medio, como IBM AS/400 o Apache Spark, y confirme que las aplicaciones son compatibles con los emuladores. Si se cumplen estos criterios, utilice el *patrón 6: cambiar la plataforma de servidores centrales o de rango medio a Amazon EC2* mediante un emulador. |
| 9 | Identifique si se trata de una aplicación antigua, monolítica o basada en un mainframe que ya no puede satisfacer la demanda de la empresa debido a sus limitaciones. Por ejemplo, identifique si la aplicación puede ampliarse, integrarse con aplicaciones relacionadas o si es cara y difícil de mantener. Si la aplicación cumple alguno de estos criterios, elija el *Patrón 11: Rediseñar la aplicación*. |
### Defina el proceso de mapeo de la aplicación
Al mapear las aplicaciones a los patrones de migración, resulta útil solicitar al equipo de descubrimiento los datos de descubrimiento de la aplicación. Estos datos suelen incluir información como un patrón de migración recomendado (a veces denominado *patrón R* o *puntuación R*), información de utilización, dependencias de las aplicaciones y otra información que puede utilizar en la evaluación. Al explorar esta aplicación en detalle, es posible que decida cambiar el patrón de migración que se identificó anteriormente.
Cuando tenga los datos, podrá comparar la aplicación con los criterios comerciales y técnicos que identificó[Paso 2: Identifique los factores empresariales y técnicos](discovery.md#discovery-2). Ha registrado sus controladores en el manual de priorización de aplicaciones. Al evaluar la aplicación en función de los criterios, es posible que se seleccionen varios patrones de migración para la aplicación o que se eliminen los patrones en función del costo, el cronograma u otras limitaciones.
El siguiente es un ejemplo de un factor empresarial que requiere el uso de varios patrones de migración en una sola aplicación. Desea migrar una base de datos de SQL Server local a Amazon DynamoDB, pero dado que el contrato del centro de datos está a punto de caducar, la empresa desea migrarla antes de lo previsto para cambiarla de plataforma. Para abordar este factor empresarial, debe revisar el plan de migración de la aplicación para adoptar un enfoque basado en dos patrones. En primer lugar, debe volver a alojar la aplicación en la nube para eliminarla del centro de datos. Más adelante, una vez que la aplicación esté en la nube, puede cambiarla de plataforma de acuerdo con el cronograma propuesto.
También debe considerar si la aplicación es una aplicación de n niveles, es decir, una aplicación compuesta por varios niveles. Un *nivel de aplicación* es un grupo de servidores físicos que alojan las capas horizontales de la aplicación. Las aplicaciones de nivel N son más complejas porque cada nivel puede requerir una estrategia diferente y puede optar por migrar los niveles de aplicación en distintas fases. Por ejemplo, si tiene una aplicación compuesta por niveles de presentación, servicio empresarial y base de datos, existe la posibilidad de que pueda mapear un patrón diferente para cada nivel.
A continuación, evalúa la aplicación en función de las reglas de mapeo de aplicaciones, que definió en el manual de priorización de aplicaciones. Para obtener más información, consulte [Reglas de mapeo de aplicaciones](#deep-dive-2-rules) mencionado previamente en esta sección.
Tras asignar la aplicación a uno o más patrones, revise y verifique esta decisión con el propietario de la aplicación. El propietario de la aplicación debe confirmar el patrón seleccionado y ayudarlo a planificar y realizar la migración. En este momento, los propietarios de las aplicaciones también pueden proporcionar información basada en su experiencia o compartir cualquier problema que prevean con la migración.
Cuando haya asignado la aplicación a uno o más patrones de migración y los haya confirmado con el propietario de la aplicación, registre la aplicación, el identificador del patrón, el nombre del patrón y los factores relevantes en una tabla de mapeo de aplicaciones del manual de priorización de aplicaciones.
En las [plantillas del manual de estrategias de la cartera](samples/portfolio-playbook-templates.zip), la *plantilla Runbook para la priorización de aplicaciones incluye un proceso estándar para* el mapeo de aplicaciones. step-by-step Defina su proceso de la siguiente manera:
1. Abra el manual de priorización de aplicaciones.
1. En la sección sobre el *proceso del taller de aplicaciones*, modifique el proceso estándar para adaptarlo a las necesidades de su caso de uso.
1. Guarde el manual de priorización de aplicaciones.
1. Mantenga el proceso en el manual de priorización de aplicaciones.
La siguiente tabla es un ejemplo de tabla de mapeo de aplicaciones. La *plantilla Runbook proporcionada para la priorización de aplicaciones* incluye una tabla vacía en la que puede registrar los resultados del proceso de mapeo de aplicaciones.
**nota**
El patrón IDs y los nombres de esta tabla corresponden a los patrones de muestra de. [Paso 4: Validar los patrones de migración](discovery.md#discovery-4) Utilice el patrón IDs y los nombres que definió en el manual de priorización de aplicaciones.
****
| Nombre de la aplicación | ID del patrón | Nombre del patrón | Se abordaron los factores empresariales y técnicos |
| --- | --- | --- | --- |
| Sitio web corporativo | 1 | Realoje en Amazon EC2 mediante Application Migration Service o Cloud Migration Factory | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema de recursos humanos | 8 | Retire la aplicación | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Solicitud de tiempo y asistencia | 9 | Permanezca en las instalaciones | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema PO | 3 | Cambie la plataforma a Amazon EC2 mediante CloudFormation | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema CRM | 10 | Recompra y actualización a SaaS | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema de activos fijos | 7 | Cambie la plataforma de Windows a Linux en Amazon EC2 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Almacenamiento de archivos ERP | 4 | Cambie la plataforma a Amazon EFS mediante AWS DataSync o AWS Transfer Family | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema de contabilidad | 6 | Realoje servidores de mainframe o de rango medio en Amazon EC2 mediante un emulador | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Libro mayor | 11 | Rediseñe la aplicación | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
### Defina los criterios de salida
+ Ha documentado lo siguiente en su manual de priorización de aplicaciones:
+ Reglas de mapeo de aplicaciones
+ Proceso de mapeo de aplicaciones
+ Ha validado las reglas y los procesos de mapeo mediante una o más aplicaciones proof-of-concept (POC).
## Paso 3: (opcional) Defina el estado objetivo de la aplicación
En este paso, defina los atributos y el proceso que utilizará para documentar el estado objetivo, *o futuro*, de la aplicación. El estado objetivo es cómo funciona la aplicación en el entorno de nube de destino después de la migración. El entorno de destino varía en función de la plataforma o servicio de destino y de los requisitos empresariales. El entorno objetivo podría ser el Nube de AWS o AWS Managed Services (AMS).
Definir el estado objetivo ayuda a los directores de proyectos, los consultores de migración, los arquitectos, los propietarios de aplicaciones y las partes interesadas a colaborar de forma eficaz. Al utilizar este proceso, el equipo puede identificar y resolver los problemas por adelantado e implementar de manera más eficiente el entorno del estado objetivo.
Para algunas aplicaciones, este paso es opcional. Puede omitir este paso si la aplicación que va a migrar es independiente o de baja complejidad. Es posible que las estrategias de migración que no modifican la aplicación, como el realojamiento, no requieran este paso. Sin embargo, en el caso de estrategias de migración más complejas, como cambiar la plataforma y rediseñar la arquitectura, debe definir el estado objetivo antes de iniciar la migración.
El taller le proporciona una comprensión profunda del estado actual de la aplicación, por lo que es una buena idea redactar el estado objetivo una vez finalizado el taller. Además, mapear la aplicación según su patrón de migración proporciona información adicional y ayuda a identificar si es necesario definir el estado objetivo. Por ejemplo, si asigna la aplicación al patrón *Rehost to Amazon EC2 mediante Application Migration Service o Cloud Migration* Factory, habrá identificado que la estrategia es realojar y probablemente no necesite definir el estado de destino de esta aplicación.
### Atributos del estado objetivo
Al definir el estado de destino y tomar decisiones sobre la aplicación, le recomendamos que tenga en cuenta los siguientes atributos del estado de destino:
+ **AWS Well-Architected Tool**— Revise el estado objetivo de la aplicación comparándolo con el AWS marco de Well-Architected para ayudar a mejorar la seguridad, el rendimiento y la resiliencia de la aplicación en la nube.
+ **Zona de aterrizaje objetivo**: normalmente, al final de la [fase de movilización](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/mobilize-phase.html), deberías haber creado una zona de aterrizaje completa que esté lista para ejecutar aplicaciones piloto. La landing zone ya debería estar configurada con una arquitectura multicuenta, administración de identidad y acceso, gobernanza, seguridad de datos, diseño de red y registro. Utilizas una aplicación piloto para comprobar que la landing zone está completa. Comprueba que puedes lanzar y ejecutar tu aplicación piloto en la landing zone objetivo existente. Si necesitas modificar la zona de aterrizaje de la aplicación, informa al equipo de landing zone de tus requisitos. Por ejemplo, es posible que la aplicación requiera acceso a un servicio alojado en una cuenta independiente o que la aplicación requiera un enrutamiento especial a una nube privada virtual (VPC).
+ **Dependencias**: identifique las aplicaciones en las que se basa su aplicación para funcionar correctamente. Por ejemplo, su aplicación puede depender de bases de datos, almacenamiento o servicios de terceros, como una pasarela de pago o un servicio web externo, o puede depender de otras aplicaciones de su entorno. Para acceder a estas dependencias, es posible que necesite una configuración o un enrutamiento especiales, como conectarse a un servicio de directorio para la autenticación.
+ **Aplicaciones dependientes**: identifique cualquier aplicación que dependa de su aplicación para funcionar correctamente. Es posible que tenga que volver a configurar y actualizar estas aplicaciones para evitar el tiempo de inactividad durante la migración.
+ **Seguridad y conformidad**: revise el entorno de destino con el equipo de seguridad y conformidad e identifique cualquier deficiencia. La aplicación puede estar compuesta por varios componentes, capas lógicas o varios niveles. En función de sus requisitos de conformidad, es posible que no pueda migrar algunos de estos componentes al entorno de destino o que necesite medidas de seguridad adicionales al migrar la carga de trabajo. Los requisitos de seguridad y conformidad más comunes son la residencia de los datos, el cifrado en tránsito y el cifrado en reposo. Estos requieren una configuración adicional en el entorno de destino. Por ejemplo, es posible que necesite configurar los certificados para proteger las comunicaciones o que necesite claves de cifrado para proteger los datos en reposo. Es posible que también necesite seleccionar varios patrones de migración para la aplicación, de modo que algunos niveles de la aplicación permanezcan en las instalaciones y otros se migren a la nube.
+ **Dependencias de almacenamiento: revise las** dependencias de almacenamiento de las aplicaciones y determine cómo afectaría a estas dependencias la migración de la aplicación al entorno de destino. Por ejemplo, si la aplicación depende del almacenamiento en red, como un almacenamiento conectado a la red (NAS) o una red de área de almacenamiento (SAN), debe planificar un servicio de almacenamiento en la nube, como Amazon Simple Storage Service (Amazon S3) o Amazon. FSx También debe planificar cómo migrará sus datos al entorno de nube de destino para mantener la aplicación en funcionamiento.
+ **Base de datos**: revise la estrategia de migración de cualquier base de datos que utilice la aplicación. ¿Va a cambiar de plataforma a un nuevo servicio de base de datos, como Amazon Relational Database Service (Amazon RDS), Amazon Aurora o Amazon DynamoDB? ¿Va a realojar su base de datos en el entorno de destino? En algunos casos, especialmente en el caso de una base de datos monolítica, es necesario refactorizar la base de datos para cumplir con los requisitos técnicos, como la latencia inferior a un segundo, o para aprovechar las características de un tipo concreto de base de datos. AWS Al igual que ocurre con los requisitos de conformidad con la residencia de los datos, es necesario identificar qué datos deben conservarse en las instalaciones y cuáles deben migrarse a la nube. Por ejemplo, es posible que necesite conservar una tabla de base de datos local para la información de los clientes y migrar el resto de la base de datos a la nube.
+ **Componentes de la aplicación**: revise los componentes de los que depende su aplicación. Determine si la aplicación depende de un componente que no sea compatible con el entorno de destino. Si el entorno de destino no admite todos los componentes de la aplicación, debe refactorizar la aplicación para mitigar el problema. Por ejemplo, si tiene una aplicación.NET Framework que depende de componentes exclusivos de Windows, como la interoperabilidad del Modelo de Objetos Componentes (COM), COM\+ o el registro de Windows, para cambiar la plataforma de la aplicación en un sistema operativo Linux, debe refactorizar la aplicación a .NET Core.
+ Niveles de **aplicación: identifique el número de niveles** de la aplicación. ¿La aplicación tiene un nivel, dos niveles o es independiente? Confirme que entiende el patrón de migración de cada nivel. Por ejemplo, su aplicación puede tener un nivel de presentación (o *web*) que aloje la interfaz de usuario, un nivel de aplicación que aloje los servicios empresariales y un nivel de base de datos que aloje las bases de datos, y cada nivel puede requerir un patrón de migración diferente.
+ **Recuperación ante desastres**: identifique el plan de recuperación ante desastres (DR) actual y futuro de la aplicación, incluidos el objetivo del punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO). Decida si desea utilizar el plan de recuperación ante desastres local existente o explorar una nueva estrategia de recuperación ante desastres en la nube. Para obtener más información, consulte las secciones [Opciones de recuperación ante desastres en la nube](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) y [Objetivos de recuperación (RTO y RPO)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html#recovery-objectives-rto-and-rpo) en el documento técnico sobre *recuperación ante desastres de cargas de trabajo en AWS: recuperación en la* nube.
### Defina el estado objetivo del proceso
Para definir el estado objetivo de la aplicación, le recomendamos que utilice la plantilla proporcionada, la *hoja de trabajo sobre el estado objetivo de la aplicación* (formato Excel), que está disponible en las [plantillas del manual de estrategias del portafolio](samples/portfolio-playbook-templates.zip). La plantilla incluye atributos estándar que puede utilizar o modificar. Defina el proceso para documentar el estado objetivo de la aplicación de la siguiente manera:
1. Abra la *hoja de trabajo sobre el estado objetivo de la aplicación*.
1. Revise los atributos predeterminados y realice los cambios necesarios para su caso de uso.
1. Guarde la hoja de trabajo.
1. Abra el manual de priorización de aplicaciones.
1. En la sección *Estado de la aplicación objetivo*, haga lo siguiente:
1. En la sección *Cuándo completar este proceso*, establezca los criterios que permitan al equipo de la cartera determinar si necesita definir el estado objetivo de la aplicación.
1. Actualice la sección de atributos según sea necesario.
1. Actualice la sección de procesos según sea necesario para su caso de uso.
1. Guarde el manual de priorización de aplicaciones.
#### Muestras del estado objetivo de la aplicación
La siguiente tabla muestra un ejemplo de cómo se utiliza la hoja de trabajo sobre el *estado de destino de la aplicación* para documentar el estado de destino de la aplicación.
****
| Aplicación | Ejemplo |
| --- | --- |
| **Plataforma de destino** | Nube de AWS |
| **Zona de aterrizaje** | Requiere acceso a un servicio de directorio local
Requiere AWS Control Tower centralizar la administración de varias cuentas y servicios en toda la organización |
| **Dependencias** | Active Directory, pasarela de pago, sistema de inventario |
| **Aplicaciones dependientes** | Ninguno |
| **Seguridad** | Cifrado en reposo y en tránsito |
| **Conformidad** | PCI, SOC |
| **Dependencias de almacenamiento** | Unidad de arranque conectada, NAS, red compartida |
| **Base de datos** | Actual: Oracle DB
Nube: Amazon RDS para Oracle |
| **Componente de aplicación** | .NET Framework 4.5 |
| **Niveles de aplicación** | Nivel N
Interfaz, servicios empresariales, servicios y agentes de datos, base de datos |
| **Recuperación de desastres** | RPO: 1 minuto, RTO: 5 minutos
La estrategia de DR actual es el modo de espera en caliente
DR en cualquier región de EE. UU. |
### Criterios de salida escalonado
+ En la *hoja de trabajo sobre el estado de destino de la aplicación*, ha definido los atributos que desea incluir en el proceso del estado de destino.
+ En el manual de priorización de aplicaciones, ha hecho lo siguiente:
+ Ha establecido los criterios para determinar cuándo se espera que el equipo de cartera defina el estado objetivo de la aplicación.
+ Ha actualizado el proceso de definición del estado objetivo en función de su caso de uso.
## Paso 4: Finalice el proceso de análisis profundo de la aplicación
Ahora, debe definir cómo el flujo de trabajo del portafolio utiliza el taller, las reglas y los procesos que estableció en esta tarea para analizar en profundidad la aplicación. Este es el proceso al que hace referencia el flujo de trabajo del portafolio en la etapa de implementación de la migración.
Personalice este proceso en el manual de priorización de aplicaciones de la siguiente manera:
1. Abra el manual de priorización de aplicaciones.
1. En la sección *Etapa 2: análisis exhaustivo de la aplicación*, modifique el proceso según corresponda a su caso de uso y entorno.
1. Guarde el manual de priorización de aplicaciones.
1. Comparta su manual de priorización de aplicaciones con el equipo para que lo revise.