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.
# Prácticas recomendadas
La decisión de retirar las aplicaciones puede ser compleja, especialmente durante una migración a la AWS nube. En las siguientes secciones se proporcionan las mejores prácticas para utilizarlas en el proceso de toma de decisiones.
**Topics**
+ [Considere un enfoque basado en una fábrica de migraciones](best-practice-1.md)
+ [Identifique y retire las aplicaciones al principio de la migración](best-practice-2.md)
+ [Concéntrese en los datos y utilice herramientas de descubrimiento para evitar interrupciones](best-practice-3.md)
+ [Programe una parada controlada](best-practice-4.md)
+ [Vuelva a evaluar si la aplicación se debe migrar](best-practice-5.md)
+ [Retire la aplicación](best-practice-6.md)
# Considere un enfoque basado en una fábrica de migraciones
Una parte importante de cualquier migración a gran escala consiste en establecer una *fábrica de migración* después de migrar las cargas de trabajo piloto iniciales.
Una fábrica de migración se compone de equipos, herramientas y procesos que trabajan en conjunto para agilizar las migraciones de forma sistemática, incorporando las lecciones aprendidas de las oleadas migratorias anteriores. La fábrica de migración aplica patrones que aceleran las migraciones de las cargas de trabajo y mejoran el resultado final.
En función del tamaño de la cartera de TI que necesite retirar, vale la pena considerar si es útil implementar un enfoque de fábrica de migración. Las metodologías y los principios descritos en esta guía también complementarán este enfoque y pueden integrarse en sus mecanismos.
Usualmente, entre el 20 y el 50 por ciento de la cartera de aplicaciones empresariales se compone de patrones repetidos que pueden optimizarse mediante un enfoque de fábrica de migración. Para ver un ejemplo de un patrón, consulte la [solución Fábrica de migración a la nube en AWS](https://aws.amazon.com//solutions/implementations/cloud-migration-factory-on-aws/), que puede implementar un equipo de migración para coordinar y automatizar las migraciones.
El equipo debe comenzar con las aplicaciones que tengan la menor criticidad empresarial, antes de pasar gradualmente a sistemas más críticos. Cuando el equipo comience a migrar los sistemas fundamentales para la empresa, habrá migrado cientos, si no miles, de cargas de trabajo y habrá aprendido muchas lecciones.
Antes de que comience la fase de evaluación, puede crear un proceso para recopilar los datos de dependencia correspondientes a un mes para las aplicaciones cuya retirada esté prevista. Se notifica a un equipo y se le da acceso a los datos cuando están listos. Luego, el equipo puntúa los datos en función de la posibilidad de que una aplicación cause un impacto. Luego, los propietarios de la aplicación podrían realizar un análisis más profundo de las conexiones antes de comenzar los siguientes pasos.
Para obtener más información sobre la metodología de la fábrica de migraciones, consulte la [Guía para migraciones grandes AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/).
# Identifique y retire las aplicaciones al principio de la migración
Es importante identificar las aplicaciones y, a continuación, retirarlas al principio del proceso de migración, y debe llevarse a cabo mientras se migran las cargas de trabajo.
Los proyectos de migración suelen priorizar la migración de las cargas de trabajo, por lo que es habitual que los sistemas que se consideran retirados (y no migrados) reciban atención hacia el final del proyecto. Sin embargo, existe el riesgo de que dejar estas aplicaciones hasta el final del proyecto deje muy poco tiempo para incluirlas en la migración si la aplicación se considera importante más adelante.
La retirada anticipada de las cargas de trabajo durante un proyecto de migración reduce la carga de trabajo de los equipos que las mantienen. Por ejemplo, si se retiran los servidores durante las fases iniciales de un proyecto de migración, los equipos de sistemas operativos tienen menos servidores que reparar, actualizar, mantener o dar soporte. De este modo, esos equipos pueden centrarse en el proyecto de migración en sí.
Por último, algunas de las mejores prácticas de esta guía son más eficaces cuando se mantienen durante períodos de tiempo más largos. Si comienza el proceso de retirada anticipadamente, pero luego determina que otro servicio realmente requiere una solicitud, podrá modificar su plan de migración e incluirlo en una ola de migración futura.
# Concéntrese en los datos y utilice herramientas de descubrimiento para evitar interrupciones
Basarse en los datos es fundamental a la hora de considerar la retirada de aplicaciones. Los diagramas de arquitectura y el conocimiento institucional pueden quedar fácilmente desactualizados o incompletos. A veces, también pueden surgir problemas imprevistos, como que otra aplicación pase a depender de su sistema sin una contratación formal debido a una situación de reparación de averías.
Un enfoque basado en datos proporciona la base sobre la que puede tomar decisiones o validar un enfoque. Al evaluar si una aplicación se puede retirar, debe confirmar que las cargas de trabajo que está migrando no dependen de ella. La migración de esas cargas de trabajo y, posteriormente, la retirada de una dependencia podría provocar una degradación del servicio o, lo que es peor, una interrupción del servicio.
Afortunadamente, es bastante sencillo entender estas dependencias mediante el uso de datos para supervisar las conexiones entrantes y salientes de la red en un servidor cuya retirada está prevista. Las conexiones entrantes de red, como una aplicación que se conecta a su aplicación, y las conexiones salientes, como la carga de un archivo a un recurso compartido del Sistema de Archivos de Red (NFS), indican una posible dependencia ascendente. Es necesario investigar esta dependencia, ya que si una carga de trabajo que se va a migrar a la AWS nube se conecta a la aplicación, existe la posibilidad de que se interrumpa el servicio si la aplicación se retira más adelante. Es posible que este proceso requiera profundizar para seguir la cadena de dependencias. Siguiendo con el ejemplo anterior, si la aplicación carga un archivo en un recurso compartido de NFS, el siguiente paso es determinar qué sistema consume ese archivo y el estado de la aplicación.
Puede decidir investigar esas conexiones y evaluar el nivel de impacto. Para ello, puede utilizar las herramientas de detección para mostrar las conexiones que se están iniciando con un servidor cuya retirada está prevista. Puede observar que la mayoría de las conexiones provienen de servidores de administración y se pueden ignorar, ya que se trata de herramientas que recopilan métricas de rendimiento o instancias de proxy del administrador del sistema. Sin embargo, si hay aplicaciones que se conectan al servidor y cuya migración está programada, debería profundizar más y comprobar el posible impacto de la migración en esa aplicación.
[AWS Application Discovery Service](https://aws.amazon.com/application-discovery/)ayuda a los clientes a planificar los proyectos de migración mediante la recopilación de información sobre los centros de datos locales que tienen previsto retirar. Tras implementar el agente en los servidores, Application Discovery Service registra la actividad de red entrante y saliente de cada servidor, junto con otra información. Al utilizar [Amazon Athena](https://aws.amazon.com/athena/) para analizar estos datos, puede identificar si otras aplicaciones dependen de servidores cuya retirada está prevista. [AWS Los socios con competencias en migración](https://aws.amazon.com//migration/partner-solutions/) también pueden proporcionar herramientas de descubrimiento y planificación exhaustivas.
**nota**
Application Discovery Service ya no está abierto a nuevos clientes. Como alternativa, utilice AWS Transform uno que ofrezca capacidades similares. Para obtener más información, consulte [Cambio en la disponibilidad de AWS Application Discovery Service](https://docs.aws.amazon.com/application-discovery/latest/userguide/application-discovery-service-availability-change.html).
Por ejemplo, en la siguiente ilustración de pantalla se muestran cuatro direcciones IP de origen que se conectan al servidor en el puerto 22 (destino = 172.31.1.117).
![\[Ejemplo de análisis de conexiones.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/migration-retiring-applications/images/best-practices-4.png)
Se trata de hosts bastión que utilizan los administradores del sistema y que pueden ignorarse. La imagen también muestra dos servidores que se conectan a esta aplicación en el puerto 80 y que están siendo objeto de una migración planificada. En esta etapa, necesitaría profundizar y comprender las aplicaciones que se conectan. Este análisis más profundo le permitirá evaluar si habrá algún impacto positivo tras la retirada.
# Programe una parada controlada
En su plan de migración, asegúrese de programar una parada controlada durante el proceso de migración. Una parada controlada detiene el proceso de migración para identificar las posibles interrupciones en caso de que se retire una aplicación. Simula la retirada de la solicitud y permite observar las consecuencias. Cuando se complete el período de parada controlada, la migración se puede reanudar fácilmente.
El enfoque de parada controlada varía según el tipo de aplicación y los procesos asociados con los que esté trabajando. Los patrones de parada controlada más comunes incluyen:
+ Implementación de un firewall basado en un host para bloquear todo el tráfico, lo que simula la retirada
+ Pausa de una máquina virtual
+ Detener un servicio en el host
+ Bloquear todo el tráfico mediante un firewall externo
Los propietarios del proyecto de migración y de la aplicación deben definir la duración de una parada controlada, en función del tipo de aplicación. Por ejemplo, si va a retirar una carga de trabajo por lotes que solo se ejecuta una vez al mes o una vez al trimestre, es posible que realizar una parada controlada de una semana no sea suficiente para determinar el impacto en otros sistemas.
Siguiendo con el ejemplo de la sección anterior, otra aplicación se estaba conectando al servidor cuya retirada estaba prevista. En una evaluación inicial se llegó a la conclusión de que no debería haber ningún impacto en los servidores anteriores. Ahora se puede realizar una parada controlada para comprender el impacto.
Esta parada controlada se llevaría a cabo mediante la implementación de un firewall basado en el host para bloquear todo el tráfico, simulando el efecto de apagar el servidor. Si esto provoca problemas de servicio en las aplicaciones cuya migración a la AWS nube está programada, se añade una regla de firewall y se reanuda todo el tráfico. Tras la parada controlada, se reconsidera la retirada del servidor debido a la degradación o interrupción del servicio.
# Vuelva a evaluar si la aplicación se debe migrar
Las dos últimas mejores prácticas que analizamos ayudan a determinar si es apropiado continuar tomando medidas en los sistemas cuya retirada está programada. Si esas mejores prácticas ponen de relieve un posible impacto empresarial inicial, debería plantearse la posibilidad de volver a evaluar el patrón de migración de la aplicación. Al iniciar anticipadamente el proceso de retirada de una solicitud, dispondrá de tiempo suficiente para incluir la solicitud en una ola de migración posterior en caso de que surjan problemas o dependencias que impidan retirarla.
Si, después de seguir estas prácticas recomendadas, no tiene plena confianza en retirar la aplicación, considere la posibilidad de volver a alojarla en la nube. AWS Esto es especialmente importante si la migración tiene una fecha de finalización establecida, como el vencimiento del arrendamiento de un centro de datos.
Servicios como el [Servicio de migración de aplicaciones de AWS](https://aws.amazon.com/application-migration-service/) simplifican el enfoque de migración del realojamiento. Al migrar aplicaciones a AWS, puede tomar una instantánea diaria de los volúmenes de Amazon Elastic Block Store (Amazon EBS) y cancelar la instancia de Amazon Elastic Compute Cloud (Amazon EC2) para reducir los costos y probar el retiro de la aplicación durante un período prolongado. Si se produce un impacto o un problema, puede confiar en que podrá crear los volúmenes de EBS a partir de la instantánea para reanudar la instancia de EC2.
**importante**
Pruebe este proceso de recuperación antes de terminar la instancia EC2.
# Retire la aplicación
Tras seguir las cinco mejores prácticas anteriores de esta guía, es posible que haya determinado que es seguro retirar una solicitud. Implementó un enfoque basado en una fábrica de migraciones, inició el proceso de retirada anticipadamente, utilizó herramientas de datos y detección para supervisar las conexiones entrantes, realizó una parada controlada correcta y evaluó si la aplicación debía retirarse. Ahora es posible retirar la aplicación como parte de su estrategia de migración.
En este punto, debe comprobar si la aplicación contiene datos que puedan ser útiles en el futuro. Machine learning (ML) y el análisis han dado a los datos un valor mayor que nunca. Aunque es posible que no esté desarrollando algoritmos de aprendizaje automático ahora, los datos históricos pueden resultar beneficiosos en el futuro. Es posible que también tenga requisitos normativos o de cumplimiento para almacenar los datos durante un período de tiempo definido, incluso si la aplicación se ha retirado.
AWS ofrece un conjunto completo de servicios de almacenamiento en la nube para la retención a largo plazo, el cumplimiento y la preservación digital. AWS las soluciones de almacenamiento para el archivado de datos ayudan a ofrecer una escalabilidad ilimitada, una durabilidad del 99,19%, fiabilidad y seguridad de los datos.
Para ayudarlo en sus esfuerzos de cumplimiento, obtiene AWS periódicamente la validación por parte de terceros de miles de requisitos de conformidad globales. Estos se supervisan continuamente para ayudarle a cumplir con los estándares de seguridad y conformidad en los ámbitos financiero, minorista, sanitario, gubernamental y más.
Para obtener más información sobre el archivado de datos con AWS, consulte [Archivo de datos](https://aws.amazon.com//archive/) en el AWS sitio web.