Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El planeamiento y la gobernanza adecuados son fundamentales para la modernización. En esta fase, usted decide qué enfoque de modernización aplicar y cómo hacerlo. La planificación cuidadosa reduce la posibilidad de excedentes presupuestarios, desviaciones del alcance o interrupciones del servicio durante la ejecución.
Elección de una estrategia de modernización
La modernización de una carga de trabajo significa actualizarla para alinearla mejor con los objetivos empresariales actuales, los estándares técnicos y las funcionalidades de la nube. Las tres estrategias principales (migración, refactorización y rediseño) existen en un continuo de complejidad y valor. La mayoría de los esfuerzos de modernización usan una combinación de estos enfoques.
La clave es hacer coincidir la estrategia con las necesidades específicas de cada componente, teniendo en cuenta los objetivos, la escala de tiempo y los recursos disponibles. Evite la tentación de modernizarse demasiado. Aunque las nuevas tecnologías son emocionantes, todas las decisiones deben fundamentarse en el valor empresarial.
| Estrategia de modernización | Definition | Cuándo usar | Pros | Cons |
|---|---|---|---|---|
| Replatform | Mover aplicaciones a plataformas en la nube con cambios mínimos de código (IaaS a PaaS). | Resultados rápidos con mínima interrupción necesaria. El código actual funciona, pero la carga de las operaciones es alta. | Implementación rápida. Reduce el esfuerzo de mantenimiento. Mejora la confiabilidad a través de una mejor infraestructura. | Mejoras de funcionalidad limitadas. La aplicación principal permanece sin cambios. |
| Refactor | Modifique el código existente para mejorar la estructura, el rendimiento y la optimización de la nube al tiempo que mantiene la funcionalidad. | La deuda técnica provoca problemas o código no está optimizado para la nube. | Mejora la capacidad de mantenimiento, el rendimiento y la seguridad. Permite mejoras futuras más sencillas. | Requiere un esfuerzo y pruebas importantes para desarrolladores. No hay nuevas características inmediatas para los usuarios. |
| Rearchitect | Rediseñe la arquitectura de aplicaciones mediante patrones nativos de la nube (microservicios, sin servidor y controlados por eventos). | La arquitectura actual limita el crecimiento o la optimización de la nube. | Aborda los problemas fundamentales de escalabilidad. Habilita servicios en la nube avanzados. Establece la base para la innovación a largo plazo. | Lo más complejo y lento. Alto costo inicial y riesgo. Requiere pruebas exhaustivas y operaciones paralelas. |
Planear las modernizacións en fases
Intentar modernizar toda una carga de trabajo compleja (o varias) de una sola vez es arriesgado. Divida el esfuerzo en fases lógicas. La fase le permite ofrecer valor incremental, reducir el riesgo abordando fragmentos manejables y ajustando el curso entre fases en función de lo que aprenda.
Divida las modernizacións en fases lógicas. Determine cómo segmentar el trabajo. No hay una sola "manera correcta". Elija el desglose que tenga sentido para la arquitectura y la estructura del equipo. El objetivo es que cada fase sea lo suficientemente pequeña como para ejecutar y probar sin sobrecargar la complejidad, pero lo suficientemente significativo como para proporcionar valor. Formas comunes de desglosar fases:
División (método) Description Example Por componente o capa Fases independientes basadas en capas de carga de trabajo o límites de carga de trabajo Fase 1: Migración de bases de datos, Fase 2: Refactorización de aplicaciones, Fase 3: Modernización de la interfaz de usuario Por prioridad y complejidad Organización del trabajo desde cambios de bajo riesgo a alto riesgo Fase 1: Servicios no críticos, Fase 2: Lógica empresarial básica, Fase 3: Características orientadas al cliente Por función empresarial Fases de estructura en torno a los límites funcionales o de la aplicación Fase 1: Carga de trabajo de administración de usuarios, Fase 2: Procesamiento de pagos, Fase 3: servicios de informes Comience con cambios de bajo riesgo y de alto valor. Para tu fase 1, elige algo que es factible y proporciona una victoria tangible, pero no pone en peligro el negocio si surgen problemas. Por ejemplo, modernice primero un servicio back-end o una herramienta interna en lugar del sitio web orientado al cliente. Aspira a completar la primera fase rápidamente (un mes o dos) como punto de prueba. El éxito anticipado crea confianza en el equipo y el apoyo de las partes interesadas para las fases posteriores.
Secuencia de fases restantes por valor y dependencias. Después de la primera fase, planee el orden de las fases posteriores en función del valor empresarial y las dependencias técnicas. Cree una hoja de ruta en la que cada fase tenga un ámbito definido y garantice que los componentes críticos tengan sus elementos auxiliares ya modernizados o compatibles.
- Abordar áreas frágiles. Si una carga de trabajo es frágil en su estado actual, es posible que incluso necesite una "Fase 0" preliminar para estabilizarla (aplicar correcciones urgentes en el entorno antiguo) para que sea segura modernizarla en la fase 1.
- Abordar primero los requisitos previos: Si la modernización de la carga de trabajo B depende de la carga de trabajo A modernizada (o al menos estable), realice primero la carga de trabajo A.
- Considere el valor empresarial frente al riesgo: Puede decidir alternar, realizar una pieza de alto valor pero más arriesgada en una fase, luego una parte de menor riesgo en la siguiente, para equilibrar la carga en el equipo y el riesgo para la empresa.
Defina criterios de éxito para cada fase. Para cada fase, decida cuándo se completa y es exitosa. Tener criterios de salida claros impide la expansión no controlada del alcance en una fase. Los criterios de éxito pueden incluir:
Tipo de criterios de éxito Examples Objetivos técnicos • El servicio X se ejecuta en Azure App Service y controla 20% más carga
• Database Y migra a Azure SQL sin pérdida de datos y con un rendimiento dentro del 10 % del valor de referencia anterior.Puertas de calidad • No hay errores de severidad 1 abiertos
Todas las pruebas automatizadas pasan
• El examen de seguridad muestra cero vulnerabilidades críticasRestricciones de tiempo y presupuesto • Completar en un plazo de tres meses y en un plazo de 5% del presupuesto
• Implementar durante las ventanas de mantenimiento programadasAdaptar planes en función de los resultados. Después de completar una fase, revise los resultados y las lecciones aprendidas. Es posible que encuentre que algunas suposiciones eran erróneas o que algunas tareas resultaron ser más fáciles o más difíciles de lo esperado. Ajuste el plan para las próximas fases en consecuencia, como agregar, combinar o repriorizar fases. El enfoque por fases está diseñado para ser flexible. Lo importante no es intentar hacer todo a la vez.
Plan de gobernanza para la modernización
La modernización suele introducir cambios significativos en las cargas de trabajo críticas, por lo que se necesita una gobernanza sólida para administrar los riesgos. La gobernanza de la modernización implica procesos de gestión del cambio, congelaciones y control del alcance.
Establezca un flujo de trabajo de aprobación de cambios formal. Defina un proceso de aprobación estructurado para todos los cambios relacionados con la modernización. Integre con los paneles de asesoramiento de cambios (CAB) existentes o cree un panel de revisión de modernización dedicado. Asigne la autoridad de aprobación en función de la categoría de cambio y documente el flujo de trabajo completo en el plan del proyecto. Para obtener más información, consulte Administración de cambios.
Bloquear los cambios cuando sea necesario. Justo antes y durante las principales acciones de implementación, congela otros cambios en esas cargas de trabajo. Una congelación de cambios significa que no se realizan otros cambios no relacionados con esas cargas de trabajo en la preparación y durante la implementación. Estabiliza el entorno para que no estés apuntando a un objetivo móvil. Comunique la ventana de congelamiento a todos los equipos relevantes.
Evite el crecimiento descontrolado del alcance. La ampliación del alcance es un desafío importante en las modernizaciones. Requerir cualquier cambio propuesto en el ámbito de modernización acordado para pasar por un paso de evaluación y aprobación. La mayoría de las solicitudes deben aplazarse a menos que sean cruciales. Formalice el "no, no ahora" con un proceso para gestionar el trabajo adicional. Mantener una acumulación de ideas deseables que surgen, que pueden integrarse en un proyecto de innovación futuro una vez que se complete la modernización actual. Las partes interesadas deben saber que su idea no se pierde.
Definición de la estrategia de implementación
Una decisión crucial de ejecución es cómo implementar los componentes modernizados en producción. Hay dos estrategias principales. En una implementación in situ, actualizará la configuración existente (como renovando una casa mientras habita en ella). En una implementación paralela, se construye una nueva configuración al lado, como si se construyera una nueva casa y luego se muda. Elija la estrategia que se ajuste al nivel de cambio y tolerancia a riesgos para cada fase o carga de trabajo. A menudo, cada fase de modernización podría usar una estrategia diferente. Por ejemplo, puede elegir in-situ para la fase 1 (si es un cambio menor) y paralelo para la fase 2 (si esto implica una restructuración importante de la base de datos).
Use la implementación local para cambios reversibles y de bajo riesgo. La implementación local introduce cambios directamente en el entorno de producción actual, quizás durante una ventana de mantenimiento. Esta estrategia minimiza la sobrecarga de la infraestructura, pero aumenta el riesgo de tiempo de inactividad. Use la implementación local solo cuando los cambios sean pequeños, aislados y fácilmente reversibles. Algunos ejemplos son las actualizaciones de código secundarias o los cambios de esquema que se pueden revertir rápidamente mediante el control de código fuente o las copias de seguridad.
Use la implementación paralela para cambios complejos o de alto riesgo. En este modelo, configurará un nuevo entorno para la carga de trabajo modernizada mientras se ejecuta la carga de trabajo anterior. Los datos se mantienen sincronizados (a través de procesos de replicación o migración) para que, cuando esté listo, pueda pasar del antiguo al nuevo entorno. Use para cambios complejos o de alto riesgo en los que el tiempo de inactividad debe ser mínimo. Si va a realizar una migración de base de datos importante o una rearquitectura que implique nueva infraestructura, trabajar en paralelo suele ser la forma habitual. Además, si la carga de trabajo es crítica para la misión y no puede permitirse más de unos minutos de tiempo de inactividad, resulta necesario implementar una solución en paralelo (con replicación y conmutación rápida).
Strategy Description Cuándo usar Pros Cons Implementación local Implementación de cambios directamente en el entorno de producción actual Cambios pequeños y reversibles con ventanas de mantenimiento aceptables Ninguna infraestructura duplicada, implementación más rápida Mayor riesgo, requiere tiempo de inactividad, reversión más lenta Implementación paralela Ejecuta un nuevo entorno junto a la carga de trabajo existente durante la transición Cambios complejos, cargas de trabajo críticas que requieren un tiempo de inactividad mínimo Implementación más segura, tiempo de inactividad casi nulo, retroceso inmediato Costos de infraestructura duplicados, sincronización de datos complejos, esfuerzo de retirada
Planear la mitigación de los riesgos de modernización
Incluso con la mejor planificación y pruebas, no todos los cambios van perfectamente. La modernización suele implicar cambios complejos y siempre hay un riesgo de que una implementación pueda presentar un problema o que algo se comporte inesperadamente en producción. La marca de un equipo bien preparado es tener un plan de reversión sólido para cada cambio o fase.
Use técnicas de implementación progresivas. Si la plataforma lo permite, realice versiones controladas o cambie el tráfico gradual a partes modernizadas de la aplicación. Por ejemplo, implemente la nueva versión junto con la antigua e inicialmente envíe solo 5% de usuarios a ella durante la supervisión. Este enfoque puede detectar problemas mientras que la mayoría de los usuarios no se ven afectados. Si las métricas son correctas, aumente al 50% y luego al 100%. Si algo empieza a fallar, redirija rápidamente a la configuración anterior (restauración).
Cree procedimientos de reversión para cada cambio importante. Para cada cambio importante o entrega de fase, escriba un procedimiento de reversión paso a paso. Enumera claramente cada acción para deshacer el cambio, quién es responsable de cada paso y cuánto tiempo tardaría. Después de la reversión, incluya qué comprobaciones confirman que las cosas vuelven a ser normales.
Automatizar las reversiones siempre que sea posible. Los scripts de reversión automatizados o la infraestructura como código pueden hacer que la recuperación sea rápida y confiable. Use herramientas de infraestructura como código (Terraform, plantilla de ARM, Bicep) para volver a implementar estados correctos conocidos. Las implementaciones azul-verde o canarias permiten de forma inherente "revertir" a la versión anterior si es necesario. Pruebe estos mecanismos en el entorno de pruebas. El objetivo es reducir el esfuerzo manual (a las 3 de la mañana durante un incidente) a una acción automatizada. Escriba los pasos de reversión junto con los pasos de implementación, por lo que es fácil revertir.
Tener soporte disponible durante y después de la implementación. Planee las implementaciones durante períodos de tráfico bajo (fines de semana o noche) siempre que sea posible, pero asegúrese de que los expertos pertinentes estén disponibles. No lo hagas cuando los miembros clave del equipo estén de vacaciones. Tenga un período de soporte extendido (hypercare) justo después de la implementación con desarrolladores y operaciones en espera para detectar cualquier problema al principio. Para los principales lanzamientos, algunas organizaciones tienen una supervisión intensiva de estilo sala de guerra durante 24-48 horas después.
Protección de la aprobación de las partes interesadas
Hasta este punto, nos centramos en la planificación técnica. Igualmente importante es obtener el apoyo de las partes interesadas, tanto del liderazgo técnico como del empresarial. La modernización a menudo requiere una inversión significativa, por lo que debe presentar un caso atractivo y mantener a las partes interesadas comprometidas a lo largo de todo.
Adapte la propuesta de valor a cada audiencia. Las distintas partes interesadas se preocupan por los distintos resultados. Personalice la mensajería:
- Los equipos técnicos priorizan la eficacia operativa: mantenimiento reducido, tiempo de actividad mejorado y menos escalaciones.
- Los líderes empresariales se centran en los resultados: un tiempo de comercialización más rápido, una experiencia de cliente mejorada y un ahorro de costos.
Documente un plan estructurado con hitos. Las partes interesadas son más cómodas si ven una hoja de ruta clara. Presente las fases que planeó, como se decidió anteriormente, y lo que cada uno debe lograr, con una escala de tiempo aproximada. Resalte las primeras victorias, como "Dentro de 6 semanas, queremos modernizar el componente X y mejorar su rendimiento en 20%".
Cuantificar el valor de modernización. Prepárese con algunas métricas de antes y después y mejoras objetivo. Algunos ejemplos de métricas y intervalos de mejora típicos (basados en pruebas comparativas del sector) son:
Category Métricas de ejemplo Intervalo de valores típico Reducción de costos Infraestructura, mantenimiento, licencias 20-40% ahorro anual Incrementos de productividad Frecuencia de implementación, tiempo de resolución Mejora de 50 a 80% Mitigación de riesgos Se ha evitado el tiempo de inactividad, los incidentes de seguridad Evitación de costos de $100 000-$1M+ Revenue Tiempo de comercialización más rápido, retención de clientes Aceleración de ingresos de 10 a 25% Abordar los riesgos del proyecto. Identificar posibles desafíos y demostrar la preparación mediante estrategias de mitigación específicas. Entre los riesgos comunes se incluyen la replicación de datos, la degradación del rendimiento y los problemas de integración. Presenta soluciones como procedimientos de reversión automatizados, protocolos de prueba completos y disponibilidad de consultas expertas. La discusión de riesgos transparente crea confianza de las partes interesadas en el liderazgo del proyecto y la profundidad de la planificación.
Mantener la cadencia de comunicación normal. Informe del progreso con los criterios de éxito definidos, resalte los resultados completados y comunique los próximos hitos. Solicite comentarios activamente y solucione los problemas para mantener el soporte técnico a lo largo del proceso de modernización.