Creación de un modelo de negocio direccional

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, de modo que pueda 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

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 y análisis de la cartera y planificación de la migración.

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

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 mejor se ajuste.

• 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 Procuring license from y explore el potencial AWS de Amazon Relational Database Service (Amazon RDS) para aumentar los ahorros.

• Almacenamiento: ajuste el tamaño adecuado del volumen total de almacenamiento necesario e identifique las necesidades de operaciones de entrada/salida por segundo (IOPS) en toda la cartera. Determine cuánto se puede transferir al almacenamiento de objetos, teniendo en cuenta las diferencias y los costos. SLAs

Necesidades de datos

En la tabla de Cómo entender los requisitos de datos de la evaluación inicial 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 se marcan 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

Las herramientas son fundamentales para realizar comparaciones del TCO de la infraestructura. AWS Los servicios profesionales o un AWS socio 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 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 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. 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.

Incorporar la optimización de los costos operativos

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 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. 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 operativo, se puede evaluar más fácilmente y se verifica más fácilmente más adelante.

2. 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, se trata de unos 400 servidores.

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

4. Multiplique el tiempo ahorrado por 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).

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 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

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, AWS Snowball Edgey) 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 inmovilizados

Estimación de la configuración del programa de migración y modernización

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, además de documentar el costo de cualquier herramienta de descubrimiento utilizada.

2. 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.

3. Establecer una 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, 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.

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: 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 ToolAWS Database Migration Service 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 costes 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 Connectenlace o un punto AWS VPNde 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 Edgela mayoría, AWS Snowball Edgeofrecen 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, 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. 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.