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.

# Aceleración del descubrimiento y planificación inicial
<a name="portfolio-discovery-initial-planning"></a>

Esta primera etapa de la evaluación de la cartera se centra en los pasos iniciales para obtener y analizar los datos a nivel de la cartera. El objetivo principal es identificar los impulsores del negocio y recopilar datos generales de las aplicaciones y la infraestructura para obtener una visión inicial de la cartera. Estos datos incluyen atributos técnicos y empresariales de alto nivel, como los nombres de las aplicaciones, el entorno, las versiones de los productos, la criticidad y los valores de rendimiento, entre otros, tal como se describe en la sección de [requisitos de datos](understanding-initial-assessment-data-requirements.md). Completar esta etapa es clave para comprender el alcance del proyecto, identificar a los candidatos iniciales para la migración y fundamentar el modelo de negocio.

## Resultados principales de esta etapa
<a name="discovery-outcomes"></a>
+ Los impulsores empresariales, los resultados, los objetivos y los principios rectores técnicos documentados.
+ Un inventario inicial de las aplicaciones y la infraestructura, y una identificación de las brechas de datos. Esta es una vista inicial de la cartera que se iterará y perfeccionará en etapas posteriores.
+ Un modelo de negocio orientativo y el coste estimado de la migración.
+ Una lista de los candidatos iniciales para la migración (por ejemplo, de tres a cinco solicitudes).
+ Se definieron los siguientes pasos.

# Comprensión de los requisitos de datos de la evaluación inicial
<a name="understanding-initial-assessment-data-requirements"></a>

La recopilación de datos puede llevar un tiempo considerable y convertirse fácilmente en un obstáculo cuando no hay claridad sobre qué datos se necesitan y cuándo se necesitan. La clave es entender el equilibrio entre los datos que son muy pocos y los que son demasiados para los resultados de esta etapa. Para centrarse en los datos y el nivel de fidelidad necesarios para esta fase inicial de la evaluación de la cartera, adopte un enfoque iterativo para la recopilación de datos.

## Fuentes de datos y requisitos de datos
<a name="data-sources-data-requirements"></a>

El primer paso es identificar las fuentes de datos. Comience por identificar a las partes interesadas clave de su organización que pueden cumplir con los requisitos de datos. Por lo general, son miembros de los equipos de administración de servicios, operaciones, planificación de la capacidad, supervisión y soporte, y los propietarios de las aplicaciones. Establezca sesiones de trabajo con los miembros de estos grupos. Comunique los requisitos de datos y obtenga una lista de las herramientas y la documentación existente que puedan proporcionar los datos.

Para guiar estas conversaciones, utilice el siguiente conjunto de preguntas:
+ ¿Cuán preciso y actualizado es el inventario actual de infraestructuras y aplicaciones? Por ejemplo, en el caso de la base de datos de gestión de la configuración (CMDB) de la empresa, ¿sabemos ya cuáles son las carencias?
+ ¿Disponemos de herramientas y procesos activos que mantengan actualizada la CMDB (o su equivalente)? Si es así, ¿con qué frecuencia se actualiza? ¿Cuál es la última fecha de actualización?
+ ¿El inventario actual, como la CMDB, contiene application-to-infrastructure mapas? ¿Cada activo de infraestructura está asociado a una aplicación? ¿Cada aplicación está mapeada a la infraestructura?
+ ¿El inventario contiene un catálogo de licencias y acuerdos de licencia para cada producto?
+ ¿El inventario contiene datos de dependencia? Tenga en cuenta la existencia de datos de comunicación, como de servidor a servidor, de aplicación a aplicación, de aplicación o de servidor a base de datos.
+ ¿Qué otras herramientas que pueden proporcionar información sobre aplicaciones e infraestructuras están disponibles en el entorno? Tenga en cuenta la existencia de herramientas de rendimiento, supervisión y administración que se pueden utilizar como fuente de datos.
+ ¿Cuáles son las diferentes ubicaciones, como los centros de datos, donde se alojan nuestras aplicaciones e infraestructura?

Una vez respondidas estas preguntas, enumere las fuentes de datos identificadas. Luego, asigne un nivel de fidelidad, o nivel de confianza, a cada una de ellas. Los datos validados recientemente (en un plazo de 30 días) a partir de fuentes programáticas activas, como las herramientas, tienen el mayor nivel de fidelidad. Los datos estáticos se consideran de menor fidelidad y menos fiables. Algunos ejemplos de datos estáticos son los documentos, los libros de trabajo, los conjuntos de datos actualizados CMDBs manualmente o cualquier otro conjunto de datos que no se mantenga mediante programación o cuya fecha de última actualización sea anterior a 60 días. 

Los niveles de fidelidad de los datos de la siguiente tabla se proporcionan a modo de ejemplo. Le recomendamos que evalúe los requisitos de su organización en términos de tolerancia máxima a las suposiciones y al riesgo asociado para determinar cuál es el nivel de fidelidad adecuado. En la tabla, el conocimiento institucional se refiere a cualquier información sobre las aplicaciones y la infraestructura que no esté documentada.


| **Origen de datos** | **Nivel de fidelidad** | **Cobertura de cartera** | **Comentarios** | 
| --- |--- |--- |--- |
| Conocimiento institucional | Bajo: hasta un 25% de los datos precisos, el 75% de los valores asumidos o los datos tienen más de 150 días de antigüedad. | Bajo | Escaso, centrado en aplicaciones críticas | 
| Base de conocimientos | Medio-bajo: entre el 35 y el 40% de los datos precisos, entre el 65 y el 60% de los valores o datos supuestos tienen entre 120 y 150 días de antigüedad. | Medio | Niveles de detalle inconsistentes y mantenidos manualmente | 
| CMDB | Medio: aproximadamente el 50% de los datos precisos, aproximadamente el 50% de los valores supuestos o los datos tienen entre 90 y 120 días de antigüedad. | Medio | Contiene datos de fuentes mixtas, con varios vacíos de datos | 
| VMware Exportaciones de vCenter | Medio-alto: entre el 75 y el 80% de los datos precisos, entre el 25 y el 20% de los valores asumidos o los datos tienen entre 60 y 90 días de antigüedad. | Alto | Cubre el 90% del espacio virtualizado | 
| Supervisión del rendimiento de las aplicaciones | Alto: datos en su mayoría precisos, aproximadamente un 5% de valores supuestos o datos de entre 0 y 60 días de antigüedad. | Bajo | Limitado a los sistemas de producción críticos (cubre el 15% de la cartera de aplicaciones) | 

En las siguientes tablas se especifican los atributos de datos obligatorios y opcionales para cada clase de activos (aplicaciones, infraestructura, redes y migración), la actividad específica (inventario o modelo de negocio) y la fidelidad de los datos recomendada para esta fase de evaluación. En las tablas se utilizan las siguientes abreviaturas:
+ R, si es necesario
+ (D), para un modelo de negocio direccional, obligatorio para las comparaciones del coste total de propiedad (TCO) y los modelos de negocio direccionales
+ (F), si se trata de un modelo de negocio totalmente orientado, es necesario para comparar el TCO con los modelos de negocio direccionales que incluyan los costes de migración y modernización
+ O, de forma opcional
+ N/A, si no se aplica

**Aplicaciones**


| **Nombre de atributo** | **Descripción** | **Inventario y priorización** | **Argumentos comerciales** | **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 (D) | 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 (D) | Medio-alto | 
| ¿Es COTS? | Sí o no. Si se trata de una aplicación comercial o de un desarrollo interno | R | R (D) | Medio-alto | 
| Producto y versión de COTS | Nombre y versión del producto de software comercial  | R | R (D) | Medio | 
| Description (Descripción) | Función y contexto de la aplicación principal | R | O | Medio | 
| Criticidad | Por ejemplo, una aplicación estratégica o generadora de ingresos, o que respalde una función crítica | R | O | Medio-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 | O | Medio | 
| Entorno | Por ejemplo, producción, preproducción, desarrollo, pruebas o entorno aislado | R | R (D) | Medio-alto | 
| Cumplimiento y regulación | Marcos aplicables a la carga de trabajo (por ejemplo, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) y a los requisitos reglamentarios | R | R (D) | Medio-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) | O | O | Medio-bajo | 
| Mapeo de infraestructuras | Mapeo de los activos and/or virtuales físicos que componen la aplicación | O | O | Medio | 
| Licencia | Tipo de licencia de software básico (p. ej., Microsoft SQL Server Enterprise) | O | R | Medio-alto | 
| Costo | Costos de la licencia de software, las operaciones del software y el mantenimiento | N/A | O | Medio | 

**Infraestructura**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **Nombre del 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 | O | Medio-alto | 
| Nombre DNS (nombre de dominio completo o FQDN) | Nombre de DNS | O | O | Medio | 
| Dirección IP y máscara de red | Direcciones IP and/or públicas internas | R | O | Medio-alto | 
| Tipo de activo | Servidor físico o virtual, hipervisor, contenedor, dispositivo, instancia de base de datos, etc. | R | R | Medio-alto | 
| Product name (Nombre del producto) | Proveedor comercial y nombre del producto (por ejemplo VMware ESXi, IBM Power Systems, Exadata) | R | R | Medio | 
| Sistema operativo | Por ejemplo, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Medio-alto | 
| Configuración | CPU asignada, número de núcleos, subprocesos por núcleo, memoria total, almacenamiento, tarjetas de red | R | R | Medio-alto | 
| Uso | Cantidad máxima y media de CPU, memoria y almacenamiento. Rendimiento de las instancias de base de datos. | R | O | Medio-alto | 
| Licencia | Tipo de licencia de producto básico (por ejemplo, RHEL Standard) | R | R | Medio | 
| ¿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 (D) | Medio | 
| Mapeo de aplicaciones | Aplicaciones o componentes de aplicaciones que se ejecutan en esta infraestructura | O | O | Medio | 
| Costo | Todos los costos de los servidores básicos incluyen el hardware, el mantenimiento, las operaciones, el almacenamiento (SAN, NAS, Object), la licencia del sistema operativo, la participación en Rackspace y los gastos generales del centro de datos | N/A | O | Medio-alto | 

**Redes**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **Nombre del 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) | O | R | Medio | 
| Utilización del enlace | Utilización máxima y media, transferencia de datos salientes (GB/mes) | O | R | Medio | 
| Latencia (ms) | Latencia actual entre las ubicaciones conectadas. | O | O | Medio | 
| Costo | Coste actual por mes | N/A | O | Medio | 

**Migración**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **Nombre del atributo** | **Descripción** | **Inventario y priorización** | **Argumentos comerciales** | **Nivel de fidelidad recomendado (mínimo)** | 
| Volver a alojar | Esfuerzo de los clientes y socios por cada carga de trabajo (días-persona), tarifas de costo por día de clientes y socios, costo de las herramientas y cantidad de cargas de trabajo | N/A | R (F) | Medio-alto | 
| Redefinir la plataforma | Esfuerzo de los clientes y socios por cada carga de trabajo (días-persona), tarifas de costos por día de clientes y socios y cantidad de cargas de trabajo | N/A | R (F) | Medio-alto | 
| Refactorizar | Esfuerzo de los clientes y socios por cada carga de trabajo (días-persona), tasas de costo por día de clientes y socios y cantidad de cargas de trabajo | N/A | O | Medio-alto | 
| Retirar | Número de servidores, coste medio de desmantelamiento | N/A | O | Medio-alto | 
| Zona de aterrizaje | Reutilizar los existentes (S/N), lista de AWS regiones necesarias, coste | N/A | R (F) | Medio-alto | 
| La gente y el cambio | Número de personal que se capacitará en operaciones y desarrollo de la nube, costo de la capacitación por persona, costo del tiempo de capacitación por persona | N/A | R (F) | Medio-alto | 
| Duración | Duración de la migración de la carga de trabajo incluida (meses) | O | R (F) | Medio-alto | 
| Coste paralelo | Plazo y ritmo a los que se pueden eliminar los costos «tal cual» durante la migración | N/A | O | Medio-alto | 
| Plazo y ritmo a AWS los que se introducen los productos y servicios, así como otros costes de infraestructura, durante la migración | N/A | O | Medio-alto | 

## Evaluar la necesidad de herramientas de descubrimiento
<a name="discovery-tooling"></a>

¿Su organización necesita herramientas de descubrimiento? La evaluación de la cartera requiere up-to-date datos fiables sobre las aplicaciones y la infraestructura. En las etapas iniciales de la evaluación de la cartera se pueden utilizar suposiciones para subsanar las lagunas en los datos. 

Sin embargo, a medida que se avanza, los datos de alta fidelidad permiten crear planes de migración satisfactorios y estimar correctamente la infraestructura de destino para reducir los costos y maximizar los beneficios. También reduce el riesgo al permitir implementaciones que tengan en cuenta las dependencias y evitar los problemas de migración. El uso principal de las herramientas de descubrimiento en los programas de migración a la nube es reducir el riesgo y aumentar los niveles de confianza en los datos mediante lo siguiente:
+ Recopilación de datos automatizada o programática, lo que da como resultado datos validados y de gran confianza
+ Aceleración de la velocidad a la que se obtienen los datos, lo que mejora la velocidad del proyecto y reduce los costos
+ Mayores niveles de integridad de los datos, incluidos los datos de comunicación y las dependencias que no suelen estar disponibles en CMDBs
+ Obtener información como la identificación automática de aplicaciones, el análisis del TCO, las tasas de ejecución proyectadas y las recomendaciones de optimización
+ Planificación fiable de las oleadas de migración

Cuando no se sabe con certeza si los sistemas existen en una ubicación determinada, la mayoría de las herramientas de detección pueden analizar las subredes de la red y detectar los sistemas que responden a los ping o a las solicitudes del Protocolo simple de administración de redes (SNMP). Tenga en cuenta que no todas las configuraciones de red o sistemas permitirán el tráfico de ping o SNMP. Analice estas opciones con sus equipos técnicos y de red.

Las etapas posteriores de la evaluación y migración de la cartera de aplicaciones dependen en gran medida de una información precisa sobre el mapeo de dependencias. El mapeo de dependencias permite comprender la infraestructura y la configuración que se necesitarán AWS (por ejemplo, los grupos de seguridad, los tipos de instancias, la ubicación de las cuentas y el enrutamiento de la red). También ayuda a agrupar las aplicaciones que deben moverse al mismo tiempo (por ejemplo, las aplicaciones que deben comunicarse a través de redes de baja latencia). Además, el mapeo de dependencias proporciona información para hacer evolucionar el modelo de negocio.

A la hora de decidirse por una herramienta de descubrimiento, es importante tener en cuenta todas las etapas del proceso de evaluación y anticipar las necesidades de datos. Las brechas de datos tienen el potencial de convertirse en obstáculos, por lo que es clave anticiparlas analizando los requisitos de datos y las fuentes de datos en el futuro. La experiencia sobre el terreno indica que la mayoría de los proyectos de migración estancados tienen un conjunto de datos limitado en el que no se identifican claramente las aplicaciones incluidas en el ámbito de aplicación, la infraestructura asociada y sus dependencias. Esta falta de identificación puede provocar métricas, decisiones y retrasos incorrectos. La obtención up-to-date de datos es el primer paso para que los proyectos de migración tengan éxito.

*¿Cómo seleccionar una herramienta de descubrimiento?*

Varias herramientas de descubrimiento del mercado ofrecen diferentes funciones y capacidades. Tenga en cuenta sus requisitos. Y decida cuál es la opción más adecuada para su organización. Los factores más comunes a la hora de decidirse por una herramienta de detección para las migraciones son los siguientes:

*Seguridad*
+ ¿Cuál es el método de autenticación para acceder al repositorio de datos de la herramienta o a los motores de análisis? 
+ ¿Quién puede acceder a los datos y cuáles son los controles de seguridad para acceder a la herramienta? 
+ ¿Cómo recopila la herramienta los datos? ¿Necesita credenciales dedicadas? 
+ ¿Qué credenciales y nivel de acceso necesita la herramienta para acceder a mis sistemas y obtener datos? 
+ ¿Cómo se transfieren los datos entre los componentes de la herramienta? 
+ ¿La herramienta admite el cifrado de datos en reposo y en tránsito? 
+ ¿Los datos están centralizados en un solo componente dentro o fuera de mi entorno? 
+ ¿Cuáles son los requisitos de red y firewall? 

Asegúrese de que los equipos de seguridad participen en las primeras conversaciones sobre las herramientas de descubrimiento.

*Soberanía de datos*
+ ¿Dónde se almacenan y procesan los datos? 
+ ¿Utiliza la herramienta un modelo de software como servicio (SaaS)? 
+ ¿Tiene la posibilidad de conservar todos los datos dentro de los límites de mi entorno? 
+ ¿Se pueden analizar los datos antes de que salgan de los límites de mi organización? 

Tenga en cuenta las necesidades de su organización en cuanto a los requisitos de residencia de los datos.

*Arquitectura*
+ ¿Qué infraestructura se requiere y cuáles son los diferentes componentes?
+ ¿Hay más de una arquitectura disponible? 
+ ¿La herramienta admite la instalación de componentes en zonas de seguridad cerradas?

*Rendimiento*
+ ¿Cuál es el impacto de la recopilación de datos en mis sistemas? 

*Compatibilidad y alcance*
+ ¿La herramienta es compatible con todos o la mayoría de mis productos y versiones? Revisa la documentación de la herramienta para verificar las plataformas compatibles con la información actual sobre tu alcance. 
+ ¿La mayoría de mis sistemas operativos son compatibles con la recopilación de datos? Si no conoce las versiones de su sistema operativo, intente limitar la lista de herramientas de detección a aquellas que cuenten con una gama más amplia de sistemas compatibles.

*Métodos de recopilación*
+ ¿La herramienta requiere instalar un agente en cada sistema de destino?
+ ¿Soporta despliegues sin agente? 
+ ¿Ofrecen las mismas funciones con agente y sin agente? 
+ ¿Cuál es el proceso de cobro?

*Características*
+ ¿Cuáles son las funciones disponibles? 
+ ¿Puede calcular el coste total de propiedad (TCO) y la tasa de Nube de AWS ejecución estimada? 
+ ¿Soporta la planificación de la migración? 
+ ¿Mide el rendimiento? 
+ ¿Puede recomendar la AWS infraestructura de destino? 
+ ¿Realiza un mapeo de dependencias? 
+ ¿Qué nivel de mapeo de dependencias proporciona? 
+ ¿Proporciona acceso a la API? (por ejemplo, ¿se puede acceder a ella mediante programación para obtener datos?)

Considere las herramientas con funciones sólidas de mapeo de dependencias de aplicaciones e infraestructuras y aquellas que puedan deducir las aplicaciones a partir de los patrones de comunicación. 

*Costo*
+ ¿Qué es el modelo de licencias? 
+ ¿Cuánto cuesta la licencia? 
+ ¿El precio de cada servidor es válido? ¿Se trata de precios escalonados? 
+ ¿Existen opciones con funciones limitadas que se puedan licenciar bajo demanda? 

Las herramientas de descubrimiento se suelen utilizar durante todo el ciclo de vida de los proyectos de migración. Si su presupuesto es limitado, considere la posibilidad de tener al menos 6 meses. Sin embargo, la ausencia de herramientas de descubrimiento suele conllevar un aumento del esfuerzo manual y de los costes internos.

*Modelo Support*
+ ¿Qué niveles de soporte se proporcionan de forma predeterminada? 
+ ¿Hay algún plan de soporte disponible? 
+ ¿Cuáles son los tiempos de respuesta a los incidentes?

*Servicios profesionales*
+ ¿Ofrece el proveedor servicios profesionales para analizar los resultados del descubrimiento? 
+ ¿Pueden cubrir los elementos de esta guía? 
+ ¿Hay descuentos o paquetes de herramientas y servicios?

**sugerencia**  
Para buscar y evaluar las herramientas de descubrimiento, utilice el sitio de [descubrimiento, planificación y recomendación](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/).

*Funciones recomendadas para la herramienta de descubrimiento*

Para evitar aprovisionar y combinar datos de varias herramientas a lo largo del tiempo, una herramienta de descubrimiento debe incluir las siguientes características mínimas: 
+ **Software**: la herramienta de descubrimiento debe poder identificar los procesos en ejecución y el software instalado.
+ **Mapeo de dependencias**: debe poder recopilar información de conexión de red y crear mapas de dependencias entrantes y salientes de los servidores y las aplicaciones en ejecución. Además, la herramienta de detección debería poder inferir aplicaciones de grupos de infraestructuras en función de los patrones de comunicación.
+ **Detección de perfiles y configuraciones**: debería poder informar del perfil de la infraestructura, como la familia de CPU (por ejemplo, x86 o PowerPC), la cantidad de núcleos de CPU, el tamaño de la memoria, la cantidad de discos y el tamaño y las interfaces de red.
+ **Detección del almacenamiento en red**: debe poder detectar y perfilar los recursos compartidos de la red desde el almacenamiento conectado a la red (NAS).
+ **Rendimiento**: debería poder informar sobre el uso máximo y promedio de la CPU, la memoria, el disco y la red.
+ **Análisis de brechas**: debe poder proporcionar información sobre la cantidad y la fidelidad de los datos.
+ **Escaneo de red**: debe poder escanear subredes de red y descubrir activos de infraestructura desconocidos.
+ **Informes**: debe poder proporcionar el estado de la recopilación y el análisis.
+ **Acceso a la API**: debe poder proporcionar medios programáticos para acceder a los datos recopilados.

*Características adicionales a tener en cuenta*
+ **Análisis del TCO** para proporcionar una comparación de costos entre el costo local actual y el costo proyectado AWS .
+ **Recomendaciones de análisis y optimización de licencias** para los sistemas Microsoft SQL Server y Oracle en escenarios de rehospedaje y replataforma.
+ **Recomendación de estrategia de migración** (¿Puede la herramienta de descubrimiento hacer recomendaciones de tipo R de migración predeterminadas en función de la tecnología actual?)
+ **Exportación de inventario** (a CSV o un formato similar)
+ **Recomendación sobre el tamaño correcto** (por ejemplo, ¿puede mapear una AWS infraestructura de destino recomendada?)
+ **Visualización de dependencias** (por ejemplo, ¿se puede visualizar el mapeo de dependencias en modo gráfico?)
+ **Vista arquitectónica** (por ejemplo, ¿se pueden producir diagramas arquitectónicos automáticamente?)
+ **Priorización de las aplicaciones** (¿puede asignar peso o relevancia a los atributos de la aplicación y la infraestructura para crear criterios de priorización para la migración?)
+ **Planificación de oleadas** (por ejemplo, grupos de aplicaciones recomendados y posibilidad de crear planes de oleadas de migración)
+ **Estimación del costo de migración** (estimación del esfuerzo de migración)

*Consideraciones sobre la implementación*

Una vez que haya seleccionado y adquirido una herramienta de descubrimiento, tenga en cuenta las siguientes preguntas para impulsar las conversaciones con los equipos responsables de implementar la herramienta en su organización:
+ ¿Los servidores o las aplicaciones son gestionados por un tercero? Esto podría determinar los equipos que deben participar y los procesos a seguir.
+ ¿Cuál es el proceso de alto nivel para obtener la aprobación para implementar herramientas de descubrimiento?
+ ¿Cuál es el principal proceso de autenticación para acceder a sistemas como servidores, contenedores, almacenamiento y bases de datos? ¿Las credenciales del servidor son locales o centralizadas? ¿Cuál es el proceso para obtener las credenciales? Se necesitarán credenciales para recopilar datos de sus sistemas (por ejemplo, contenedores, servidores virtuales o físicos, hipervisores y bases de datos). Obtener las credenciales de la herramienta de descubrimiento para conectarse a cada activo puede resultar difícil, especialmente cuando estos activos no están centralizados.
+ ¿Cuál es el esquema de las zonas de seguridad de la red? ¿Están disponibles los diagramas de red?
+ ¿Cuál es el proceso para solicitar las reglas de firewall en los centros de datos?
+ ¿Cuáles son los acuerdos de nivel de servicio de soporte actuales (SLAs) en relación con las operaciones del centro de datos (instalación de herramientas de detección, solicitudes de firewall)?

# Impulsores empresariales y principios rectores técnicos
<a name="business-drivers-technical-guiding-principles"></a>

## Impulsores empresariales
<a name="business-drivers"></a>

Tanto si su organización ya ha decidido migrar a la nube como si está a punto de tomar esa decisión, definir y documentar los factores empresariales que impulsan la migración a la nube aclarará los motivos de la migración. Una vez documentados los motivos, puede definir qué se va a migrar y cómo se va a migrar. Esta actividad es importante. Recomendamos que se lleve a cabo lo antes posible en el proceso para informar y guiar los próximos pasos. 

Identifique a las partes interesadas que deberían formar parte de la discusión para documentar los factores que la impulsan. Por lo general CxOs, los altos directivos y los principales líderes tecnológicos de la organización y sus propios clientes. Si bien es poco probable que sus clientes participen en este debate, le recomendamos que designe a una o más personas de su organización para que representen sus puntos de vista y objetivos.

Los impulsores empresariales deben estar vinculados a una métrica que se pueda medir a lo largo del proceso de migración para validar si se han logrado los resultados. Los objetivos estratégicos y los informes anuales de la empresa pueden servir de punto de partida. 

Centra la conversación en dónde quiere estar la empresa, en función de las métricas existentes y proyectadas, como resultado de la migración a la nube. Tenga en cuenta los objetivos y los resultados empresariales. Además, considere cómo será el éxito a medida que aumente la adopción de la nube. 

A continuación, establezca el nivel de importancia de cada factor. ¿Cuáles son las prioridades? ¿Cuáles son los beneficios esperados? ¿Cómo respaldan los beneficios los objetivos y resultados empresariales? En el contexto de la evaluación de la cartera de aplicaciones, las respuestas ayudarán a priorizar las cargas de trabajo para la migración y a establecer principios rectores técnicos. Sin embargo, los factores empresariales definirán el programa de migración en su conjunto e influirán en él.

## Principios rectores técnicos
<a name="technical-guiding-principles"></a>

Los principios rectores técnicos sirven de base para la selección de la estrategia de migración en las etapas posteriores de la evaluación de la cartera. En la etapa actual, el objetivo es identificarlos. 

Los principios rectores se pueden establecer como decisiones generales relacionadas con la tecnología y el enfoque derivadas de los objetivos y resultados empresariales.

Por ejemplo, una empresa tiene el objetivo principal de reducir los costos y el resultado deseado es cerrar un centro de datos local en una fecha determinada, en un plazo de 6 a 12 meses. Un principio rector resultante es trasladar todas las aplicaciones a la nube mediante una estrategia de migración de realojamiento o reubicación siempre que sea posible. En este caso, el lift-and-shift enfoque acelera los resultados de la migración a corto plazo. Una vez que las aplicaciones se hayan mudado del centro de datos local, la empresa puede centrarse en los principales factores empresariales para optimizar o modernizar las cargas de trabajo migradas.

Para establecer los principios rectores técnicos, comience por analizar los factores que impulsan el negocio. Identifique una lista de tecnologías y técnicas que permitirán alcanzar los objetivos y resultados empresariales. A continuación, perfeccione la lista y asigne un orden de relevancia en función de la idoneidad o la preferencia para lograr el resultado deseado.

Documente y comunique los principios rectores a las personas involucradas en la planificación y realización de la migración. Resalte las preocupaciones y los posibles conflictos entre los principios y la implementación real.

La siguiente tabla proporciona un ejemplo de los impulsores empresariales y los principios rectores técnicos.


| **Impulsor empresarial** | **Resultado** | **Métricas** | **Principio rector técnico** | 
| --- |--- |--- |--- |
| Acelere la innovación. | Mejora de la competitividad, aumento de la agilidad empresarial | Número de despliegues por día o mes, nuevas funciones lanzadas por trimestre, puntuaciones de satisfacción de los clientes, número de experimentos | Refactorice la diferenciación de las aplicaciones mediante el uso de microservicios y el modelo DevOps operativo para aumentar la agilidad y la velocidad de comercialización de las nuevas funciones. | 
| Reduzca los costos operativos y de infraestructura. | Adaptación de la oferta y la demanda, base de costes elástica (pague por lo que utilice) | Variación del gasto a lo largo del tiempo | 1. Realoje las aplicaciones con el tamaño adecuado de la infraestructura. 2. Retire las aplicaciones que tengan un uso bajo o nulo. | 
| Aumente la resiliencia operativa. | Mejora del tiempo de actividad y reducción del tiempo medio de recuperación | SLAs, número de incidentes | 1. Cambie la plataforma de las aplicaciones a las versiones de sistema operativo más recientes y mejor compatibles. 2. Implemente arquitecturas de alta disponibilidad para aplicaciones críticas. | 
| Salga del centro de datos. | Cierre del centro de datos en un plazo de 6 a 12 meses | Velocidad de las migraciones de servidores | Realoje las aplicaciones mediante la solución Cloud Migration Factory. | 
| Permanezca en las instalaciones, pero aumente la agilidad y la resiliencia. | Mejora de la competitividad y el tiempo de actividad sin dejar de trabajar en las instalaciones | Número de despliegues por día o mes, lanzamiento de nuevas funciones por trimestre SLAs, número de incidentes | 1. Modernice los sistemas extendiendo su funcionalidad a la nube.2. Evalúe la posibilidad de realojarlos o cambiarlos de plataforma a. AWS Outposts | 

# Iniciar la recopilación de datos
<a name="initiating-data-collection"></a>

La recopilación de datos es el proceso de recopilación de metadatos de las aplicaciones y la infraestructura. El proceso es iterativo en todas las etapas de la evaluación. En cada etapa, la cantidad y la fidelidad de los datos aumentarán. En esta etapa, la atención se centra en recopilar datos generales que puedan ayudar a establecer un inventario inicial. El inventario se utilizará para crear un modelo de negocio orientativo y para identificar a los candidatos iniciales a la migración.

Una vez identificadas las fuentes de datos actuales, recomendamos recopilar información de tantos sistemas como sea posible. Para obtener más información, consulte los [requisitos de datos](understanding-initial-assessment-data-requirements.md) para esta etapa.

Este enfoque tiene la ventaja de ayudar a actualizar la visión actual de la cartera y el conocimiento de la organización sobre sus aplicaciones y servicios. También ayuda a determinar qué es lo que se pretende trasladar. El enfoque recomendado consiste en revisar los datos existentes, como los resultados de las bases de datos de administración de la configuración (CMDB) y los sistemas de administración de servicios de tecnología de la información (ITSM). A continuación, elabore una lista de los activos destinados a la recopilación de datos. Si su organización tiene total claridad sobre lo que está dentro y fuera del alcance de la migración, puede restringir la recopilación de datos a los sistemas incluidos en el ámbito de aplicación.

Al crear su cartera, tenga en cuenta las aplicaciones y sus entornos o los ciclos de vida de las versiones de software. Por ejemplo, en lugar de identificar una aplicación de gestión de relaciones con los clientes (CRM) y especificar que tiene entornos de prueba, desarrollo y producción, enumere tres aplicaciones (por ejemplo, CRM-Test, CRM-Dev, CRM-Prod). Como alternativa, utilice el nombre del CRM pero asigne un identificador único a cada entorno y preséntelos como registros independientes en su repositorio de datos. Esto ayudará a planificar y realizar un seguimiento de la migración de estos entornos de forma individual. Por ejemplo, es posible que desee migrar primero los entornos que no son de producción. Al enumerar las instancias de su aplicación según el entorno, puede gestionar y controlar su transición con claridad.

Durante la recopilación de datos, es posible que no se sepa con certeza qué aplicaciones o servidores se encuentran en un centro de datos o ubicación de origen determinados. En estos casos, resulta útil obtener listas completas y de hipervisores a partir de las herramientas de administración existentes. Por ejemplo, puede conectarse a un hipervisor para obtener listas de máquinas virtuales a las que se destinará la recopilación de datos. 

Tenga en cuenta que el resultado inicial, al combinar las fuentes de datos existentes, podría estar incompleto. La clave es realizar un análisis de las carencias en términos de [los requisitos de datos](understanding-initial-assessment-data-requirements.md) para esta etapa y de lo que se puede obtener de las fuentes existentes. Es importante contrastar el porcentaje de integridad con el nivel de fidelidad de los datos. Los niveles de integridad más altos procedentes de fuentes de baja fidelidad contendrán varias suposiciones que podrían llevar a un análisis erróneo. Si bien esta etapa de la evaluación no requiere la máxima fidelidad de los datos, recomendamos que las fuentes de datos tengan una fidelidad mínima de media a media-alta. Compare estas cifras con la tolerancia de su organización al riesgo, incluido el uso de suposiciones para cubrir las lagunas en los datos. 

El análisis de brechas le ayuda a comprender la cantidad y la calidad de los datos con los que trabaja. El análisis también le ayuda a establecer el nivel de suposiciones que se deben hacer para crear un modelo de negocio orientado y priorizar las aplicaciones para la migración. Las herramientas de descubrimiento pueden ayudar a colmar las lagunas y a recopilar datos de alta fidelidad. Para aumentar los niveles de confianza en los datos y acelerar los resultados de la migración, recomendamos implementar las herramientas de descubrimiento lo antes posible. También es importante actuar cuanto antes, ya que los procesos internos de adquisición, seguridad e implementación de nuevas herramientas pueden tardar varias semanas o meses en completarse.

Recomendamos establecer un plan o cadencia de comunicación y un mecanismo de control del cambio de alcance en esta etapa. Esto le ayuda a mantener informadas a las partes interesadas para que puedan planificar con antelación y mitigar los riesgos. Un elemento clave para una comunicación clara es definir una única fuente de información fiable para la cartera de aplicaciones y la infraestructura asociada. Evite mantener varios sistemas de registro y listas de aplicaciones e infraestructuras. Guarde los datos en un lugar (por ejemplo, una base de datos, una herramienta o una hoja de cálculo) que permita el control de versiones y la colaboración en línea, y asígneles un propietario.

# Estrategia de priorización y migración
<a name="prioritization-and-migration-strategy"></a>

Un elemento clave de la planificación de la migración es establecer los criterios de priorización. El objetivo de este ejercicio es comprender el orden en que se migrarán las aplicaciones. La estrategia consiste en adoptar un enfoque iterativo y progresivo para desarrollar el modelo de priorización.

## Priorizar las aplicaciones
<a name="prioritizing-applications"></a>

Esta fase de evaluación se centra en establecer los criterios iniciales para priorizar las cargas de trabajo de bajo riesgo y baja complejidad. Estas cargas de trabajo son buenas candidatas para las aplicaciones piloto. El uso de cargas de trabajo de bajo riesgo y baja complejidad en las migraciones iniciales reduce el riesgo y brinda a los equipos la oportunidad de adquirir experiencia. Estos criterios se irán modificando en las siguientes etapas de evaluación para alinear la priorización con los factores empresariales a la hora de crear el plan para la oleada de migración.

Los criterios iniciales deberían priorizar las aplicaciones con un número reducido de dependencias, que se ejecuten en una infraestructura compatible con la nube y que provengan de entornos no productivos. Un ejemplo serían las aplicaciones con entre 0 y 3 dependencias listas para rehospedarse tal cual en un entorno de desarrollo o prueba. Estos criterios son válidos para definir las aplicaciones piloto y, posiblemente, la primera y la segunda oleada de migración, según el nivel de madurez de la adopción de la nube y los niveles de confianza. 

*Decidir qué criterios iniciales utilizar*

Seleccione de 2 a 10 puntos de datos para utilizarlos para priorizar sus primeras cargas de trabajo. Estos puntos de datos provienen del inventario inicial de aplicaciones e infraestructuras (consulte la sección de recopilación de [datos](initiating-data-collection.md)). 

A continuación, defina una puntuación, o ponderación, para cada valor posible de cada punto de datos. Por ejemplo, si se selecciona el atributo de entorno y los valores posibles son producción, desarrollo y prueba, a cada valor se le asigna una puntuación, y un número mayor representa una mayor prioridad. Aunque es opcional, recomendamos asignar un factor multiplicador por importancia o relevancia a cada punto de datos. Este paso opcional proporciona un diferenciador de nivel superior para enfatizar lo que es más importante, lo que ayuda a mantener los criterios alineados a medida que se van asignando puntuaciones a los valores.

Basándose en la estrategia de priorizar las aplicaciones sencillas y de bajo riesgo para las primeras oleadas de migración, en la siguiente tabla se muestran ejemplos de la selección de atributos y sus asignaciones de valores.


| **Atributo (punto de datos)** | **Valores posibles** | **Puntuación (0-99)** | **Factor multiplicador de importancia o relevancia** | 
| --- |--- |--- |--- |
| Entorno | Test | 60 | Alto (1x) | 
| Desarrollo | 40 | 
| Producción | 20 | 
| Criticidad empresarial | Bajo | 60 | Alta (1x) | 
| Medio | 40 | 
| Alto | 20 | 
| Marco regulatorio o de cumplimiento | Ninguno | 60 | Alto (1x) | 
| FedRAMP | 10 | 
| Compatibilidad con sistemas operativos | Preparado para la nube | 60 | Medio-alto (0,8 veces) | 
| No se admite en la nube | 10 | 
| Número de instancias de cómputo | 1-3 | 60 | Medio-alto (0,8 veces) | 
| 4-10 | 40 | 
| 11 o más | 20 | 
| Estrategia de migración | Volver a alojar | 70 | Medio (0,6 veces) | 
| Redefinir la plataforma | 30 | 
| Refactorizar o rediseñar | 10 | 

Asegúrese de seleccionar atributos que puedan actuar como diferenciadores clave entre las aplicaciones. De lo contrario, los criterios harán que muchas cargas de trabajo compartan la misma prioridad. Tras aplicar el modelo, te recomendamos que consultes las posiciones superior e inferior de la clasificación resultante para comprobar si estás de acuerdo. Si no estás de acuerdo en general, puedes revisar los criterios que utilizaste para puntuar las cargas de trabajo. 

Tras obtener una clasificación, observa la distribución de las puntuaciones en toda la cartera. Las puntuaciones en sí mismas no importan. Lo que importa es la diferencia entre las puntuaciones. Por ejemplo, es posible que descubra que la puntuación total más alta es de 8000 y la puntuación más baja es de 800. Considere la posibilidad de trazar las puntuaciones resultantes como un histograma, de modo que pueda comprobar que tiene una buena distribución. La distribución ideal se parece a una curva de campana estándar, con unas pocas cargas de trabajo de muy alta prioridad y unas pocas cargas de trabajo de muy baja prioridad. La mayoría de las aplicaciones estarán en algún punto intermedio.

Otro aspecto clave de la priorización inicial es incluir equipos internos o unidades de negocio que muestren interés en ser los primeros en adoptar la nube. Estos podrían ser una palanca considerable a la hora de obtener apoyo empresarial para migrar una aplicación determinada, especialmente en los primeros días. Si este es el caso de su organización, incluya el atributo de unidad de negocio en la tabla anterior. Asigne una puntuación alta a las unidades de negocio que estén dispuestas a presentar sus solicitudes. El uso del atributo de unidad de negocio ayudará a que esas aplicaciones ocupen los primeros puestos de la lista.

Una vez que esté de acuerdo con la clasificación resultante, seleccione las 5 o 10 aplicaciones principales. Estas serán las candidatas iniciales para la migración de su solicitud. Refina la lista para confirmar de 3 a 5 solicitudes. Esto le ayuda a adoptar un enfoque específico a la hora de realizar una evaluación detallada de la solicitud. Para obtener más información, consulte [Evaluación de aplicaciones priorizadas](prioritized-applications-assessment.md).

 

## Determinar el tipo R para la migración
<a name="migration-r-type"></a>

La decisión sobre una estrategia de migración para cada aplicación e infraestructura asociada tendrá repercusiones en la velocidad de la migración, el costo y el nivel de beneficios. Es fundamental determinar la estrategia en función de una combinación equilibrada de factores, incluidos los impulsores empresariales, los principios rectores técnicos, los criterios de priorización y la estrategia empresarial.

A veces, estos factores crean puntos de vista contradictorios. Por ejemplo, el principal impulsor de la migración podría ser la innovación y la agilidad. Al mismo tiempo, es posible que necesite reducir los costos rápidamente. La modernización de todas las aplicaciones previstas reducirá los costos a largo plazo, pero requerirá una mayor inversión inicial. En ese caso, un enfoque consiste en migrar las aplicaciones mediante estrategias que requieran menos esfuerzo, como realojarlas o cambiarlas de plataforma. Esto puede proporcionar eficiencias rápidas y una reducción de costos a corto plazo. Luego, reinvierta los ahorros en modernizar la aplicación en una etapa posterior y logre una mayor reducción de costos. 

Sin embargo, empezar con una reubicación completa de todas las aplicaciones retrasa los mayores beneficios de la modernización. La clave es encontrar un equilibrio entre las estrategias de migración, de modo que se priorice la modernización de las aplicaciones empresariales estratégicas, mientras que otras aplicaciones se puedan realojar o cambiar de plataforma primero y, después, modernizarlas.

*¿Cómo determinar una estrategia de migración para sus aplicaciones?*

En esta etapa de la evaluación, el objetivo es incorporar un modelo inicial para guiar la selección de la estrategia de migración. Para validar la estrategia de migración de las aplicaciones iniciales, utilice el modelo junto con los factores empresariales y los criterios de priorización. La lógica predeterminada del árbol de decisiones le ayudará a determinar el tratamiento inicial del ámbito. En el árbol, los enfoques más complejos, como la refactorización o la rearquitectura, están reservados para sus cargas de trabajo estratégicas.

![\[El proceso de decisión de las 6 R se analiza en esta guía.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)


En la sección de *[adjuntos](#attachments)* hay disponible una versión personalizable de [draw.io](https://github.com/jgraph/drawio-desktop/releases) de este diagrama.

El primer paso de un modelo inicial consiste en actualizar los factores empresariales más importantes con los definidos por la organización. A continuación, aplique el árbol a los componentes de la aplicación en lugar de a las aplicaciones en su conjunto. Por ejemplo, en el caso de una aplicación de tres niveles que tiene tres componentes (interfaz, capa de aplicación y base de datos), cada componente debe transitar por el árbol de forma independiente y asignársele una estrategia y un patrón específicos. Esto se debe a que, en algunos casos, es posible que desee realojar o cambiar la plataforma de un nivel determinado y refactorizar (rediseñar) otros niveles. 

La asignación independiente de los componentes le permitirá definir una estrategia de migración para la infraestructura asociada. La estrategia de infraestructura puede ser la misma estrategia que el componente de aplicación que admite o puede ser diferente. Por ejemplo, un componente de una aplicación que se transformará en una nueva máquina virtual con un sistema operativo más nuevo seguirá la estrategia de replataforma, mientras que la máquina virtual actual que lo aloja se retirará. La estrategia de migración de la infraestructura se calcula en función de la estrategia elegida para los componentes de la aplicación.

Antes de utilizar el árbol de decisiones para establecer estrategias de migración, pruebe la lógica con algunas aplicaciones y compruebe si, en general, está de acuerdo con el resultado. El árbol de decisiones de las 6 R es una guía que no reemplaza el análisis necesario para determinar su exactitud. Es posible que la lógica del árbol no se aplique a casos particulares. Trate esos casos como excepciones y proceda a anular la decisión impulsada por el árbol documentando los motivos de la anulación en lugar de cambiar la lógica del árbol. Esto evita tener varias versiones del árbol de decisiones, lo que podría resultar difícil de gestionar. La orientación general es que el árbol debe ser válido para al menos entre el 70 y el 80 por ciento de las cargas de trabajo. Por lo demás, habrá excepciones. Cualquier ajuste a la lógica del árbol, en esta etapa de la evaluación, debe centrarse en establecer un modelo inicial. Se realizarán más iteraciones y ajustes en etapas posteriores, como el [análisis de la cartera y la planificación de la migración](portfolio-analysis-migration-planning.md).

## Archivos adjuntos
<a name="attachments"></a>

[attachment.zip](samples/attachment.zip)

# Creación de un modelo de negocio direccional
<a name="directional-business-case"></a>

Las partes interesadas de toda la empresa deben comprender y aceptar el argumento empresarial a favor de la transformación en cada paso del proceso. 

En las primeras etapas, es importante demostrar rápidamente el valor potencial de un programa de migración para poder disponer de los recursos necesarios para planificar y establecer el programa. El modelo de negocio orientativo está diseñado para ofrecer una confianza razonable a la hora de lograr un valor empresarial convincente con los datos limitados que se pueden recopilar en una fase temprana.

Una vez establecido el programa, se sigue desarrollando el modelo de negocio. El caso detallado proporciona una mayor precisión, una imagen más completa del valor del programa y una visión de las prioridades de planificación. Define y cuantifica los resultados empresariales planificados en los que se basa la organización y establece la base sobre la que la oficina de gobierno del programa podrá dirigir el programa y medir sus logros.

## Fijar el alcance del modelo de negocio direccional
<a name="fix-scope"></a>

Por lo general, un modelo de negocio direccional se elabora rápidamente, en un plazo de 2 a 4 semanas. Debe generar suficiente confianza para poder disponer de los recursos necesarios para establecer el equipo principal, contratar a los AWS socios si es necesario y, como mínimo, completar las etapas [prioritarias de evaluación de las aplicaciones](prioritized-applications-assessment.md) y [análisis de la cartera y planificación de la migración](portfolio-analysis-migration-planning.md).

Por lo general, los casos de negocio direccionales que respaldan las migraciones de carteras se crean de alguna de las siguientes maneras:
+ Una**** comparación simple *del costo total de propiedad (TCO)* entre el panorama de la infraestructura tal como está y la arquitectura posterior a la migración. Servicio de AWS La comparación muestra la diferencia en las tasas de ejecución esperadas para determinados volúmenes de carga de trabajo.
+ Un modelo de negocio**** que muestra el valor actual neto (VAN), el rendimiento de la inversión (ROI), el período de amortización, la tasa interna de rendimiento modificada (MIRR) y los análisis del flujo de caja de 3 a 5 años para migrar a AWS incluir los costes de migración en lugar de quedarse como está. 

El alcance direccional del modelo de negocio suele estar limitado a uno de los siguientes aspectos:
+ Una comparación de los costos de la tecnología de infraestructura
+ Una comparación de los costos de infraestructura, tecnología y operaciones

En general, cuanto mayor sea la cartera, menos desarrollada debe estar la carcasa. Esto se debe a que se pueden hacer suposiciones más amplias sin afectar significativamente el resultado. En el caso de una cartera más pequeña, cualquier cambio tendrá un mayor impacto, por lo que se requieren más detalles.

Comience por crear la comparación de costos de la infraestructura básica. A continuación, decida si la comparación es lo suficientemente convincente antes de continuar. Por lo general, las carteras de más de 400 servidores muestran un argumento empresarial positivo solo en lo que respecta a la reducción de los costes de infraestructura a los 3 años de su puesta en funcionamiento AWS, o 250 servidores a los 5 años, aunque esto puede variar. En el caso de carteras más pequeñas, es posible que se necesiten más detalles.

Por el contrario, rara vez resulta útil examinar otros componentes del valor empresarial en esta fase, como el valor derivado de la mejora de la resiliencia o la agilidad empresarial, a menos que el alcance total de la migración sea inferior a unas 5 cargas de trabajo o 50 servidores.

## Centrarse en los factores de valor
<a name="focus-value-drivers"></a>

La comparación del costo total de propiedad de la tecnología de infraestructura compara un modelo de los costos de infraestructura tal como están con un modelo básico de la Servicio de AWS lista de materiales necesaria para ejecutar sus cargas de trabajo con un rendimiento y una disponibilidad equivalentes. Se pueden realizar muchas optimizaciones. Sin embargo, en este momento, la atención se centra en la siguiente lista, ya que son más fáciles de evaluar y, por lo general, permiten ahorrar alrededor del 30 por ciento en el TCO, lo que es suficiente para seguir adelante:
+ **Elasticidad de procesamiento**: asigne los servidores cuyo uso no es del 100 por ciento, como los servidores de desarrollo o UAT que ejecutan 8x5 (24 por ciento de uso), 10x5 (30 por ciento) o 10x6 (36 por ciento), y los servidores de recuperación ante desastres (DR) que se ejecutan al 2 por ciento, a servicios bajo demanda que se facturan solo cuando se usan.
+ **Adquiera con un plan de ahorro**: planifique adquirir servidores de producción y otros servidores con un uso elevado (superior al 36 por ciento) con un plan de ahorro adecuado para reducir los costos hasta en un 75 por ciento. Las opciones incluyen compromisos de 1 y 3 años, con diferentes niveles de pagos iniciales para garantizar mayores descuentos.
+ **Elimine a los zombis**: identifique los servidores con un uso de la CPU inferior al 2 por ciento que pueda confirmar que ya no son necesarios y elimínelos del análisis de costes.
+ **Calcule el tamaño correcto**: utilice los datos de series temporales de utilización de la CPU y la memoria para evaluar la potencia informática y la memoria necesarias para cada servidor. A continuación, selecciona la instancia de Amazon Elastic Compute Cloud (Amazon EC2) que encaje.
+ Tamaño **correcto de las licencias del sistema de administración de bases de datos relacionales (RDBMS)**: reevalúe sus necesidades de licencias de RDBMS después de calcular el tamaño correcto en sus servidores de bases de datos, compare Bring Your Own License (BYOL) y Procuuring license from y explore el potencial AWS de Amazon Relational Database Service (Amazon RDS) para aumentar los ahorros.
+ **Almacenamiento: asigne** el tamaño adecuado al volumen total de almacenamiento necesario e identifique las necesidades de operaciones por segundo (IOPS) en toda la gama. input/output Determine cuánto se puede trasladar al almacenamiento de objetos, teniendo en cuenta las diferencias SLAs y los costos.

## Necesidades de datos
<a name="data-needs"></a>

En la tabla de [Cómo entender los requisitos de datos de la evaluación inicial](understanding-initial-assessment-data-requirements.md) se muestran los datos necesarios para elaborar cada parte de un modelo de negocio direccional y si son obligatorios u opcionales. 

Para fundamentar el caso, necesita el subconjunto de infraestructura de los datos de planificación iniciales más los datos de costes. Determinar cómo identificar la infraestructura que se va a incluir depende de su objetivo empresarial: 
+ Si el objetivo del programa es migrar y modernizar aplicaciones específicas, cree la cartera de infraestructuras en función de las necesidades de las aplicaciones y teniendo en cuenta la infraestructura compartida. 
+ Si el objetivo del programa se centra en la infraestructura, como la migración desde un centro de datos cuyo arrendamiento está a punto de expirar, no es necesario mapear las aplicaciones para comparar el costo total de propiedad de la infraestructura. 

Los datos que están marcados como opcionales (como el uso máximo de la CPU y la memoria en los servidores) suelen sustituirse por valores de referencia estándar. Puede hablar de ello con un AWS socio o con un servicio AWS profesional. O bien, puede extrapolar los valores a partir de los puntos de datos que están disponibles en una parte de su cartera (como los datos recopilados por un hipervisor). Cuanto más grande sea la cartera, más precisa será.

## Comparaciones del TCO de la infraestructura de edificios
<a name="building-infrastructure-tco-comparisons"></a>

Las herramientas son fundamentales para realizar comparaciones del TCO de la infraestructura. [AWS Los servicios profesionales](https://aws.amazon.com/professional-services/) o un [AWS socio](https://aws.amazon.com/migration/partner-solutions/) pueden ayudarlo con todo tipo de casos direccionales, especialmente si tiene previsto contratarlos para que le ayuden en el proceso de migración más amplio. 

Hay herramientas disponibles para hacer lo siguiente:
+ Recopile datos de inventario.
+ Recopile datos de utilización.
+ Proporcione datos comparativos de costos de infraestructura precisos tal como están.
+ Identifica y elimina a los zombis.
+ Realice evaluaciones del tamaño correcto.
+ Recomiende opciones de compra.
+ Compare las opciones de licencias de software.
+ Realice análisis gráficos sencillos del flujo de caja.

El [evaluador de migración](https://aws.amazon.com/migration-evaluator/) desde AWS es una opción. Proporciona todas estas capacidades como un **servicio gestionado gratuito. Puede** solicitar un evaluador de migración a través de su administrador de AWS cuentas o socio competente en materia de AWS migración o enviando [una solicitud](https://pages.awscloud.com/Migration-Evaluator-request.html) en línea. Migration Evaluator se ha diseñado específicamente como una solución puntual para realizar comparaciones del coste total de propiedad de la infraestructura y la tecnología de forma rápida.

Ventajas clave: 
+ Gratuito
+ Detección sin agentes o configuración manual de los datos de inventario cuando la detección basada en herramientas está restringida
+ Soporte dedicado para facilitar la implementación, la configuración, la recopilación de datos y la creación del caso base o modelo de negocio direccional
+ Comodidad del funcionamiento del SaaS, pero puede ejecutar la recopilación de datos completamente dentro de la red del cliente para facilitar la depuración antes de cargarlos en el motor de análisis
+ Fuerte apoyo al dimensionamiento correcto de las licencias de Microsoft
+ Capacidades completas de exportación de datos 

Limitaciones clave: 
+ Evalúa únicamente los servidores con arquitectura x86 (Windows y Linux) 
+ Opciones limitadas para configurar o calibrar los datos de costos de referencia tal cual
+ No hay soporte para modelar la optimización de los costos de las operaciones
+ No hay soporte para el modelado de costos de migración 
+ No hay soporte directo para elaborar modelos de negocio más allá de las comparaciones del TCO

Si decide utilizar una herramienta de descubrimiento comercial para las funciones de descubrimiento y análisis de carteras, como la pila de aplicaciones y la detección de interdependencias, normalmente también le permitirá comparar el coste total de propiedad de la infraestructura. Para obtener orientación sobre el uso de herramientas para el descubrimiento y la evaluación de carteras, consulte [Evaluación de la necesidad de herramientas de descubrimiento](understanding-initial-assessment-data-requirements.md#discovery-tooling). Para revisar y comparar las capacidades clave de las herramientas líderes del mercado, consulte las herramientas de migración de [descubrimiento, planificación y recomendación](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/).

## Incorporar la optimización de los costos operativos
<a name="building-operational-cost-optimization"></a>

La mejora de la productividad de las operaciones de TI suele aportar un valor significativo a las migraciones. De media, tras la migración AWS, la productividad del personal operativo de TI aumenta un 62 por ciento mediante la migración, según el documento técnico de la Corporación Internacional de Datos (IDC) titulado [Fomentar la transformación empresarial y organizacional para generar valor empresarial con Amazon](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) Web Services. Sin embargo, el dimensionamiento y la inclusión de estos beneficios en el caso de la direccionalidad plantean dos desafíos.

En primer lugar, evaluar toda la gama de aumentos de productividad requiere una amplia recopilación de datos y es más apropiado para un modelo de [negocio detallado.](detailed-business-case.md) Este desafío se puede resolver centrándose en unos pocos elementos que son más fáciles de evaluar y dimensionar con datos de referencia simples, pero que, aun así, muestran una ventaja significativa. 

En segundo lugar, centrarse en la productividad como fuente de reducción de costos puede generar preocupación y negatividad entre los principales clientes, partes interesadas y miembros del programa. Asegúrese de proporcionar claridad sobre cómo se obtendrá el beneficio y qué significa eso para las personas afectadas. Estos problemas se pueden evitar aclarando que esto solo mejorará las funciones del equipo:
+ El programa de migración incluye un plan para desarrollar y trasladar al personal de operaciones internas a nuevas funciones, como unirse a DevSecOps equipos, crear infraestructuras automatizadas mediante códigos y probar automatizaciones que impulsen el crecimiento del equipo.
+ El beneficio se puede obtener modificando y redimensionando los contratos de subcontratación de operaciones, de modo que el personal interno pueda centrarse más en las actividades de mayor valor

Enfoque la elaboración de este elemento empresarial basándose en las transformaciones de las operaciones que desee tener en cuenta:
+ Si ya cuenta con un equipo de operaciones interno, capacite a los miembros del equipo y demuestre la mejora de productividad esperada.
+ También puede migrar su solución de operaciones actual a AWS Managed Services (AMS) o a una oferta alternativa de servicios gestionados de un AWS socio.

Para la primera transformación, a fin de obtener una estimación financiera conservadora de la mejora de la productividad que se puede incluir en el caso, le recomendamos lo siguiente:

1. Céntrese específicamente en la productividad de las operaciones de administración de servidores. Suele representar una proporción significativa del esfuerzo de las operaciones, se puede evaluar más fácilmente y se verifica más fácilmente más adelante. 

1. Calcule el personal necesario en función de los puntos de referencia del número de servidores que puede administrar cada empleado equivalente a tiempo completo (FTE). En las instalaciones, ese número es de unos 150 servidores. En él AWS, son unos 400 servidores.

1. Aplique estas métricas a la cantidad de servidores locales en comparación con la cantidad de instancias de EC2. 

1. Multiplique el tiempo ahorrado con una tarifa de costes combinada para todo el equipo de operaciones.

A continuación, puede comprobar sus resultados con cualquiera de los dos enfoques comprobando que el resultado no supere con creces las ganancias de productividad promedio por función que se muestran en la siguiente tabla (datos extraídos del documento técnico de IDC [Fomentar la transformación empresarial y organizacional para generar valor empresarial con Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)).

 


| **Rol** | **Aumento de la eficiencia** | 
| --- |--- |
| Administración de la infraestructura de TI | 62% | 
| Soporte de TI | 59% | 
| Application Management (Administración de aplicaciones) | 43% | 
| Gestión de bases de datos | 19% | 
| Desarrollo de aplicaciones | 25% | 

Para la segunda transformación, puede añadir los ahorros en los costos operativos comparando directamente el costo total actual de operaciones y soporte de la cartera incluida con el costo del servicio gestionado que se está considerando. 

Para obtener el coste del servicio gestionado, proporcione a su gestor de AWS cuentas o a cualquier [AWS Managed Services socio](https://aws.amazon.com/managed-services/partners/) la AWS lista de materiales propuesta, el nivel de servicio que elija (Plus o Premium) y el paquete AMS (AMS Accelerate o AMS Advanced). Esto le proporcionará un coste total de los servicios gestionados para los siguientes Servicio de AWS componentes de la solución transformada. Del mismo modo, puede solicitar los precios a un AWS socio que ofrezca su propio paquete de servicios gestionados en función de sus propios parámetros.

## Expansión a un modelo de negocio totalmente orientado
<a name="full-directional-business-case"></a>

En general, para elaborar un modelo de negocio integral, realice una comparación del TCO, con o sin el elemento de productividad de la TI, y calcule todos los costos de migración y modernización. A continuación, cree un flujo de caja que abarque pares de escenarios migrate-and-modernize y situaciones en las que no se debe hacer. t-migrate-and-modernize 

El caso más básico es la preparación de un solo par de escenarios, donde el t-migrate-and-modernize escenario de no hacer es tu situación actual y el migrate-and-modernize escenario tiene las siguientes características:
+ El volumen de transacciones, el cómputo o la capacidad de red no aumentan ni disminuyen
+ Crecimiento constante y bajo de los requisitos de almacenamiento
+ Quality-of-service capacidades (como la disponibilidad, la durabilidad, el rendimiento y el rendimiento) que coinciden con las capacidades del sistema existente

Para todas las carteras, excepto las muy pequeñas, esto se ajusta bien a los objetivos de crear un modelo direccional. Demuestra su valor suficiente rápidamente como para obtener el mandato necesario para seguir adelante. 

En el caso de carteras más pequeñas, puede resultar útil añadir pares de t-migrate-and-modernize situaciones migrate-and-modernize hipotéticas que demuestren otros aspectos del aumento del valor de la migración a la nube, como:
+ Una combinación de requisitos de crecimiento de capacidad moderados y altos en todas las cargas de trabajo en las que se espera ese crecimiento
+ Inclusión de una resiliencia mejorada, como la alta disponibilidad, la recuperación ante desastres y la tolerancia a errores
+ Rendimiento global mejorado con computación perimetral, red de entrega de contenido (CDN) y replicación de bases de datos multirregional.
+ Cualquier otra mejora de calidad de servicio específica que haya convertido en una prioridad empresarial para el programa

En estos escenarios, asegúrese de estimar con precisión los costes y las implicaciones en el flujo de caja de la actualización de la arquitectura actual de infraestructura no basada en la nube para adaptarla a la nueva especificación. La forma más directa de obtener esta estimación puede consistir en solicitar un presupuesto a un integrador de sistemas, especialmente si también es un socio AWS consultor con competencias en materia de migración, que puede ayudarlo tanto en el migrate-and-modernize caso de que no lo haga. t-migrate-and-modernize 

Para cada par de escenarios, prepare un caso que incluya lo siguiente:
+ Los costes del t-migrate-and-modernize escenario de no hacerlo. En el caso más básico, esto incluye:
  + El coste total de propiedad a lo largo del plazo de viabilidad de la configuración de infraestructura actual
  + Aumentos periódicos del consumo de cómputo, almacenamiento y tráfico de red 
+ Los costos del escenario migrate-and-modernize; que incluyen:
  + Configurar el programa, que incluye la detección detallada, la planificación de la migración, el desarrollo detallado de los casos de negocio, la creación del equipo central y la mejora de sus habilidades, el establecimiento de una landing zone, si aún no existe, y el establecimiento de la gestión de la seguridad y la integración de las operaciones para las cargas de trabajo migradas
  + Los costos de migración y modernización de la carga de trabajo 
  + Los costos de la infraestructura de migración, incluidas las conexiones de red, los servicios de migración de datos (por ejemplo [AWS DataSync](https://aws.amazon.com/datasync/), [AWS Snowball Edge](https://aws.amazon.com/snowball/)y) AWS y los costos de los servicios de la arquitectura necesaria durante el proceso de migración en sí (por ejemplo, para las pruebas)
  + El aumento de los costos de los AWS servicios públicos a lo largo de la migración a medida que se van produciendo las olas, y la disminución de los costos de la infraestructura existente, al ser reemplazada por servicios AWS basados y desmantelada
+ Los costes de desmantelamiento y las amortizaciones de los activos abandonados

## Estimación de la configuración del programa de migración y modernización
<a name="estimating-migration-and-modernization-program-setup"></a>

Para configurar un programa con éxito, si no lo ha hecho antes, es posible que necesite llevar a cabo una serie de actividades fundamentales para desarrollar las capacidades básicas y el plan detallado. Estas actividades fundamentales incluyen las siguientes:

1. Realizar el descubrimiento detallado de la cartera, la planificación de la migración y el desarrollo detallado de los casos de negocio, tal como se describe en la sección de [análisis y planificación de la migración de la cartera](portfolio-analysis-migration-planning.md), además de documentar el costo de cualquier herramienta de descubrimiento utilizada.

1. Establecer un equipo central técnico y empresarial en la nube y desarrollar las habilidades internas mediante la formación y la contratación. Identifique a los miembros de la organización de TI que necesitarán formación y asigne un presupuesto de formación a cada persona.

1. Establecer una [landing zone](https://aws.amazon.com/solutions/implementations/aws-landing-zone/) y configurarla para que soporte las capacidades de gestión de costes, operaciones y seguridad que necesitará.

AWS Los socios consultores pueden ayudar a proporcionar estimaciones para los puntos 1 y 3. 

*Estimación de los costos de migración y modernización*

Para cumplir los objetivos de un modelo de negocio direccional y demostrar el potencial comercial *suficiente* para pasar a la siguiente fase, procure que la estimación de los costos de migración y modernización sea lo más básica posible. 

Para ello, le recomendamos que prepare el modelo de negocio orientativo centrándose en las aplicaciones incluidas en las siguientes estrategias de migración: 
+ Retirar
+ Retener
+ Reubicar
+ Volver a alojar
+ Redefinir la plataforma
+ Recompra

Por lo general, alrededor del 70 por ciento de las cargas de trabajo se pueden realojar, reubicar o cambiar de plataforma, y otro 5 por ciento se puede retirar. La evaluación de las aplicaciones por estrategia de migración suele abordar el aspecto central de la reducción de costes. 

**Estimar los costos de la refactorización o la rearquitectura puede resultar complejo.** No es práctico intentarlo dentro del plazo previsto para preparar un modelo de negocio orientativo. Como se explicó anteriormente en [Determinar el tipo R para la migración](prioritization-and-migration-strategy.md#migration-r-type), considere la posibilidad de utilizar estrategias de rehospedaje, reubicación o replataforma para la primera fase de migración y modernización. Es probable que estas estrategias R aceleren la recuperación inicial, reduzcan el riesgo de implementación y mejoren el modelo de negocio a corto plazo. También es considerablemente más fácil para sus equipos de aplicaciones modernizar las aplicaciones que se ejecutan en el AWS entorno que las que no lo están. [Es mejor añadir las estimaciones para la refactorización (rediseño de la arquitectura) de aplicaciones específicas cuando se prepara un modelo de negocio detallado.](detailed-business-case.md) 

*Estimación del esfuerzo de migración por estrategia*

Cada migración es diferente. Antes de comprometer cualquier presupuesto o plan, procure realizar estimaciones de la carga de trabajo para las actividades de migración a cargo del equipo responsable del proyecto, ya se trate de sus equipos de aplicaciones internos, de servicios AWS profesionales o de una organización AWS asociada. 

Para ayudar a establecer una hipótesis orientativa, la siguiente tabla proporciona los rangos de esfuerzo indicativos para los diferentes tratamientos. Estos rangos suponen que se está migrando una medium-to-large cartera y que el equipo de migración está formado y tiene experiencia. En el caso de carteras pequeñas, lo mejor es que el equipo responsable de la migración prepare la estimación, incluso si se trata de un caso direccional.


| Estrategia de migración | Proceso de estimación | Elementos | Horas de trabajo por persona | Horas de trabajo por persona | 
| --- |--- |--- |--- |--- |
| Retener | No haga nada, sin costos, sin beneficios y sin reducir la deuda tecnológica. | – | – | – | 
| Retirar | Calcule el desmantelamiento del equipo de hardware utilizado, si lo hubiera. | – | – | – | 
| Reubicar | Calcule la posibilidad de copiar la carga de trabajo mediante el VMware uso de VMware herramientas. Esto incluye copiar los datos, realizar pruebas de humo para verificarlos y desmantelar cualquier hardware. El esfuerzo de reubicación VMs suele ser menor que en el caso de los patrones de rehospedaje de baja complejidad. | – | – | – | 
| Volver a alojar | Calcule la posibilidad de copiar la carga de trabajo y los datos con una copia de imagen, realizar pruebas de humo, realizar pruebas de alta disponibilidad (HA) y recuperación ante desastres (DR), cuando proceda, para los servidores de producción y cualquier desmantelamiento del hardware. La mejor práctica consiste en utilizar herramientas como [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/): Divida las cargas de trabajo en complejidad baja, media y alta en función de factores como si se está ejecutando una base de datos u otro software de infraestructura, la complejidad de la base de datos, si está agrupada en clústeres, la complejidad de la integración y los volúmenes de datos. | Esfuerzo por aplicación y servidor | Migración | Prueba HA/DR | 
| Bajo | 10—14 | 3—5 | 
| Medio | 16—24 | 4—6 | 
| Alto | 26—38 | 8—12 | 
| Redefinir la plataforma | En el caso de las migraciones de cambio de plataforma que incluyan actualizaciones al sistema operativo o a la versión del RDBMS, prevea un realojamiento y añada tiempo para realizar una reconstrucción y una prueba de humo en la nueva plataforma. Si la replataforma incluye cambiar la tecnología de la plataforma, calcule el tiempo adicional para el uso de las herramientas de conversión, como y, y una prueba de aplicación más completa. [AWS Schema Conversion Tool[AWS Database Migration Service](https://aws.amazon.com/dms/)](https://aws.amazon.com/dms/schema-conversion-tool/) Un ejemplo de cambio de tecnología es la migración de una base de datos comercial propietaria a una sustituta de código abierto. | Esfuerzo por aplicación y servidor | Versión superior | Cambio tecnológico | 
| Bajo | Sumar 1—3 | Sume 10—15 | 
| Medio | Sumar 2—5 | Suma 20—30 | 
| Alto | Sumar 4-8 | Sumar 40—60 | 
| Recompra | Calcule la extracción, la transformación y la carga de datos en el reemplazo del servicio SaaS recién adquirido y en cualquier desmantelamiento del hardware. | – | – | – | 

*Estimación de los costos de la infraestructura de migración*

Incluya estimaciones de la infraestructura que utilizará durante la migración. Por lo general, estas estimaciones comprenden:
+ Un presupuesto para servicios de conectividad e intercambio de datos para la migración de la carga de trabajo y los datos del entorno actual a AWS
+ Un presupuesto para lo necesario Servicios de AWS (especialmente el cómputo y el almacenamiento) para alojar las cargas de trabajo migradas durante los procesos de migración, pruebas y transición
+ El aumento de los costos de los AWS servicios públicos a medida que se completa cada ola de migración
+ Los costos de desmantelamiento de la infraestructura existente que ya no ejecutará las cargas de trabajo migradas

Para el intercambio de datos, examine sus volúmenes totales de datos y evalúe la viabilidad de utilizar las redes. Si ha aprovisionado un [AWS Direct Connect](https://aws.amazon.com/directconnect/)enlace o un punto [Site-to-Site VPN](https://aws.amazon.com/vpn/)de AWS la WAN con antelación para su uso operativo tras la migración, puede utilizar ese recurso hasta alcanzar su cuota de servicio. 

Si la capacidad de la red es insuficiente, un aumento a corto plazo del ancho de banda de Internet con una red privada virtual (VPN) suele ser una solución muy rentable. Si no es así, AWS los dispositivos de intercambio multimedia, como [AWS Snowball Edge](https://aws.amazon.com/snowball/)la mayoría, [AWS Snowball Edge](https://aws.amazon.com/snowcone/)ofrecen soluciones Regiones de AWS. Además, si se trata de una migración de datos de gran volumen, considere la posibilidad de incluir un presupuesto [AWS DataSync](https://aws.amazon.com/datasync/), ya que mejora la fiabilidad y puede acelerar las transferencias, independientemente del medio utilizado.

Modelar la expansión de AWS los servicios y la reducción de la infraestructura existente es importante para el análisis del flujo de caja del modelo de negocio. En este momento, no es probable que tenga un plan de oleaje para determinar exactamente cuándo se incurrirá en los costos. Le recomendamos lo siguiente:
+ Aumentar los costes AWS a un ritmo constante durante la migración. 
+ Al reducir los costos de la infraestructura existente, planea desmantelar a un ritmo constante durante el mismo período.

Empezar a aumentar los AWS costes uno o dos meses antes de reducir la infraestructura existente. Esto proporciona 1 mes de uso de AWS servicios públicos para realizar la migración de cada oleada. Incluye tiempo para realizar las pruebas y tiempo adicional para completar el trabajo de desmantelamiento necesario a fin de dejar de incurrir en costes en la infraestructura sustituida.

*Estimación de los costos de desmantelamiento*

El desmantelamiento de los equipos que no se puedan redistribuir y su eliminación de forma legal y respetuosa con el medio ambiente pueden implicar algunos costes pequeños. Sin embargo, si se trata de un modelo de negocio orientativo, normalmente la única suma potencialmente importante es el coste de amortizar cualquier resto del valor contable de los activos sustituidos.

Para el modelo de negocio direccional, le recomendamos que haga lo siguiente:
+ Revise su lista de activos.
+ Identifique los que serían desmantelados.
+ Para reducir la amortización, estudie las posibilidades de cambiar de dispositivo a fin de poder utilizar los dispositivos más nuevos de la lista para sustituir activos más antiguos y más amortizados. 
+ Haga una evaluación del valor contable futuro de los activos que se desmantelarían en ese momento.
+ Incluya esto como el costo de migración del desmantelamiento.

*Ensamblar y ajustar el modelo de negocio totalmente direccional*

Después de preparar el conjunto completo de costos para cada par de escenarios, elabore un estado de flujo de caja descontado para cada uno y grafíquelos. Recomendamos crear modelos de negocio direccionales durante el mismo período del ciclo de actualización del hardware. Esto suele ser de 5 años para los servidores, el almacenamiento y los dispositivos de red. Si se utiliza el mismo período que el ciclo de actualización del hardware, los costes de exactamente una actualización se incluyen en los costes actuales de cada escenario.

A continuación, calcule las métricas financieras clave que necesita para obtener la aprobación necesaria para pasar a la siguiente fase del programa. Por lo general, incluimos lo siguiente:
+ El valor actual neto (VAN) para medir el valor absoluto de las reducciones de costes y los aumentos de productividad evaluados
+ El período de amortización en meses para comprobar que las devoluciones son lo suficientemente rápidas
+ La comparación final de las tasas de ejecución para comprobar si el proceso está reduciendo los costes suficientes a lo largo del plazo
+ El rendimiento de la inversión (ROI) y la tasa de rendimiento de la inversión modificada (MIRR) para evaluar el rendimiento financiero relativo del programa en comparación con otras demandas de capital que su organización pueda estar priorizando

Utilice la primera iteración del caso para determinar si el rendimiento financiero esperado significa que se deben realizar mejoras, como en los ejemplos siguientes:
+ Si la amortización es demasiado lenta, considere opciones para acelerar y reducir el costo de la migración, como las siguientes:
  + Utilice AWS socios o servicios AWS profesionales para ampliar los recursos disponibles y paralelizar aún más la migración de las cargas de trabajo con patrones más básicos. 
  + En el caso de las cargas de trabajo en curso VMware, compare la estrategia de reubicación con la estrategia de realojamiento o replataforma, al menos en la fase inicial. El uso de la estrategia de reubicación puede reducir los costos de migración y aumentar la velocidad de migración.
  + Cuando sea técnicamente posible, lleve las cargas de trabajo que requieran estrategias más complejas de replataforma o refactorización (rediseño) a una fase futura, fuera del ámbito del modelo de negocio inicial.
+ Si el ROI y el MIRR son demasiado bajos, tenga en cuenta lo siguiente:
  + ¿Los escenarios que está considerando son demasiado conservadores? ¿Tiene un escenario que refleje las necesidades más probables de crecimiento de la capacidad y elasticidad? ¿Tiene escenarios que comparen los costos, incluidos los aumentos en la calidad del servicio, dentro de sus objetivos?
  + ¿Puede refinar el alcance de la cartera de aplicaciones que se va a migrar en la primera fase para centrarse en las cargas de trabajo que generen mayores retornos, como las que tienen un menor uso actual o que requieren costosas necesidades de recuperación ante desastres (DR)?
  + ¿Puede refinar el alcance de la cartera de aplicaciones para excluir inicialmente cargas de trabajo específicas que tengan un menor rendimiento comercial? Por ejemplo, ¿puede posponer las cargas de trabajo para las que las licencias de software de terceros se vuelven más caras debido a las diferentes condiciones de despliegue en la infraestructura de nube pública?
+ Si la comparación final de la tasa de ejecución no cumple el objetivo esperado, explore lo siguiente:
  + En primer lugar, confirme que las demás métricas cumplen con las expectativas. El objetivo principal es demostrar que hay suficientes oportunidades financieras para justificar el inicio de la siguiente fase de preparación de la migración. 
  + Identifique una lista de las oportunidades para seguir mejorando la rentabilidad una AWS vez finalizada la fase inicial de la migración.

Incluya una evaluación de la lista de oportunidades al preparar el modelo de negocio detallado. Además, incluya una evaluación de las oportunidades en el mantenimiento continuo del caso y en el proceso de month-to-month optimización de costes una vez finalizada la migración.