Recorrido por su transición a la nube

Cualquier proceso de transformación en la nube que incluya la migración de aplicaciones será complejo. Sin embargo, entre toda esta complejidad, hay algunos destinos claramente definidos en la transición a la nube. Uno de esos destinos implica qué tan "lista para la nube" debe estar la aplicación de destino. ¿Qué tan preparada para la nube desea/necesita que esté la aplicación para trasladarse a la nube en el período de tiempo deseado? A lo largo de este documento, describiremos algunos de estos destinos y haremos énfasis en las prácticas recomendadas y lecciones aprendidas en base a nuestro recorrido. La clave del éxito es definir con claridad los objetivos de su migración por adelantado, de forma que pueda realizar decisiones óptimas acerca de cómo alcanzarlos. Se encontrará con muchos caminos potenciales. Durante el transcurso de su migración, los desarrolladores, los equipos de entrega y los ejecutivos deberán evaluar y tomar muchas decisiones sobre cómo proceder.

Recomendamos centrarse en los siguientes impulsores técnicos y comerciales para enmarcar las decisiones que debe tomar para alcanzar sus objetivos comerciales.

Escalabilidad

Los servicios en la nube proporcionan potencia de procesamiento a escala, mucho más allá de lo que es posible para la infraestructura gestionada, lo que permite que su negocio crezca a fin de abordar las oportunidades del mercado. Infrastructure-as-a-Service (IaaS) y Platform-as-a-Service (PaaS) basadas en la nube permiten a los ISV centrarse en la creación de arquitecturas escalables mediante el uso de componentes modernos. Un beneficio adicional de la migración es que, mediante la liberación de los equipos de desarrollo internos de la gestión y el escalamiento de las operaciones de TI, el enfoque se puede dirigir al ajuste y la optimización del rendimiento.

Modernización

La modernización de los conjuntos de herramientas, los servicios y las arquitecturas facilita la integración entre componentes, lo que ayuda a que las aplicaciones obtengan el valor total de las herramientas y las tecnologías disponibles en la nube. Estas herramientas incluyen desde actualizaciones de infraestructura hasta canalizaciones de implementación automatizadas y modelos integrados de aprendizaje autónomo que mejoran el rendimiento de las aplicaciones. La modernización es más importante cuando los mercados experimentan cambios rápidos y consistentes, ya que las aplicaciones deben ser dinámicas para mantenerse al ritmo. En algunos casos, puede que se vuelvan a escribir los servicios por completo y se cambie su nombre, y se aproveche la última tecnología para ofrecer costos más bajos u opciones de servicio más optimizadas. Mediante estos cambios, se pueden renovar los productos antiguos e interrumpir los mercados establecidos en los que las ofertas con licencia son la norma. En otros casos, puede que se revisen los productos con enfoques nuevo y se mejore el servicio, a la vez que se preserva el reconocimiento de la marca y la lealtad de los clientes. Para hacer esto, no es necesario realizar un cambio completo del paquete de productos.

La transición a la nube se convierte en el detonante de un impulso de modernización generalizado. A medida que la nube le brinde a usted y a sus equipos acceso a servicios, tecnologías y experiencia que antes no estaban disponibles en su organización, se volverá posible lograr objetivos nuevos y brindar capacidades nuevas. Tus equipos pueden pasar a “niveles más altos del entorno” para centrarse en características nuevas y de aplicación general de los productos, en lugar de en código personalizado vinculado a implementaciones específicas en distintos clientes. Debido a que el aprovisionamiento de servicios, las actualizaciones de productos y la asistencia al cliente se realizan más rápido que nunca, los recursos se pueden redirigir al desarrollo de nuevas funciones. De esta manera, la migración a la nube sienta las bases para una extensa ola de actividades de modernización y así se transforma todo, desde la ejecución de actualizaciones de productos hasta la calidad del servicio al cliente.

---

"La migración a Gen2 Cloud permitió a Oracle garantizar la entrega exitosa de sus servicios a través de un modelo sólido de DevSecOps y le permitió respaldar las transformaciones comerciales de sus clientes. Ahora, lanzamos software a diario y reducimos el tiempo de aprovisionamiento en más del 98 %." — Karthic Murali, director principal sénior de estrategia de productos de las unidades de negocio globales de Oracle

---

Estandarización

La estandarización en IaaS y PaaS le permite reducir los costos generales y hacer que los equipos sean más flexibles y fungibles. A medida que las organizaciones crecen, sus equipos adoptarán herramientas de varios niveles de madurez. La consolidación de estos conjuntos de herramientas dentro del servicio en la nube remueve gran parte de la complejidad asociada con esta capa de la administración de TI. Permite el desarrollo y el uso de prácticas operativas estándar para tareas que se pueden asignar en toda la cartera de productos. La estandarización también hace que las actividades de rutina sean más simples y predecibles, lo que reduce la demanda de mano de obra para tareas básicas. Los recursos que antes se dedicaban a la navegación por procesos variados y posiblemente incompatibles entre aplicaciones ahora se liberan para centrarse en problemas más importantes, que incluyen el desarrollo de productos y servicios de próxima generación para los clientes.

En particular, la estandarización simplifica la aplicación de políticas y prácticas globales en torno a la seguridad, los riesgos, el cumplimiento y otras actividades operativas que sus equipos puedan aplicar con facilidad a productos nuevos y existentes. De hecho, la aplicación puede heredar muchas de las capacidades intrínsecas de la plataforma de IaaS, como las certificaciones de cumplimiento acreditadas.

Optimización de ingresos

La optimización de ingresos se puede lograr de dos formas principales. La primera forma, que es la más obvia, son las reducciones de costos. La eliminación de los centros de datos mediante el uso de IaaS no solo cambia el modelo financiero de CapEx a OpEx, sino que también suele generar ahorros significativos de TCO. Lo que puede que no sea tan obvio son los ahorros de costos que se logran mediante la racionalización del paquete de tecnología que se utilizó en una cartera de aplicaciones que se migraron a la nube. Los conjuntos de herramientas comunes crean conocimiento institucional y eliminan los gastos asociados con la capacitación ad hoc para herramientas no estandarizadas. En este sentido, los conjuntos de herramientas comunes que tratan la infraestructura como código proporcionan una automatización que, en última instancia, ahorra tiempo y costos laborales. Por último, los equipos especializados en áreas fundamentales que se aplican en toda la cartera, como la seguridad, eliminan la necesidad de crear expertos dentro del equipo de cada producto individual.

En segundo lugar, la transición a la nube puede, en última instancia, optimizar los ingresos al ayudarlo a llegar al mercado con mayor rapidez, ya que los plazos de desarrollo de los productos se suelen acortar una vez que una aplicación está lista para la nube o es nativa de la nube. Llegar al mercado mayor rapidez implica una obtención más rápida de ingresos. Una vez que una aplicación está lista para la nube, se puede implementar en cualquier lugar del mundo en cuestión de minutos.

En combinación, los principios analizados deberían dar como resultado arquitecturas estandarizadas de productos y servicios, así como una velocidad y una calidad mayores de implementación. Escale los resultados a partir del diseño para obtener patrones repetidos, lo que contribuye a la optimización de los ingresos, a un tiempo más rápido de generación de valor y a la capacidad resultante de volver a destinar los recursos para mejorar la calidad y la integridad del servicio para los clientes.

---

WorkForce Software migra su solución de gestión del personal a Oracle Cloud Infrastructure y logra un aumento del 30 % en el rendimiento.

"Observamos un rendimiento financiero que, de inmediato, nos permitió ahorrar entre un 30 % y un 35 % en nuestros gastos de CapEx, y gracias al excelente rendimiento que obtenemos de OCI, el ROI que ofrecemos con nuestra suite mejora cada vez más." —Mike Morini, director ejecutivo de WorkForce Software

Más información

---

Caminos para obtener un valor en la nube

La computación en la nube puede incluir una variedad de recursos de IaaS y PaaS, así como varios modelos de implementación de software, que van desde el acceso a instancias de hardware hasta entornos integrados en contenedores y paquetes de servicios completamente funcionales. En el nivel más básico, la computación en la nube se refiere al reemplazo de componentes de la infraestructura física por recursos básicos de IaaS.

La mayoría de las aplicaciones empresariales no se crearon en un principio para la nube. En el caso de muchas aplicaciones, pasarse a la nube o adaptarse a los patrones de la nube requiere mucho tiempo y es difícil. El cambio de plataforma puede resultar caro desde el punto de vista del tiempo y del trabajo, por lo que no es sorprendente que a veces sea más fácil diseñar desde cero para los entornos principales nativos de la nube. Por ello, las empresas se suelen encontrar en uno de tres escenarios principales cuando consideran realizar una migración a la nube.

• Salir de los centros de datos heredados: Ejecutar un centro de datos es costoso. Los edificios, las personas, la energía, la refrigeración, el mantenimiento y las actualizaciones son solo algunas de las responsabilidades de todos los días. Muchas empresas trabajan de forma activa para reducir o eliminar su dependencia del centro de datos mediante la evaluación de carteras de aplicaciones para que los candidatos se trasladen fuera de las instalaciones. La prioridad es trasladar las aplicaciones fuera de los centros de datos locales o de hospedaje administrado que se encuentran en ubicación conjunta en un esfuerzo por reducir o eliminar los gastos de capital. A menudo, se utiliza una estrategia de elevación y cambio mediante la cual la aplicación se migra tal cual está a un servidor de hardware o a una máquina virtual en la nube.
• Evolución del paquete de tecnología: En este caso, las empresas comienzan a realizar cambios incrementales en las aplicaciones que, con el tiempo, requerirán una inversión adicional, pero que también se espera que aporten más valor. Un ejemplo de esto sería reemplazar las versiones locales de Oracle Database por Oracle Autonomous Database basada en la nube sin realizar cambios importantes en la aplicación en sí. Esto a veces se denomina estrategia de trasladar y mejorar.
• Traslado completo a un entorno nativo de la nube: Los beneficios de rediseñar una aplicación desde cero para que esté lista para la nube pueden superar los costos de mantener intacta una aplicación menos madura al implementar uno de los escenarios ya mencionados. Las aplicaciones nativas de la nube se encuentran muy distribuidas por naturaleza (a menudo se diseñan mediante el uso de principios de 12 factores) y, por lo tanto, están diseñadas para ser independientes de la arquitectura subyacente, lo que significa que las aplicaciones continúan ejecutándose incluso cuando la infraestructura subyacente se rompe. En resumen, vale la pena evaluar si este camino sería el adecuado para la aplicación de destino, ya que el traslado a la nube será sin duda más sencillo que trasladar una aplicación que está unida de forma estrecha a su infraestructura subyacente.

Para conocer de qué manera Oracle define nativo de la nube, los orígenes de las aplicaciones nativas de la nube y las prácticas recomendadas a seguir al diseñarlas, lea este libro electrónico.

---

Otra forma de visualizar estos escenarios es analizar el espectro de acciones que podría realizar para que una aplicación empresarial se acerque más a una arquitectura nativa de la nube mientras la traslada a Oracle Cloud Infrastructure. Consulte la Figura 1 a continuación.

Figura 1: Niveles de inversión y cambios en la migración a la nube

El lado izquierdo de la Figura 1 representa la menor cantidad de cambios, el menor tiempo necesario para generar un valor y la menor inversión inicial. Por lo general, el nivel de los cambios, la inversión y el tiempo aumenta a medida que se mueve hacia la derecha, pero el valor obtenido también es mayor. Este modelo lo ayuda a formular una manera de predecir qué tipo de inversiones considerar realizar durante la fase de traslado. Tenga en cuenta que los escenarios no necesariamente se logran diferenciar y se superponen un poco, ya que las aplicaciones se diseñan de muchas formas.

Los escenarios descritos se convierten en puntos de referencia clave para evaluar los niveles de madurez existentes y los objetivos de transición a la nube. La brecha entre su estado actual y el estado de destino brinda una estimación aproximada del alcance del cambio técnico y de procesos necesario para la transición a la nube. En un mundo perfecto, la transición a la nube debería dar como resultado la transición de todas las aplicaciones a modelos de entrega nativos de la nube. Sin embargo, debido a las limitaciones de tiempo y recursos, pocas organizaciones están en condiciones de realizar la transición de toda su cartera a un modelo nativo de la nube en un solo proceso. Incluso los esfuerzos simples de cambiar de plataforma pueden consumir muchos recursos y requerir inversiones significativas tan solo para replicar las capacidades heredadas.

Por lo tanto, la transición a la nube es una cuestión de identificar las soluciones intermedias entre el nivel óptimo de madurez de la nube (en el que las aplicaciones se encuentran alojadas en la nube en el continuo nativo de la nube que se mostró antes) y la inversión en ingeniería necesaria para rediseñar el producto y sus procesos empresariales asociados. En esta etapa, el paso clave es identificar los niveles de madurez actuales y de destino de cada aplicación con una estimación aproximada de la inversión en desarrollo necesaria para subsanar la brecha.

Las aplicaciones que cambian los niveles de madurez durante la migración también deben cambiar las expectativas y los patrones operativos. El cambio en los niveles de madurez afecta a los equipos, los procesos y las políticas que respaldan el servicio.

 

Evaluación de la preparación técnica para la nube

Es esencial contar con una comprensión técnica de la aplicación de destino, o de toda la cartera de aplicaciones para empresas que ofrecen varias aplicaciones basadas en SaaS, a fin de entender los requisitos y las dependencias de la migración. En esta etapa, el área clave de enfoque debe ser identificar las capacidades que requiere la aplicación y cómo se relacionan con estas dependencias. Esto impulsará los plazos relativos de las actividades de migración y ayudará a identificar las áreas clave de enfoque. La evaluación debe abordar tres dimensiones críticas.

1. Requisitos de infraestructura: La nube desasocia el software de su hardware o sus entornos operativos subyacentes. Las aplicaciones con un alto nivel de madurez son, en esencia, independientes de su entorno y dependen solo de un recurso de infraestructura general, como una CPU o un clúster de Kubernetes, que se escala con facilidad en la nube. Las aplicaciones con un bajo nivel de madurez dependen de equipos, componentes o entornos específicos proporcionados, como una infraestructura gestionada u otros sistemas dedicados. El grado de dependencias estrictas de la configuración y los componentes de la infraestructura en la nube que tendrá su aplicación se debe, primero, documentar y, en última instancia, eliminar. No es inusual encontrarse con personalizaciones (realizadas por usted o por sus clientes) que están vinculadas o asociadas a la infraestructura subyacente.
2. Componentes de los servicios: La nube ofrece capacidades de soporte como servicios independientes que se operan y ofrecen de forma independiente de la aplicación. Las aplicaciones con un nivel alto de madurez están diseñadas en torno a componentes diferenciados con dependencias mínimas en el paquete, lo que permite realizar cambios y actualizaciones específicos y maximiza el tiempo de actividad. Las aplicaciones con un nivel bajo de madurez están diseñadas con componentes grandes, asociados de forma estrecha, que se vuelven muy interdependientes y se deben administrar como una sola entidad. Estas relaciones de servicios se deben documentar para cada aplicación.
3. Preparación operacional: La nube cambia las arquitecturas técnicas, así como los procesos de trabajo, los conjuntos de habilidades, las herramientas disponibles y los modelos en funcionamiento. Las aplicaciones con un nivel alto de madurez ya se ejecutan como aplicaciones en la nube y utilizan procesos, estándares y conjuntos de herramientas que funcionarán bien en la nube. Las aplicaciones con un bajo nivel de madurez encontrarán que les faltan servicios de soporte esenciales en la nube, contarán con equipos que les brindarán apoyo con conjuntos de habilidades inadecuadas para el trabajo en la nube o utilizarán procesos que se interrumpirían si se cambia a la nube.

Comenzar una migración mediante una evaluación de la madurez de una aplicación con respecto a estos factores le permite planificar de forma adecuada y evitar sorpresas posteriores que generen retrasos, aumenten los costos y provoquen que no se cumplan los objetivos. Es difícil subestimar la complejidad de una migración, ya que los entornos de producción, los conjuntos de servicios de soporte y el entorno de nube objetivo actuales seguirán evolucionando a lo largo del proceso. Develar los vínculos entre los servicios y las aplicaciones no solo permite realizar una planificación inteligente inicial, sino que también permite que la planificación responda de forma flexible a los cambios que es inevitable que ocurran durante la migración. Si se documenta de forma eficaz, esta evaluación debería dar como resultado una lista clara de tareas pendientes para el proceso de migración. Esto ayudará a garantizar que los cronogramas de migración previstos sigan estando en consonancia con las hojas de ruta que cambian de forma constante.

---

Zoom escala y activa con rapidez millones de reuniones simultáneas en Oracle Cloud Infrastructure.

"De forma reciente, experimentamos el crecimiento más significativo que jamás haya experimentado nuestro negocio y requerimos incrementos masivos en la capacidad de nuestro servicio. Exploramos varias plataformas y Oracle Cloud Infrastructure fue fundamental para ayudarnos a escalar con rapidez nuestra capacidad y cumplir con las necesidades de nuestros usuarios nuevos." — Eric S. Yuan, director ejecutivo de Zoom

Más información

---

Objetivos financieros

Como ocurre con cualquier iniciativa de TI, la transición a la nube requiere una serie de inversiones para lograr su valor total, en especial si la aplicación objetivo se creó para un modelo de alojamiento local. Las aplicaciones que se consideren dignas de trasladarse a la nube con el tiempo se convertirán en nativas de la nube o se descontinuarán. Sin embargo, el objetivo inicial suele ser llevar una aplicación a un estado de lanzamiento en la nube.

Lo que se necesita para que la aplicación pase de su estado actual a un estado de lanzamiento en la nube es producto de una serie de decisiones e inversiones iniciales. ¿Planea solo elevar y trasladar la aplicación a un servidor de hardware (en cuyo caso, la mayor parte de la inversión se realiza en infraestructura en la nube) o planea hacer que la aplicación esté lista para la nube antes de realizar la transición (en cuyo caso, Se requerirá que parte de la inversión se destine a trasladar partes del paquete de aplicaciones a un modelo basado en la nube y, por ejemplo, trasladar la base de datos de las instalaciones locales a DBaaS u Oracle Autonomous Database)? Si creó personalizaciones con codificación fija para habilitar las capacidades específicas del cliente, se deberán rediseñar para un modelo en el que los componentes de la plataforma se encapsulen y entreguen a través de API como características desarrolladas. Las dependencias de plataforma o de hardware se deberán eliminar para poder escalar una aplicación muy distribuida en la nube. Comprender estas inversiones es un factor esencial para planificar y lograr los objetivos financieros asociados con la transición a la nube.

En la inversión inicial, se incluye el tiempo de desarrollo y la mano de obra necesarios para realizar los cambios necesarios en el producto asociados con la etapa de migración a la nube que acabamos de analizar. Sin embargo, también se deben tener en cuenta los gastos adicionales. Entre una amplia serie de gastos que es probable que contraiga su organización durante la transición, se incluyen los siguientes:

• Inversión en desarrollo: Es la mano de obra de desarrollo necesaria para rediseñar el producto o crear aceleradores para el esfuerzo de migración, incluida la automatización necesaria a fin de respaldar actividades como la migración de bases de datos y el aprovisionamiento de aplicaciones.
• Ejecución de la migración: Son los recursos de la mano de obra necesarios para aprovisionar activos nuevos, migrar entornos y datos existentes, y retirar del servicio los inventarios heredados.
• Incorporación de infraestructura: Son las tarifas de suscripción acumuladas a través de la rampa de IaaS, que pasará a un estado estable, pero representará nuevos aumentos durante el período de migración.
• Infraestructura abandonada: Son los costos de depreciación de CapEx y del centro de datos pendientes que se acumulan a través de los esfuerzos de migración hasta que se puedan eliminar o descartar.
• Transición del personal: Son los gastos asociados con la capacitación, la formación o la reestructuración de los equipos existentes o los gastos de la adquisición de recursos nuevos con los conjuntos de habilidades necesarios para la nube.
• Transición del cliente: Son los costos asociados con los cambios en las características del entorno o los términos del servicio que no se pueden respaldar en el modelo nuevo, incluidos el desarrollo nuevo, los incentivos, la renegociación de los artículos del contrato o la pérdida de clientes.

En mayor o menor medida, cada uno de estos costos es un componente necesario de la transición a IaaS. Cada uno impacta su perfil de costos de una manera diferente. Puede que los gastos de inversión en desarrollo y de ejecución de la migración, por ejemplo, se generen en depósitos de un solo uso, incluso aunque los recursos asociados con este trabajo sean fijos. La incorporación de infraestructura nueva dará como resultado un aumento neto de los gastos durante un periodo hasta que se eliminen los gastos de la infraestructura abandonada. Una parte de los gastos de transición del personal y el cliente, como los incentivos de capacitación o migración, representarán gastos que se generarán una sola vez. Es posible que otros gastos, como las expansiones del personal o los cambios en los contratos con los clientes, generen nuevos gastos continuos.

Comprender cómo se desarrollarán estas dinámicas a lo largo del tiempo es esencial a fin de que la organización se prepare y establezca expectativas para la transición a la nube. Si en su organización se muestra entusiasmo por los beneficios considerable de la nube, pero no se comprende de forma clara el riesgo de la transición, se sorprenderá ante los aumentos iniciales de los gastos durante las primeras etapas, en especial a medida que asimile los costos iniciales de la migración, la infraestructura superpuesta y la transición. Establecer una expectativa adecuada y mantener la visibilidad del progreso incremental a medida que ocurre son elementos fundamentales para mantener la convergencia y la disciplina a medida que la organización avanza en el proceso de transición.

Inventario de migración a la nube

Un inventario de migración a la nube es imprescindible para realizar la transición a la nube. ¿Qué es un inventario de migración a la nube? En resumen, es una lista de todos los activos de la flota y de los elementos asociados de datos críticos que describen cada activo. Son las aplicaciones objetivo que se desean trasladar y todas sus dependencias. El medio utilizado para capturar estos datos es irrelevante y no es inusual que se utilicen varias herramientas, ya que a menudo los datos abarcan departamentos enteros dentro de una empresa. Por lo general, la información requerida se encuentra dispersa en una variedad de bases de datos operativas, de producción y de ventas. Por ejemplo, una base de datos de gestión de la configuración puede rastrear en detalle las dependencias técnicas y la ubicación de los activos, hasta llegar a los servidores físicos y las ubicaciones de los bastidores. Sin embargo, en la búsqueda no se incluirán las consideraciones de la empresa y del cliente, que son vitales para determinar cuándo y cómo se notificará a los clientes sobre la transición. Esta información suele estar contenida en repositorios diseñados para las operaciones y para proporcionar soporte a las partes interesadas. Además, las adquisiciones, los casos de uso especiales y los silos de productos pueden indicar que la información se encuentra fragmentada en mayor medida en varios repositorios.

El objetivo clave del inventario de migración es proporcionar una vista centralizada de los factores que necesita para administrar la transición a la nube. Por ejemplo: ¿Cuál es el activo? ¿Dónde se encuentra? ¿Con qué producto es compatible? ¿Qué hace? ¿Con qué clientes es compatible?

Desde el inicio, es importante darse cuenta de que el plano es un documento vivo. Debe ser flexible, ya que evolucionará con el tiempo, en especial en las empresas con varias aplicaciones o varias versiones de las aplicaciones. El inventario evolucionará a medida que surjan problemas nuevos y se descubran necesidades nuevas. Incluso la infraestructura de nube subyacente puede cambiar durante el transcurso de una migración, lo que hace que el inventario siga evolucionando. El inventario de migración capturará tantos datos disponibles como sea posible (lo que le permitirá comenzar la planificación inicial) y, luego, agregará capas de detalles a medida que en la transición surjan requisitos nuevos.

La gestión del inventario de migración es un proyecto multifuncional en sí mismo que debe equilibrar la necesidad de datos detallados con el trabajo de recopilarlos. También incluye elementos que identifican dependencias, limitaciones y recursos, que tendrán un impacto en los plazos y la velocidad, como las especificaciones técnicas detalladas, los enfoques de la arquitectura, los requisitos del cliente y las vías de transferencia de datos. Si hay muy poca información, el inventario no será útil. Si hay demasiada, se convertirá en una carga que mantener, que puede quedar obsoleta y caer en desuso con rapidez.

Recomendamos utilizar el siguiente marco de inventario de migración como punto de partida para la migración a la nube.

De un inventario de migración a un inventario operativo

Si bien nos centramos en el inventario de migración, en última instancia, la transición a la nube presenta dos desafíos. De forma más directa, crea la necesidad de planificar, priorizar y rastrear las actividades de migración. Sin embargo, la migración en sí misma obligará a realizar cambios en los datos necesarios para el seguimiento operativo diario. Por ejemplo, los detalles de configuración posteriores a la migración acerca de los bastidores y los servidores físicos serán irrelevantes, incluso la información acerca de las instancias individuales perderá importancia. A la vez, las métricas como el uso general y la salida de datos se pueden volver críticas, en particular a medida que las organizaciones adoptan modelos de autoservicio.

La creación de un inventario de migración debería iniciar la transición a estos nuevos procesos y esquemas de datos centrados en la nube. Si bien los desafíos relacionados de crear el inventario y migrar la aplicación son proyectos independientes, no deben emprender por separado. El esfuerzo de migración es el esfuerzo principal y puede que sea la primera vez que una organización cree una vista detallada y consolidada de sus activos. Es un momento de transformación que debería constituir la plantilla para las vistas nuevas del inventario posteriores a la migración. Como se mencionó antes, el inventario de migración deberá ser flexible y adaptable. Si se gestiona de forma adecuada, el inventario de migración evolucionará hasta convertirse en una valiosa herramienta de gestión de inventarios posterior a la migración.

Al volante de su recorrido hacia la nube

Diseño de la infraestructura para alojar aplicaciones de SaaS

Como un ISV que proporciona aplicaciones basadas en SaaS, necesita una infraestructura segura, escalable y de nivel empresarial para alojar sus servicios y gestionar a sus clientes por separado. La arquitectura de referencia que se muestra a continuación en la Figura 3 proporciona un marco validado en el que se incorporan las prácticas recomendadas, lo que le permite alojar sus aplicaciones de SaaS en Oracle Cloud Infrastructure.

En esta arquitectura de referencia, debe implementar y administrar varias instancias aisladas de aplicaciones. Cada implementación se realiza para un usuario específico y estas instancias de aplicaciones de usuarios individuales se administran a través de una capa de gestión en común.

Puede optar por crear todas las instancias de aplicaciones de usuarios a partir de una única base de código u ofrecer versiones personalizadas de la aplicación a cada usuario. Este patrón es ideal para los clientes de SaaS que requieren un aislamiento completo del entorno de la aplicación.

Figura 3: Una arquitectura de referencia de prácticas recomendadas para aplicaciones de SaaS en OCI

Para obtener más detalles sobre la arquitectura de referencia anterior, visite Oracle Architecture Center. Además, creamos herramientas basadas en Terraform para ayudar en la implementación de la arquitectura para cuatro usuarios, junto con una guía paso a paso. Por último, siempre recomendamos seguir la guía de prácticas recomendadas de Oracle Cloud Infrastructure, en la que se brinda orientación para cuatro objetivos comerciales comunes: la seguridad y el cumplimiento, la confiabilidad y la resiliencia, la optimización del rendimiento y los costos, y la eficiencia operativa.

Además de los cambios en la arquitectura, debe pensar en cómo cambiará su paquete de servicios en la nube. Los conjuntos principales de herramientas utilizados para la supervisión, la administración de redes o la seguridad que se implementan en entornos heredados desarrollados para arquitecturas locales evolucionarán para la nube. La transición a la nube brinda la oportunidad de ampliar el alcance de los problemas que abordan estas herramientas. En lugar de supervisar ante todo los puntos finales, las herramientas basadas en la nube ofrecen una supervisión de todo el paquete. A veces, un proveedor de servicios en la nube ofrecerá herramientas de supervisión basadas en la nube o en entornos híbridos, además de las capacidades básicas. En el caso de Oracle Cloud Infrastructure, una combinación de capacidades nativas de supervisión, etiquetado y auditoría brinda la capacidad de supervisar el paquete completo de servicios y, a menudo, corregir de forma automática las anomalías que se encuentran fuera de las normas especificadas. Si en este momento utiliza herramientas de supervisión de terceros en las instalaciones, puede que estos proveedores también ofrezcan herramientas basadas en la nube o en entornos híbridos.

---

Cisco Tetration traslada su aplicación principal a Oracle Cloud Infrastructure y logra aumentar 60 veces el rendimiento.

"La asociación con Oracle ha sido magnífica. Es por eso que sucede toda la magia en Cisco Tetration." — Navindra Yadav, fundadora de Cisco Tetration

---

Implementación de su programa piloto

Al igual que con cualquier esfuerzo de ingeniería, comenzar con un programa piloto o un prototipo pequeño maximiza las probabilidades de éxito, ya que proporciona al equipo del piloto y a su organización una idea de lo que se puede hacer y cómo proceder. Los programas piloto y de prueba de concepto identifican desafíos y los resuelven, sin las presiones financieras y de tiempo que conlleva un cambio a gran escala en toda la organización. Al realizar la transición de forma lenta y familiarizarse con el entorno operativo nuevo, los programas piloto pueden ayudarlo a gestionar la tasa de cambio.

El piloto es una oportunidad para que un grupo principal de desarrolladores y personal de operaciones explore el entorno de destino en la nube y conozca las arquitecturas, los servicios y los modelos operativos. Este equipo formula una base de conocimiento práctico, herramientas útiles y prácticas recomendadas, así como confianza, competencias y experiencia. A la vez que el equipo formula este conocimiento, evoluciona las reglas del recorrido para la colaboración entre equipos en un entorno basado en la nube. Para la migración a la nube, es necesario que los equipos de aplicaciones evolucionen de administradores de recursos directos a consumidores de servicios proporcionados por otros equipos. Un piloto permite a los equipos de aplicaciones comprender cómo cambiarán los límites de los servicios, establecer relaciones con los equipos de operaciones que brindan los servicios que utilizarán y aprender cómo defender sus necesidades con estos equipos de operaciones.

Los pilotos brindan los siguientes beneficios:

• Un contexto en el que validar (o cuestionar) los supuestos sobre la portabilidad de las tecnologías, en especial en los casos en los que las tecnologías siempre se ejecutaron en el mismo entorno. Esto ayuda a los equipos a comprender si están listos para realizar la migración e identifica qué se debe cambiar para poder hacerlo.
• Una oportunidad para confirmar la preparación de la aplicación o la base de datos para integrarse con los servicios en el entorno de destino. Esto les indica a los equipos qué cambios se requieren y cuándo la aplicación y el entorno de servicios de destino están listos para que se produzca la migración.
• La capacidad de crear para el entorno de destino, y así crear un punto de apoyo, que se convierte en un punto de partida para el resto de la cartera a medida que se trasladan a servicios y un entorno nuevos. Esto le brinda a los equipos objetivos estratégicos para su cartera.

---

Manhattan Associates migra sus soluciones de cadena de suministros a Oracle Cloud Infrastructure y ahorra un 50 % en costos con respecto a la solución en la nube anterior.

"La versatilidad y la flexibilidad de Oracle Cloud en la capa de la aplicación y de la base de datos dio como resultado un ahorro de aproximadamente el 50 % con respecto a nuestras soluciones en la nube anteriores en términos de infraestructura." — Jeff Demenkow, vicepresidente de Manhattan Associates

---

Gestión de un programa piloto

El piloto es una experiencia de aprendizaje para el personal técnico y operativo, así como para sus equipos ejecutivos y de gestión. Los equipos ejecutivos y de gestión deben comunicarse de forma continua con los equipos del piloto para ayudar a eliminar los obstáculos organizacionales y garantizar que la organización maximice el aprendizaje que surge del proyecto piloto (es decir, qué funcionó, qué falló, las prácticas recomendadas, las lecciones aprendidas, y los patrones estándar o los antipatrones identificados). Esta información valiosa se puede capturar y, luego, compartir con el resto de la organización. Lo ideal es hacer que los proyectos posteriores en la nube sean más efectivos y eficientes. Un piloto permite a la administración probar los supuestos que se utilizaron para formular los planes y aclarar las áreas de incertidumbre. Si bien estos supuestos variarán de una organización a otra, los pilotos logran develar algunos desafíos clave en cualquier migración.

• Capacitación: Los pilotos prueban las habilidades existentes y dejan ver cuán preparada está la organización para el trabajo técnico de la migración. La administración debe utilizar el piloto para evaluar la competencias técnicas, comprender qué herramientas y capacidades es más importantes desarrollar y planificar cómo desarrollar habilidades (o contratarlas) con rapidez en estas áreas clave.
• Colaboración: Los pilotos revelan cómo los equipos operativos, de desarrollo y de soporte trabajarán juntos de forma diferente. La administración debe asegurarse de que estos equipos trabajen juntos en verdad durante el piloto, de forma que expongan requisitos nuevos y desarrollen una comprensión de cómo operar en este entorno nuevo.
• Interés por el cambio: Los pilotos son una oportunidad para encontrar barreras culturales que afectarán la migración generalizada. Un grupo que experimente problemas en un piloto tendrá la misma respuesta a gran escala. El piloto es una oportunidad para que la administración identifique problemas, implemente capacitaciones y ajuste los planes para que se tengan en cuenta las realidades de la organización en particular.

La clave para una migración fluida es crear una base sólida. La primera fase de la migración impulsará el desarrollo de un conjunto esencial de servicios y plataformas, que se expandirán de forma gradual a medida que se avance en el proceso de migración. Con el tiempo, estas capacidades esenciales se deberán ampliar para respaldar la cartera completa de la migración. Como resultado, es esencial que los lanzamientos iniciales en la nube no solo tengan éxito, sino que generen un camino para todos los lanzamientos y las actualizaciones posteriores.

Adaptación al cambio en la organización

Diseño de la infraestructura para alojar aplicaciones de SaaS

Los cambios en el modelo de entrega de su organización y las relaciones con los clientes pueden requerir habilidades, conocimientos, procesos comerciales y mentalidades nuevos. Estos cambios pueden generar un gran impacto en toda la organización, por la que a menudo se dice que el cambio cultural es el aspecto más difícil de la transición a la nube.

El gran alcance de estos cambios puede generar la impresión de que una transición a la nube requiere una reorganización a gran escala y la incorporación de reemplazos de personal con experiencia en la nube y conocimientos sobre esta. Si bien los cambios en la especialización funcional interna y la contratación de personal nuevo que se centra en los conjuntos de habilidades para la nube son componentes importantes de la transición a la nube, no se puede permitir la pérdida de los procesos, las dinámicas y los contribuyentes establecidos que han sido clave para el éxito hasta la fecha. Es fundamental que equilibre la velocidad del cambio en la organización con las posibles interrupciones en las experiencias empresariales y de los clientes actuales. Mantener este equilibrio implica una realineación de los cambios estructurales en torno a las capacidades de desarrollo profesional que permitirán a los empleados existentes realizar la transición al nuevo modelo operativo.

La transición de una empresa antigua de software a modelos de entrega en la nube requiere un gran cambio en los supuestos, los conocimientos técnicos y los procesos operativos estándar en varias áreas comerciales clave. Si bien la cantidad de cambios necesarios puede ser abrumadora, nuestras experiencias sugieren que, en general, es mejor conservar los equipos existentes, e invertir en ellos, que intentar renovar por completo el personal con expertos en la nube. Las organizaciones que planean realizar transiciones similares deben observar cómo nuestra organización de GBU comenzó con una evaluación ascendente descentralizada de las necesidades de cambios, lo que permite que cada equipo cree sus respectivos inventarios de migración y hojas de ruta del paquete de servicios. De esta forma, se identificaron los pasos necesarios en sus respectivas áreas de control. Este enfoque permitió a los equipos hacer que sus programas estén en concordancia con los impulsores de cambios tangibles y, a la vez, evitar realizar supuestos de alto nivel acerca de lo que podrían requerir.

---

8x8 mantiene al mundo conectado, reduce los costos en un 80 % y mejora los servicios mediante la transición a Oracle Cloud Infrastructure.

"A medida que las videoconferencias se convirtieron con rapidez en el la vía de conexión del mundo actual, vimos cómo nuestra cantidad de usuarios se disparó. Para respaldar este crecimiento exponencial, analizamos varias plataformas y elegimos la infraestructura de segunda generación en la nube de Oracle debido a su sólida seguridad, su excelente relación de precio y rendimiento y su soporte de clase mundial a fin de ofrecer nuestros servicios a esta nueva ola de usuarios." — Vik Verma, director ejecutivo de 8x8

Vea el video

---

Impactos empresariales

Una transición exitosa a la nube permite realizar cambios en la organización y se logra mediante estos. La transición de una cartera que en gran medida se encuentra alojada o en las instalaciones locales a una empresa basada en la nube requerirá cambios esenciales en la forma en que la organización se relaciona con sus clientes. Sin embargo, el grado en que cambien las prácticas y los supuestos comerciales establecidos dependerá en gran medida del alcance del cambio en los productos realizado durante la transición a la nube.

Incluso en escenarios en que se produzcan pocos cambios, el cambio a IaaS generará cambios en los procesos empresariales. Nuestras GBU identificaron dos oportunidades de cambio clave en este contexto.

1. Reemplazar la gestión de la infraestructura física que realiza un uso intensivo de CapEx por modelos de pronóstico orientados a OpEx en los que se tengan en cuenta las variaciones a corto plazo y las expectativas a largo plazo.
2. Desarrollar equipos de seguridad y cumplimiento que se hayan liberado de las responsabilidades tradicionales para centrarse en la entrega de componentes de servicios.

Las organizaciones que aborden estos cambios, junto con el cambio técnico en sus aplicaciones, estarán mejor posicionadas para aprovechar todo el potencial de la migración a la nube.

Alineación con el cliente

Pasar de ofrecer un producto "empaquetado", o incluso un producto alojado, a un verdadero servicio en la nube es un proceso que usted y sus clientes emprenderán juntos. De hecho, es este cambio hacia un modelo de producto como servicio lo que diferencia la nube de todas las modalidades de alojamiento anteriores. Cada cambio hacia un servicio en la nube afectará la experiencia del cliente, desde la escalabilidad hasta el tiempo de actividad y la resiliencia. En algunos casos, puede que el cliente solicite, o incluso exija, el cambio hacia un modelo de entrega nuevo. En otros casos, puede que las expectativas de características, capacidades y costos evolucionen de maneras que solo se pueden respaldar mediante una entrega basada en la nube.

A medida que comience a involucrar a sus clientes en sus estrategias para la nube, deberá prepararse para afrontar estos dos puntos de vista: una emoción por la hoja de ruta y una resistencia a dejar lo que le es familiar. Para responder ante estos puntos de vistas, se requiere una comunicación clara y moderada que indique hacia dónde se dirige el esfuerzo sin perderse en los detalles técnicos ni causar sospechas. Es un momento clave para involucrar a los equipos de atención al cliente dentro de su organización a fin de asegurar que comprendan el esfuerzo en curso, la inversión que está realizando la empresa y los resultados esperados para el producto y la entrega. Al hacer esto, sus equipos de atención al cliente se deben alistar para traducir este cambio en términos que fortalezcan la confianza del cliente en el servicio.

Para los clientes que consumirán el servicio en la nube, el escenario se puede tornar un poco más complicado. Hay segmentos de clientes que demandan un servicio en la nube y que entienden los beneficios que SaaS les brinda en términos de eficiencia y agilidad. Sin embargo, como las opciones de SaaS o en la nube se convirtieron en intereses en juego, los clientes necesitan conocer las capacidades y los acuerdos de nivel de servicio que distinguen al servicio de un proveedor, en lugar del valor de la nube en sí.

No obstante, no todos los clientes están listos para recibir un servicio en la nube. En particular, puede que los clientes existentes en modelos de servicios alojados o administrados estén satisfechos con el estado actual, en especial si tienen componentes de servicio personalizados o entornos no estándar, y si tienen modelos de acceso que son incompatibles con la entrega en la nube. Incluso puede que los clientes que ven los beneficios del traslado a un servicio en la nube no se sientan cómodos con los cambios en los términos de entrega o con las interrupciones del servicio necesarias para migrar sus entornos.

Para convencer a los clientes, se requiere coordinación y una comunicación constante entre los equipos de mercadeo, ventas, soporte y éxito del cliente. En un mundo ideal, el cliente no se daría cuenta en absoluto de que sus cargas de trabajo se migraron. Un día notarían una mejora en el rendimiento sin ser conscientes de los cambios que se produjeron. La realidad es que, para la migración de servicios a la nube, a menudo se requieren actualizaciones, períodos de inactividad y, posiblemente, cambios en los términos del servicio o en la funcionalidad disponible. Guiar a un cliente a través de estos eventos, y a la vez mantener la alineación con la línea de tiempo de la transición general, es una hazaña compleja que requiere más que solo la comprensión de los beneficios del cambio. Requiere la aceptación de los cambios que se están produciendo y la alineación de los pasos de la migración que podrían llegar a afectar la empresa del cliente.

---

CMIC migra su software empresarial de construcción a Oracle Cloud Infrastructure y observa implementaciones 10 veces más rápidas.

"Además de los beneficios de costos de OCI en comparación con otros proveedores de servicios en la nube, ahora somos más ágiles. OCI nos brindó un nuevo nivel de flexibilidad tecnológica. Avanzamos hacia el futuro con tecnologías como Oracle Container Services y Oracle Autonomous Database para poder continuar concentrándonos en ofrecer el mejor software disponible de ERP de construcción." — Vince Di Piazza, director de TI y de infraestructura en la nube de CMIC

Vea el video

---

Una vez que un cliente respalda los beneficios y los cambios que acompañarán a la transición a la nube, el paso final para su organización es trasladar las cargas de trabajo del cliente al entorno nuevo. Esto se vuelve un desafío que consiste en determinar el momento óptimo para la migración y las pruebas de validación del entorno nuevo. Un cliente que acepta que deberá afrontar un período de inactividad seguirá teniendo, a menudo, opiniones firmes acerca de cuándo debería ocurrir este período.

Si bien las preferencias del cliente serán importantes para usted, se deben sopesar muchas otras preocupaciones. La planificación de migraciones implica una compensación de varios factores, incluidos los atributos técnicos de un producto o un servicio, la conciliación de las preferencias de todos los clientes, las limitaciones de los recursos internos y los objetivos comerciales, como la consolidación o la eliminación de los centros de datos heredados existentes o la finalización de la desaprobación de líneas de productos. Para equilibrar estas prioridades en conflicto, incluya equipos de atención al público en las actividades de planificación de la migración, ya que serán una voz clave en representación de las expectativas del mercado.

Su organización debe prepararse para un período de inversión y migración, así como para los cambios técnicos y de procesos empresariales en curso de un modelo de entrega en la nube. Sin embargo, también debe prepararse para la forma en que se involucrará a los clientes con respecto a la migración y para un nuevo orden establecido en la relación entre el producto y el cliente.

Nuestras GBU respondieron a estas necesidades primero mediante la revisión de la forma en que la transición afectaría a los clientes en términos técnicos, operativos y de compromisos de entrega, y se identificaron aquellos clientes que requerirían atención especial, compromiso y posibles cambios en la relación comercial. Los esfuerzos realizados para preparar a los equipos de atención al cliente se formulan desde una perspectiva similar, que implica la colaboración entre el producto, las operaciones, la estrategia y otros equipos para proporcionar conocimientos generales sobre la nube mientras se abordan cambios específicos de productos y clientes.

Este esfuerzo se trató de mucho más que simplemente preparar equipos de atención al cliente para involucrar a los clientes. Unir el liderazgo central y multifuncional para estar en concordancia con la participación de los clientes también generó oportunidades valiosas de expandir lo que, técnicamente y en gran medida, había llevado a los programas hacia iniciativas más amplias sobre la revisión del valor central de nuestras soluciones, la rearticulación de lo que diferencia a nuestros productos y la planificación de las mejor formas de preservar ese valor en el mercado y hacerlo crecer.

Preparación anticipada

Diseño de la infraestructura para alojar aplicaciones de SaaS

A lo largo de este manual, proporcionamos una guía de prácticas recomendadas basada en las lecciones que aprendimos durante la migración de más de 60 aplicaciones de GBU alojadas en miles de instancias. A continuación, resumimos los cinco desafíos principales que enfrentamos a lo largo de nuestro recorrido, ya que creemos que se pueden aplicar a cualquier organización que migre aplicaciones a la nube.

1. Determinar los esfuerzos de desarrollo previos a la migración
   Preparar una aplicación establecida para su lanzamiento en la nube puede implicar una gran inversión, en especial para llevar un producto a un estado nativo de la nube. La inversión en principios de aplicaciones nativas de la nube produce el mayor beneficio que puede obtener de la nube, a la vez que consume una gran cantidad de tiempo y recursos de desarrollo para llegar al estado final. Cuanto más tiempo se tarde en preparar un producto para la nube, más se demora el acceso a los beneficios incrementales e inherentes del traslado a la nube, por lo que se prolonga de forma potencial la exposición a los riesgos que en general se asocian con los entornos heredados. A la vez, no todos los productos se beneficiarán por igual. Esto dependerá de la fase del ciclo de vida útil y la posición del cliente. Comprender y documentar por completo la cantidad de trabajo de desarrollo que se debe realizar antes de la migración es clave para realizar un traslado exitoso.
   
   La flota de aplicaciones de GBU es diversa e incluye productos de todos los niveles de madurez de la nube y todas las fases del ciclo de vida útil. Si bien era necesario migrar todas las aplicaciones a la nube, tuvieron problemas con la cantidad de cambios que se debían realizar en los productos antes del lanzamiento en la nube. Encontrar el equilibrio correcto requirió que la organización evaluara la etapa del ciclo de vida de cada producto, su potencial de crecimiento y el esfuerzo necesario para trasladar el producto a la nube. En función de estas evaluaciones combinadas, las GBU determinaron el nivel de prioridad y los costos que se le asignaría a cada producto.
2. Determinar el equilibrio del desarrollo
   La cantidad de ancho de banda de ingeniería que asignar a la preparación para la inversión en la nube, en comparación con el desarrollo de nuevas características y funciones en respuesta a la demanda del mercado, representó un equilibrio difícil de lograr para las GBU.
   
   A las GBU no les faltó alineación en torno a la prioridad de la transición a la nube, pero los equipos de productos tuvieron dificultades para comprender cuánto trabajo se debería dedicar a las capacidades en la nube que mejorarían la experiencia del cliente y el rendimiento pero no servían como reemplazos de las funciones que demandan los clientes. El desarrollo en la nube requiere una inversión en capacidades operativas subyacentes que es posible que distraigan la atención de la capacidad de la organización para responder a la demanda de funciones nuevas de parte de los clientes. Estas compensaciones hacen que sea difícil descubrir cómo distribuir el tiempo entre la preparación para la nube y las iniciativas de mejora de los productos.
   
   A fin de responder ante este desafío, las GBU dependieron de los marcos de madurez de la nube que se analizaron en el Capítulo 1 para proporcionar información detallada sobre la inversión relativa en desarrollo que se requiere para cada camino. Luego, examinaron el ROI de cada etapa potencial de la transición a la nube y sopesaron ese resultado frente a la posible contribución de ingresos que se esperaba del desarrollo de funciones nuevas. Esto proporcionó un marco de evaluación común que se podría usar para determinar la combinación correcta de esfuerzos y mantener la visibilidad de los resultados empresariales objetivo.

   ---

   Altair opta por el procesamiento de alto rendimiento de Oracle Cloud Infrastructure y mejora la relación de precio y rendimiento en un 20 %.

   "Cuando analizamos a todos los proveedores de servicios en la nube, descubrimos que Oracle se concentraba mucho en HPC. Creo que su oferta de hardware fue la primera del sector y contaba con redes de alta velocidad y baja latencia, lo cual es muy importante para nosotros." — Piush Patel, vicepresidente sénior de relaciones estratégicas de Altair

   ---

3. Comprender la flota
   Ya sea que su empresa tenga una sola aplicación o una extensa cartera de aplicaciones, hay muchos factores a los que se le debe realizar un seguimiento y un inventario durante una migración a la nube. A fin de entender por completo qué cambios se deben realizar, debe comprender en su totalidad el inventario actual en los repositorios de las aplicaciones existentes, así como lo que se planea utilizar en la nube. Si tiene muchas aplicaciones que trasladar, es posible que no haya un inventario existente. O bien, puede confiar en el conocimiento tribal del estado de aplicaciones específicas. Incluso las empresas que tienen una única aplicación orientada al cliente deben realizar un inventario de todo el paquete de aplicaciones a fin de determinar qué aspectos se deberán modificar durante la migración a la nube. Comprender qué requisitos cambiarán en la nube y cómo se debe ver el diseño son aspectos esenciales para documentar el trabajo necesario para la transición.
   
   Se requieren diferentes tipos y cantidades de trabajo con respecto a cada instancia de la aplicación, según las características de la instancia (la versión, las dependencias de hardware o de plataforma, las personalizaciones y el modelo de acceso del cliente, entre otros). Además, los datos de la aplicación se pueden distribuir en varios sistemas de registro.
   
   Las GBU de Oracle son una consolidación de más de 30 adquisiciones con una flota que se extendió en 80 centros de datos y en más de 12.000 instancias de aplicaciones. Los datos esenciales relacionados con estas instancias estaban muy fragmentados y no necesariamente se gestionaban de manera coherente en todos los equipos de productos de componentes. Sin esta información, no podrían organizar y planificar de forma eficaz la mano de obra de la migración. A fin de generar una comprensión clara de lo que se necesitaba migrar, las GBU tuvieron que iniciar un esfuerzo dedicado de recolección y consolidación de datos.

   ---

   "El equipo de Oracle GBU pudo reducir el gasto de capital en un 80 % y disminuir los costos de infraestructura en un 64 % mediante la migración a OCI." — Mike Prindle, vicepresidente de arquitectura en la nube de GBU
   

   ---

4. Priorizar y organizar el esfuerzo de migración
   En realidad, las cargas de trabajo que se trasladan pueden emprender varios recorridos, que van desde copiar imágenes de máquinas virtuales existentes hasta instalar una instancia nueva y replicar los datos. Sin embargo, todos estos recorridos requieren algún nivel de inversión técnica o de compromiso laboral para completarse. Al multiplicarse en el entorno de cada producto de la flota de la organización, la cantidad y los distintos tipos de mano de obra involucrados en la migración se tornan abrumadores con facilidad. Los recursos disponibles para completarla son finitos y, a menudo, también tienen la responsabilidad de gestionar las operaciones diarias.

   ---

   OceanX traslada sus sistemas de inteligencia empresarial de Amazon Web Services (AWS) a Oracle Cloud Infrastructure y observa que el rendimiento se triplica.

   "Necesitábamos nuestra plataforma de datos para realizar escalamientos y ofrecer un alto rendimiento a un costo menor. La migración de la plataforma de datos de AWS a Oracle fue una de las migraciones más exitosas en OceanX y, junto con una ganancia significativa en el rendimiento que generó ahorros considerables de costos, produjo que todo el programa fuera un logro impresionante. En última instancia, esto nos permite ofrecer a nuestros clientes una plataforma que les permite tomar decisiones mejor informadas y con mayor rapidez." — Vijay Manickam, vicepresidente de datos y análisis de OceanX

   ---

   Para la transición a la nube de GBU, se necesitaron más de 3.000 proyectos de migración individuales. En un principio, estos proyectos se priorizaron en función de las preferencias del cliente (es decir, se priorizaron los plazos de la migración en función de los comentarios consolidados de los clientes) o de la preparación para la migración de un entorno en particular. En última instancia, este enfoque no logró ayudar a impulsar los beneficios empresariales incrementales durante el transcurso de la migración. Al no contar con marcos comunes de priorización o coordinación, las GBU observaron un volumen inconsistente de actividad de migración. Esto sobrecargó a los equipos responsables de completar el trabajo de migración con períodos intercalados de alta contención de recursos y de disponibilidad desperdiciada de los recursos.
   
   A fin de resolver estos desafíos, las GBU crearon una oficina central de gestión de programas dedicada a la migración y un comité ejecutivo de supervisión responsable de priorizar las migraciones en función de los resultados empresariales objetivo y de identificar las oportunidades de transición.
5. Gestionar los cambios en la organización
   Para los cambios involucrados en la transición a la nube, se requieren nuevas áreas de conocimiento, conjuntos de habilidades y procesos, así como otras áreas de cambio cultural. La gestión de estos desafíos de recursos humanos puede ser más difícil que la de los componentes técnicos de la transición a la nube. Para abordar este desafío, las GBU de Oracle GBU ayudaron a los equipos existentes a evolucionar en equipos en la nube mediante el enfoque en la capacitación. Gestionar la cuestión de cuándo traer talentos nuevos frente a cuándo encontrar mecanismos para hacer evolucionar la organización de otra manera requería que las GBU realizaran evaluaciones de personal en sus áreas funcionales y de productos principales y que, luego, asignaran la iniciativa de mejora adecuada en cada caso de uso. Si su empresa tiene varias aplicaciones que trasladar, considere dónde puede generar conocimiento básico de la nube que abarque todos los productos, como la seguridad y la IaaS general.

Celebración de los resultados

Este manual se basa en los conocimientos que acumularon nuestros equipos de Oracle GBU durante la migración de más de 60 aplicaciones basadas en SaaS a Oracle Cloud Infrastructure. Estas aplicaciones son compatibles con las funciones empresariales centrales de ocho verticales del sector y de más de 199.000 clientes en todo el mundo. Una migración diligente, planificada y bien ejecutada generó beneficios considerables.

• Se consolidaron 80 centros de datos en 11
• Se redujo el CapEx en un 80 %
• Se redujeron los costos de infraestructura en un 64 %
• Se redujeron los proveedores de software de 28 a 10
• Se redujo el gasto en software en un 42 %
• Se trasladó a las versiones diarias del software
• Se disminuyó el tiempo de aprovisionamiento en más del 98 %
• Disminución del tiempo de inactividad planificado en más del 98 %

Si bien este manual de ISV se basó en los conocimientos que obtuvieron nuestros equipos de GBU, su esfuerzo fue solo una de las varias migraciones extensas a Oracle Cloud Infrastructure. Si se tienen en cuenta los ingresos y la cantidad de clientes de todas nuestras aplicaciones de SaaS, Oracle se puede considerar uno de los ISV más grandes del mundo. Además, entendemos el proceso de migración. De hecho, trasladamos a Oracle Cloud Infrastructure toda nuestra cartera de productos, incluidos Oracle Fusion Cloud ERP, Oracle Fusion Cloud EPM, Oracle Fusion Cloud HCM, Oracle Advertising and CX y Oracle Fusion Cloud SCM. Estas migraciones son parte de nuestra iniciativa de transformación, que llamamos Oracle@Oracle. Fue un proyecto de varios años que involucró a decenas de miles de aplicaciones distribuidas en varias docenas de centros de datos.

Estos son algunos de los beneficios que observamos como resultado de estos esfuerzos.

• Infraestructura: Logramos una disponibilidad del 99,99 % en toda nuestra cartera de aplicaciones con un ahorro de costos del 30 % y mejoras de 2 a 10 veces en el rendimiento
• Finanzas: Obtuvimos la capacidad de cerrar libros e informar las ganancias en menos de 10 días
• Recursos humanos: Se redujo el tiempo del ciclo de revisión de talentos en un 70 %
• Cadena de suministro: Se redujo el ciclo de planificación de la cadena de suministro de 1 semana a 48 horas, lo que es una mejora del 71 %
• CX: Se redujo el tiempo de entrega de la campaña de 4 semanas a 5 días, lo que es una mejora del 82 %
• Sustentabilidad: Se reutilizó o recicló el 99,4 % del equipo dado de baja que se recolecto en Oracle durante el año fiscal 2019

Asociación con Oracle

Estamos ayudando a los ISV a expandir el mercado que pueden abordar mientras aumentan su potencial de crecimiento de ingresos de primera línea. Envíenos un correo electrónico a: oraclecloud-isv_ww@oracle.com para obtener más información.

Si desea obtener más información sobre por qué los ISV eligen Oracle Cloud, considere los siguientes recursos:

• isv.oracle.com
• El programa de Oracle@Oracle para ISV
• Explore el micrositio de Consideraciones y patrones de hospedaje en la nube

---

Körber consolida los sistemas de warehouse management en Oracle Cloud Infrastructure y se ejecuta un 40 % más rápido.

"Cuando evaluamos los distintos puntos de decisión, OCI fue una opción muy estratégica para lo que estábamos intentando hacer en términos de nuestra estrategia de comercialización." — Rick Schrader, vicepresidente sénior de ventas y alianzas en América del Norte de Körberö

Vea el video

---