Module4 02 Migration Methodology

Módulo 4 objetivos
El objetivo de este módulo es proporcionar al

estudiante las metodologías y herramientas para
migrar completamente las aplicaciones y datos
seleccionados al sistema de la nube de destino
-------------------------------------------------------------------
Nota: por razones de propiedad intelectual, el logotipo de
UCBL debe figurar en todos los usos de los contenidos del
curso, así como la nota "derechos de autor DUNOD" que
aparece en algunas diapositivas con figuras.
Migración a la nube: hoja de ruta
APARTADO 2: Metodología de la migración de aplicaciones a la
nube
APARTADO 2 PRESENTACIÓN
1. Preámbulo
2. Tipos de migración
3. Metodología para migrar una aplicación
4. Opciones de estrategia de migración
5. Herramientas
1. PREÁMBULO
PREÁMBULO
Al igual que con cualquier proyecto informático, las empresas necesitan analizar
la viabilidad técnica y económica de la migración a la nube de sus aplicaciones
informáticas.
En el proceso de toma de decisiones, conviene expresar en primer lugar las

necesidades y evaluar las soluciones de nube que cumplen con los requisitos de
la empresa.
Además hay que evaluar el retorno de la inversión (ROI), hacer un análisis de

riesgos y de integración con el sistema informático de la empresa.
2. TIPOS DE MIGRACIÓN
TIPOS DE MIGRACIÓN
Según Gartner, Inc, las organizaciones que deseen migrar sus aplicaciones a la
nube tienen cinco opciones [15] [16]:
Rehost: Alojar las aplicaciones tal cual en una Infraestructura como Servicio
(IaaS)
Refactor: Alojar las aplicaciones en una Plataforma como Servicio (PaaS)
Revise: Modificar y adaptar las aplicaciones a una IaaS o PaaS
Rebuild: Reconstruir una aplicación en una PaaS
Replace: Remplazar por Software como Servicio (SaaS)
"Cuando el Director General da la orden 'Muevan algunas aplicaciones a la

nube", los técnicos se enfrentan a decisiones desconcertantes sobre cómo
hacerlo, y por tanto, su decisión deberá tener en cuenta requisitos de la
organización, criterios de evaluación y principios de la arquitectura", dice Richard
Watson, director de investigación en Gartner.
"Sin embargo, no existe ninguna panacea: todas exigen que los técnicos planteen
la migración de aplicaciones desde múltiples perspectivas y criterios, incluidas las
competencias del personal informático, el valor de las inversiones existentes o la
arquitectura de las aplicaciones ".
TIPOS DE MIGRACIÓN
Podríamos añadir una 6a opción a la lista de Gartner [15] [16].
-Data Rehost : Mover los datos a la nube.
Consiste en transferir datos empresariales a sistemas de almacenamiento más

baratos para asegurar una mayor protección, un mejor rendimiento, una mayor
disponibilidad.
Este tipo de migración puede estar incluida de forma implícita en las cinco
opciones anteriores.
Se llama DaaS (Data as a Service).
Este tipo de migración puede utilizarse cuando la empresa necesita información

interna y externa en tiempo real para tomar decisiones rápidamente o para
problemas de integración de Big Data en el almacenamiento.
TIPOS DE MIGRACIÓN
Desde el nivel local a la nube
Rehost (IaaS)
Refactor (PaaS)
Revise (IaaS/Paas)
Rebuild (PaaS)
Replace (SaaS)
Desde una nube a otra (privada, pública)

TIPOS DE MIGRACIÓN
Dependiendo de si se migra una aplicación a SaaS, PaaS o IaaS, la
gestión de la migración y la carga de trabajo varía, como ilustra la
siguiente figura adaptada de [1]
My application
S1
S ervers
M y application
Data
Runtime
Middleware
Operating
Virtualisation
S torage
Network
S ystem
My application
D ata
R untime
Middlew are
Operating
Migración de una aplicación a IaaS:
System
IaaS
Virtualisation
Servers
TIPOS DE MIGRACIÓN
Storage
N etw ork
S1
My application
D ata
R untime
Middlew are
Operating
Migración de una aplicación a PaaS:
System
PaaS
Virtualisation
Servers
TIPOS DE MIGRACIÓN
Storage
N etw ork
S1
My app lication
D ata
R untime
M iddlew are
Operating
System
Migración de una aplicación a SaaS:
SaaS
Virtu alisation
Servers
TIPOS DE MIGRACIÓN
Storage
N etw ork
S1
TIPOS DE MIGRACIÓN
• La estrategia ideal para migrar a la nube no sólo depende
de las necesidades de cada empresa, sino también de las
condiciones de su antiguo sistema
• Cada estrategia tiene sus propios objetivos:
• Con PaaS, las empresas tienen que determinar los cambios
necesarios para que la aplicación sea compatible con la
plataforma en la nube
• En los casos en que las empresas necesitan hacer más
cambios para migrar a PaaS, puede ser más apropiada
la estrategia IaaS
• Como mecanismo eficaz para la distribución de
software, SaaS podría ser una opción ideal, pero el
reto para la reingeniería SaaS es evidente
TIPOS DE MIGRACIÓN
Comparación de tres estrategias teniendo en cuenta
varios criterios [2]:
IaaS PaaS SaaS
Carga de trabajo Baja Moderada Importante
Complejidad de la Fácil Moderada Difícil

migración
Adaptación No requerida Modifica las Requiere
aplicaciones para Ingeniería inversa
adaptarlas Ingeniería avanzada
Impacto Ahorra en gasto de Libertad de gestión Mecanismo de
equipamiento de los recursos precios flexibles, fácil
mantenimiento,
reutilización y
escalabilidad
TIPOS DE MIGRACIÓN REHOST (IAAS)
• Vuelve a implementar la aplicación en un entorno físico diferente y

cambia las configuraciones de la infraestructura de aplicaciones [15]
[16] [17]
• Ventajas: Realoja la aplicación sin cambiar su arquitectura agiliza la
migración
• Inconvenientes:
• La aplicación no aprovecha beneficios de la infraestructura en la nube,
como la escalabilidad
• El alojamiento o la virtualización de sistemas muy específicos o
antiguos no siempre es posible
Infraestructura virtual
Base de datos ....
....
Aplicación
Implementación en la Implementación en una

plataforma en la nube
plataforma inicial
TIPOS DE MIGRACIÓN REFACTOR
(PAAS)
El objetivo de refactor es implementar aplicaciones que se ejecutan en un
entorno técnico con el hardware más reciente y sistemas operativos
suministrados por la nube [15] [16]. Aunque puede requerir ajustes menores,
a menudo permite mejorar la disponibilidad y el rendimiento o aumentar la
capacidad de los recursos.
Ventajas:
•Alarga la vida de las aplicaciones heredadas
•Combina innovación y familiaridad, ya que las PaaS permiten el uso de
lenguajes y entornos que los desarrolladores conocen y dominan.
Inconvenientes:
•Algunas herramientas de desarrollo muy antiguas pueden plantear
problemas de compatibilidad y reducir la funcionalidad de las aplicaciones
migradas.
•No explota todas las capacidades de PaaS
•Marco cerrado
TIPOS DE MIGRACIÓN REVISE
(IAAS/PAAS)
La estrategia revise tiene por objeto modificar o cambiar el código existente para
que pueda beneficiarse de las ventajas de la nube (escalabilidad, etc.) para
después implementar las aplicaciones aplicando las estrategias rehost y refactor
[15] [16].
Ventajas:
•Las aplicaciones pueden evolucionar hacia una explotabilidad mejorada y
ampliada (alta disponibilidad o procesamiento paralelo, por ejemplo)
•Las aplicaciones pueden ser adaptadas a las nuevas funciones (interfaz web,
conexiones con otros programas, etc.).
Inconvenientes:
•Puede exigir cambios más allá de la migración propiamente dicha. Éstos pueden
ser lentos y verse limitados por el diseño inicial de las aplicaciones.
•Los cambios conllevan el gasto de movilizar a un equipo de desarrollo
•Dependiendo del alcance de la revisión, este tipo de migración es probablemente
el que más tiempo requiere.
TIPOS DE MIGRACIÓN REBUILT (PAAS)
Ocurre a nivel PaaS [15] [16].
En este caso el código existente se deja de lado y se procede a reconstruir la

arquitectura de la aplicación
Ventajas:
•Acceso a nuevas características que ofrece PaaS, que mejoran la productividad
de los desarrolladores, como herramientas para la personalización de plantillas
de aplicaciones o modelos de datos.
Inconvenientes:
•Menor familiaridad con las herramientas que ofrece PaaS.
•El lock-in es el principal inconveniente, de hecho si el proveedor introduce
cambios técnicos o de precio que el cliente no puede aceptar, si viola el CNS o si
desaparece, el cliente se verá obligado a cambiar, o incluso a renunciar a
algunas o a todas sus aplicaciones heredadas
TIPOS DE MIGRACIÓN REPLACE (SAAS)
Abandona una aplicación (o un conjunto de aplicaciones) existente y utiliza una
solución comercial ofertada como servicio que cubre las características
existentes [15] [16].
Ventajas:
•Esta opción evita la inversión y la movilización de un equipo de desarrollo en
casos en los que las necesidades de las funciones empresariales cambian con
frecuencia.
•El uso de software estándar permite que la empresa se beneficie de los
desarrollos de software a menor coste (ya que el coste es compartido entre
todos los clientes de la empresa).
Inconvenientes:
•Lock in
•Acceso no autorizado a los datos
•cambios muy significativos en los hábitos de trabajo de los usuarios en el
momento de la transición entre los programas antiguos y los nuevos.
•Necesidad de una política de formación.
•La empresa no puede desarrollar la aplicación aegún su propia conveniencia
TIPOS DE MIGRACIÓN DE DATOS
REHOST (DAAS)
En este caso la migración sólo afecta a las bases de datos.
Infraestructura virtual
Base de datos ....
....
Aplicación
Implementación en la Implementación en una
plataforma inicial plataforma en la nube
Ventajas:
•Las transferencias de datos a los sistemas de almacenamiento son escalables.
•Mejor Garantía de protección y seguridad.
•Los datos pueden ser particionados para mejorar y optimizar el rendimiento.
Inconvenientes:
•La transferencia de datos y su partición podría afectar negativamente a las
aplicaciones existentes
3. METODOLOGÍA PARA MIGRAR UNA
APLICACIÓN
METODOLOGÍA PARA MIGRAR UNA
APLICACIÓN
Note que la mayor parte de este contenido es sobre la
migración PaaS, o IaaS en menor medida.
De hecho la migración a SaaS solo implica la migración

de la utilización del producto, y la migración a una
plataforma IaaS suele consistir en simples copias de las
aplicaciones en las máquinas virtuales.
METODOLOGÍA PARA MIGRAR UNA
APLICACIÓN
• Las diferentes metodologías de migración, tanto académicas
como empresariales, tienen más o menos las mismas fases
• Las únicas diferencias son la fusión de dos o más fases en una,
pero en general contienen las mismas tareas
• Las fases para la migración de una aplicación son:
A. Toma de decisiones
B. Estudio preliminar
C. Diseño y planificación
D. Proyecto piloto
E. Migración
F. Mejora y desarrollo de la nube
G. Optimización
A. TOMA DE DECISIONES
• El primer paso, incluso antes de hablar de migración
a la nube, es la fase de toma de decisiones
• Este paso tiene como objetivo responder a la
pregunta general: "¿Tiene interés la empresa o la
organización en ir a la nube"?
• Hemos presentado anteriormente las ventajas y
desventajas de la nube; es importante ahora
determinar qué solución presenta mayores ventajas
en el caso de una empresa y una(s) aplicación(es)
concreta(s)
• Este paso no existe en las metodologías que ofrecen los
proveedores. Podemos pensar que asumen que si una
organización está interesada y está leyendo su metodología ya
ha decidido migrar a la nube
• Sin embargo, las metodologías más académicos siempre
describen este paso
• Este enfoque se presenta generalmente bajo la forma de un
conjunto de criterios de análisis, y se desglosa así:
1. Definición de los criterios de decisión
2. Ponderación de la tabla de criterios
3. Análisis de la solución
4. Agregación de los resultados
• La definición de los criterios de decisión se basa en las
necesidades de los usuarios y en la política de seguridad de la
empresa
• La ponderación de la tabla de criterios El objetivo es asignar una
puntuación a cada criterio en una escala de 1 a 4 (importancia
crítica, grande, media o baja). Eso nos permitirá cuantificar con
precisión los criterios desde la perspectiva de la empresa
(seguridad o reducción de costes, por ejemplo)
• El análisis de la solución Tenemos que comparar la solución con
la tabla de criterios. Esta fase se puede hacer a través de la
documentación en línea o visitando el proveedor para formularle
preguntas relacionadas con la tabla de los criterios. Luego
puntuaremos cada criterio (p.ej. 1 punto si el requisito se cumple
parcialmente, 2 puntos si se cumple totalmente)
• La agregación de los resultados Este paso consiste en analizar
los resultados en términos de notas y pesos relativos para obtener
indicadores. Dichos indicadores, preferiblemente gráficos, ayudarán
en el proceso de toma de decisiones
A. Familia de criterios para la empresa [4]:
Criterios Comentarios
Análisis de costes •¿Proporciona la plataforma en la nube un buen ROI (teniendo en cuenta

la suscripción y la implementación)?
•Por ejemplo, ¿Suponen beneficios sustanciales la reducción de los costes
de licencias informáticas, dispositivos y carga de trabajo de los equipos?
Estrategia del •¿Es la plataforma en la nube el núcleo del negocio del operador o una
operador oferta marginal?
Sostenibilidad del •¿Es el proveedor de servicios en la nube sostenible? ¿solvente?

operador ¿maduro?
Flexibilidad del • ¿Impone contratos el operador?
operador
Racionalización •¿Permite la plataforma en la nube externalizar tareas tediosas,
en torno a la excluyendo las que constituyen el núcleo del negocio?
actividad principal •El correo, por ejemplo, nunca es una aplicación empresarial.
A. Familia de criterios para la empresa:
Cumplimiento •¿Es adecuado el modelo de nube para el sector de la empresa?

Normativo •No es posible, por ejemplo, subcontratar la contabilidad de un
banco
Aceptación por •¿Podría plantear problemas a los clientes o a los socios la
parte de clientes utilización del modelo de nube? Por ejemplo, un abogado de
y socios negocios puede externalizar fácilmente documentos relativos a
fusiones / adquisiciones.
Desarrollo •¿Es posible que el uso de la nube reduzca la huella
sostenible medioambiental de la empresa?
Made in France •El uso de una nube ubicada en el extranjero plantea algunos
(Europe) problemas potenciales frente a la legislación local
Seguridad •Seguridad de las aplicaciones y capacidad para restaurar los
datos en caso de problemas.
B. Familia de criterios para los usuarios:
Agilidad •¿Permite la plataforma en la nube acortar el tiempo de
comercialización de las aplicaciones?
Ergonomía de •¿Está permitiendo la plataforma en la nube ofrecer a los usuarios
las aplicaciones más ergonómicas para el seguimiento de los clientes?
aplicaciones
Aplicaciones •¿Permite la plataforma en la nube disponer con mayor frecuencia

Escalabilidad de los desarrollos de aplicaciones utilizando el "beta perpetuo"?
Acelerador de •¿Es la plataforma una buena herramienta que facilite la incubación
innovación de aplicaciones innovadoras?
Accesibilidad •¿Posibilita la plataforma la oferta de aplicaciones más accesibles a

para personas con deficiencias?
personas con
deficiencias
B. Familia de criterios para los usuarios:
Accesibilidad de •¿Permite la plataforma en la nube ofrecer a los usuarios
las aplicaciones aplicaciones más accesibles? Por ejemplo, ¿son accesibles en
una situación de teletrabajo o en una situación nómada, desde
un móvil?
Disponibilidad / •¿Ofrece el operador de servicios en la nube una mayor
aplicaciones disponibilidad de las aplicaciones que la empresa? Habría que
QoS verlo
•Por ejemplo, una pequeña empresa que subcontrata el correo
electrónico se beneficiará de una disponibilidad del 99,9%.
Mashups •¿Permite la plataforma en la nube crear nuevas aplicaciones
mediante ensamblaje?
Aceptabilidad •¿Introduce la plataforma en la nube restricciones inaceptables
para los usuarios? Por ejemplo la imposibilidad de trabajar sin
conexión.
C. Familia de criterios para el DSI (Departamento de Sistemas Informáticos):
Agilidad de los estudios •¿Permite la plataforma en la nube ahorrar tiempo

en tareas de desarrollo?
Agilidad en la •¿Permite la plataforma en la nube ahorrar tiempo
producción en las tareas de puesta en producción?
Gestión del cambio •¿Son aceptables los nuevos métodos de trabajo

relacionados con la nube (almacenamiento de
datos en los servidores del proveedor, lock-in de
datos, gestión de proveedores)?
• ¿Se simplifica el proceso de capacitación?
Flexibilidad de la •¿Impone la plataforma una arquitectura
plataforma restringida al SI?
Criterios Subcriterios Comentarios
C. Familia de criterios para el DSI:
Seguridad Autenticación •¿Ofrece el proveedor de servicios en la nube un
dispositivo de autenticación suficientemente seguro,
especialmente para tareas administrativas?
•De lo contrario ¿ofrece un sistema de delegación
de la autenticación?
Confidencialidad •¿Es compatible la externalización de los datos
de los datos plataforma en la nube con la política de seguridad
almacenados de la empresa?
por el operador •Por ejemplo, los datos relacionados con la
de servicios en programación de proyectos pueden ser
la nube subcontratados si tienen la clasificación de no
críticos.
Simplificación de •¿Ofrece el proveedor de la nube un sistema de
la seguridad de seguridad más homogéneo que el de la empresa?
acceso
(confidencialidad
de los datos
intercambiados)
C. Familia de criterios para el DSI:
Criterios Subcriterios Comentarios

Seguridad Confidencialidad •¿Ofrece el proveedor de servicios en la nube un
de los datos sistema de copias de seguridad o un plan de
almacenados recuperación en caso de desastre más avanzado
por el operador que el de la empresa?
de servicios en •Por ejemplo, una PYME puede mejorar la
la nube seguridad mediante la externalización de sus
datos.
•¿Ofrece el operador la posibilidad de rastreo de
Trazabilidad accesos / del comportamiento del usuario?
Reversibilidad •¿Ofrece el proveedor herramientas para recuperar
datos / aplicaciones?
•De lo contrario, ¿ofrece al menos una API para la
creación de una herramienta de este tipo?
Tiempo de •¿Tiene el operador un compromiso permanente
recuperación de recuperación en caso de fallo?
•Después de analizar el proceso con ayuda de la tabla

de criterios, podemos estudiar otra faceta de esta fase
de la toma de decisiones, que supone pensar en las
ventajas y desventajas desde la perspectiva de las
diferentes partes de la empresa implicadas en la
migración
•Esta reflexión debe llevarse a cabo en paralelo o de
forma previa al análisis de la tabla de criterios
presentada en la sección anterior
1.El punto de vista del legislador
Ventajas:
•La reducción de los costes de infraestructura. En primer lugar, es posible
reducir los costes relacionados con los equipos operativos gracias a la
mutualización. Además, los operadores compran las máquinas y su
energía al por mayor, lo que les permite negociar el precio
•La "TI verde" o Informática verde: la nube permite minimizar el impacto
ambiental de la informática, evitando por ejemplo el desperdicio de
energía de las estaciones de trabajo y de los centros de datos. Los
actores de la informática en la nube suelen disponer de dispositivos de
ventilación optimizadas y están empezando a utilizar más energía
renovable para sus centros de datos
Ventajas:
•Reducción de los costes de utilización:
• El modelo económico de la nube es el de pago por consumo
• La suscripción es casi siempre más barata que la internalización, y también
contribuye a que costes en tiempo y en capital (CAPEX) se conviertan en
gastos operativos (OPEX)
•La nube ofrece buenas garantías de seguridad en términos de integridad
de los datos
•Esto a su vez ayuda a centrarse en el negocio principal, concentrando los
esfuerzos en los aspectos centrales del negocio y en la creación de valor,
y delegando la totalidad o parte del sistema informático [5]. La nube
también aporta otras tantas ventajas como un sistema de información más
sostenible, una mayor celeridad en la implementación de nuevas
características, etc...
1.El punto de vista del legislador
•Inconvenientes:
• El alojamiento de los datos en la nube supone un riesgo comercial: ¿qué ocurre
en caso de quiebra del operador? ¿Y si cambia sus términos o tarifas? Es
importante medir con precisión estas incertidumbres y tenerlas en cuenta en el
proceso de selección del operador
•Cuando una empresa se propone migrar a la nube la información de sus

clientes (correos electrónicos, direcciones...) es necesario tener en cuenta la
opinión del cliente
•Debemos comprobar, por ejemplo, si esa migración implica o no restricciones

legales. Podría ser que algunos datos deban ser declarados a la Agencia de
Protección de Datos o que ciertos empleados hagan valer sus derechos
2.El punto de vista de los usuarios
•Ventajas:
• La utilización de la nube acelera la implementación de nuevas
aplicaciones sin tener que pasar por el DSI, cuyos procedimientos son
a menudo pesados y lentos
• Las aplicaciones SaaS suelen ofrecer funcionalidades sencillas, más
centradas en el usuario y pueden mejorar la productividad general
• La nube ofrece nuevas oportunidades y permite una gran disponibilidad
de las aplicaciones (en el trabajo, en casa, en situaciones de
teletrabajo, etc...)
• La nube también permite una migración más rápida de la estación de
trabajo, puesto que el entorno de trabajo del usuario es almacenado en
la plataforma del proveedor
• La nube es utilizada para gestionar la recuperación de datos y exime de
responsabilidad a los usuarios en cuanto a los métodos de copia de
seguridad y los complejos métodos de recuperación de datos
2. El punto de vista del usuario:

•Inconvenientes:
• En general, los usuarios no confían mucho en la privacidad
de los datos
• Las aplicaciones gestionan mal el mundo offline
• La nube también puede despojar a los usuarios de sus
estaciones de trabajo. El riesgo social relacionado con la
transformación es ahora uno de los puntos clave del cambio
en el alcance de las operaciones informáticas [5]
3. El punto de vista de los informáticos expertos:
• Ventajas:
• La nube siempre implica una mayor agilidad, tanto para los
estudios como para la producción. Se puede utilizar para
proporcionar máquinas más rápidas, entornos de desarrollo
/ pruebas / fórmulas... También permite configurar más
fácilmente escenarios de desbordamiento o de un consumo
elevado de recursos, gracias a la elasticidad de sus
propiedades
• La nube permite a los informáticos centrarse en las
aplicaciones informáticas empresariales en vez de hacerlo
en los recursos físicos
3. El punto de vista de los informáticos expertos:

•Inconvenientes:
• Los informáticos temen la pérdida de poder y de recursos
que genera la migración. También puede implicar reducción
de presupuestos y de personal. Por tanto, los equipos
operativos ven peligrar sus puestos de trabajo
• Incluso si los argumentos mencionados en los apartados
anteriores deberían bastar para convencerles, siguen
siendo escépticos en el ámbito de la seguridad
• Otro temor que puede plantearse es la dependencia de la
red, como hemos visto anteriormente
Resumen de los impactos de la migración a la nube en diferentes
áreas de la empresa (3)
Área Ventajas Impactos Cambios necesarios

Empresa Permite centrarse en el Cuestiones legales Mayor competencia del
núcleo de su negocio. Riesgo de rechazo por departamento jurídico
Reducción de costes parte de clientes /
socios
Usuarios Tiempo de
comercialización
Usabilidad y escalabilidad
Calidad del servicio
accesibilidad
Departamento OPEX en lugar de CAPEX Dificultades para Mayor competencia del
de compras Pay As You Go (Pago por contactar departamento de
consumo) Garantías limitadas compras
OPEX: Gastos operativos

CAPEX: Gastos de capital
Resumen de los impactos de la migración a la nube en las distintas
áreas de la empresa
Área Ventajas Impactos Cambios necesarios

Responsable Cuestionamiento de la Desarrollo de la política de
de la política de seguridad seguridad
seguridad
Responsable Reorientación Nuevos problemas de Aprobación de los operadores de

de la hacia la arquitectura la nube
arquitectura urbanización
Análisis Agilidad Limitaciones de Creación de un centro de

desarrollo de la PaaS competencia sobre la nube
Producción Agilidad Reducción en el Certificación del operador de la

espectro de la nube
intervención
B. ESTUDIO PRELIMINAR
• Si la decisión de migrar a la nube es favorable, se debe hacer

un estudio preliminar para investigar la viabilidad del proyecto
de migración
• Este estudio debe ser transversal y completo, y debe tener en
cuenta muchas consideraciones en diversas áreas, tales como:
1. La elección del tipo de nube y del proveedor
2. El estudio de costes
3. La estimación de beneficios
4. El análisis de riesgos

•El primer paso de este estudio, antes de estimar los costes, los
riesgos y los beneficios, es elegir un tipo de migración y un
proveedor de servicios en la nube
•La migración a una solución SaaS sólo es posible si ya existe un
producto similar a la nube original. Es sólo una migración de la
utilización del producto
•La elección entre IaaS y PaaS debe basarse en las necesidades
de la empresa y las características de los dos tipos de nube, como
se describe en la primera parte. Cabe señalar que aunque PaaS
está ganando popularidad, IaaS sigue siendo la solución más
común
•También está la cuestión de elegir entre una nube privada, pública

o híbrida
•El tema principal en este proceso de elección es la propiedad y
seguridad de los datos
•Cuando se haya optado por una de estas opciones, queda elegir
un proveedor de servicios en la nube con una oferta apropiada.
Conviene ser cuidadosos con ciertos criterios a la hora de
seleccionar el proveedor
1. La elección del tipo de nube y del proveedor:
•Criterios de selección:
• Potencial de evolutividad (hardware, internacional, visión de futuro), para
garantizar la sostenibilidad de la aplicación
• Interoperabilidad de su plataforma y riesgo de bloqueo del proveedor y de la
compatibilidad no asociada
• Certificaciones de seguridad de sistemas informáticos - 27001, por ejemplo - y
certificaciones físicas de su centro de datos. La certificación de los procesos
(incluyendo la gestión de incidentes y la recuperación en caso de desastre) es
imprescindible
• Debe ser claramente capaz de asegurar la localización de los datos, así como
sus flujos
• En función de la criticidad de los datos, puede ser conveniente elegir un
proveedor que pueda albergar datos fuera de los EE.UU., estando autorizado el
gobierno a acceder a los mismos en base a la Patriot Act
•Si se cumplen estos aspectos críticos, la elección sólo dependerá de los precios, de la
reputación, y de la adecuación de los servicios ofrecidos a los requisitos del proyecto
La siguiente clasificación adaptada de [6] es un ejemplo de ayuda para la
elección de un proveedor por tipo de nube y luego por función
Proveedor de SaaS
Comunicaciones y
Colaboraciones en Línea
•Adobe Acrobat Connect
•BaseCamp
Finanzas, Recursos Humanos,
Nóminas y ERP •Cisco WebEx
•Google Apps Ventas y CRM
•Agresso •Oracle Siebel On Demand
Escritorio Alojado •Huddle
•NetSuite •SalesForce.com
•EnTrustIT •IBM Lotus Live
•Sage Online 50 •SugarCRM
•Naastar •Microsoft BPOS
•SAP Business by desugn •Zoho
•ThinkGrid •Zoho
•Workday
Proveedor de PaaS
Usuario empresarial Plataformas para Lo mejor de ambos
Plataformas Desarrolladores mundos
•Caspio •Bungee Connect •Force.com
•Intuit QuickBase •Google AppEngine •LongJump
•Wolf frameworks •Microsoft Windows Azure
•Zoho Creator
Los siguientes ejemplos se refieren a IaaS y a nubes privadas:
Proveedor IaaS
Máquinas
Almacenamiento Nube Privata
Virtuales Red Informática Red de Datos
•Amazon S3 Virtual
•Amazon EC2 •Amazon Elastic MapReduce •IBM eXtreme scale
•GoGrid •Amazon VPC
•Flexiscale •CycleCloud •GigaSpaces XAP
•Microsoft SkyDrive •BT VDC
•GoGrid •CloudEra •Oracle Cogerence
•Mozy •OpSource Cloud
•Joyent •Terracotta
•Rackspace
•Rackspace
Nubes Privadas
Privada Código abierto
•Eucalyptus •Enomaly
•IBM •Open Nebula
•Platform •Reservoir
•Rackspace •Nimbus
•Unisys
•Univa UD
•VMWare vSphere
2. El estudio de costes:
•Inmediatamente después de esta elección viene el estudio de los
costes del proyecto de migración
•Este importante aspecto, sin embargo, es difícil de estimar ya que
actualmente no existe ningún método de cálculo estándar [3]
•Esto se explica por el carácter reciente de este tipo de proyectos,
así como por su especificidad y heterogeneidad
•De hecho, los proyectos de migración varían mucho en función de
los componentes a migrar, de las arquitecturas, de las tecnologías,
de los objetivos de la migración, etc... Esto hace que sea difícil
hacer estimaciones empíricas de costes sobre la base de
proyectos parecidos
•Los costes pueden ser de 2 tipos [3]. El primero, y con mucho el más importante,
incluye los costes de la migración propiamente dichos. Debe incluir los costes
relativos a:
• el estudio preliminar
• la intervención de los consultores
• la formación de técnicos e ingenieros informáticos
• la formación de los usuarios internos potenciales de la plataforma
• la realización de un PoC (Prueba de Concepto)
• el desarrollo de componentes de unión específicos
• la reingeniería de la aplicación o al menos de algunos de sus componentes
• el desarrollo de funciones adicionales para aprovechar las ventajas de la
nube
• la pérdida de beneficios que se deriva del esfuerzo invertido en el proyecto
de migración
• el coste de oportunidad
• el riesgo de fracaso del proyecto
•A estos gastos hay que agregar los costes recurrentes una vez
implementada la solución, es decir los costes de infraestructura,
mantenimiento y soporte
•En esencia, estos costes serán mucho más bajos en la nube que
en una solución basada en el alojamiento local o incluso que un
servicio de alojamiento gestionado [7]
•Un estudio de caso realizado con rigor científico ha demostrado
que alojar la aplicación en la nube en vea de en un centro de datos
supone un ahorro del 37% de los costes de infraestructura de una
empresa [3]
•Sin embargo, es necesario realizar un análisis previo en
profundidad para estimar la rentabilidad esperada de la inversión
3. Estimación de beneficios:
•Para poder calcular el retorno de la inversión, debemos poder
estimar los beneficios generados por la solución
•Los profesionales del sector han propuesto varios ejes que
ayudan a realizar este cálculo, como por ejemplo "las 10 Leyes de
la Nubología" [8]. La mayoría de estos criterios ya han sido
abordados en este curso (ver "¿Por qué migrar a la nube?")
•La utilización de este tipo de ejes facilita el cálculo de los
beneficios de la nube, que dependerán de los elementos nuevos
que aporta en comparación con la aplicación inicial
• La siguiente figura describe la construcción del ROI de la informática en la nube a
través de indicadores clave de rendimiento (KPIs) y de métricas [18]
• Sería interesante añadir medidas relacionadas con la experiencia del cliente de la
Web. Estas medidas pueden indicar si la experiencia de los clientes ha sido
exitosa, y si las aplicaciones basadas en SaaS han respondido a sus expectativas
4. El análisis de riesgos:
•Como parte de este estudio preliminar, también hay
que evaluar adecuadamente los riesgos relacionados
con el proyecto en su conjunto, tanto en términos de
gravedad como de probabilidad
•Este ejercicio es a veces descrito en la literatura
específica como el mayor reto del proyecto
•Los riesgos se pueden agrupar en dos grandes
categorías: riesgos generales y riesgos relacionados
con la seguridad [9] (véase el capítulo análisis de
riesgos)
•Los riesgos generales incluyen:
• Problemas de rendimiento no anticipados
• Las discontinuidades dentro del servicio que afectan a la actividad
empresarial
• La eficacia del sistema de recuperación; subestimación de la
magnitud de acontecimientos específicos y de otras restructuraciones
de la aplicación que pueden disparar los costes de forma sustancial
• Los problemas de cumplimiento y gobernanza de las normas
• Los problemas de licencias
• La ubicación de los datos, la propiedad y los cambios en las leyes
que les afectan
• El incumplimiento de las cláusulas del CNS por parte del proveedor
• El grado de interoperabilidad de la plataforma
• La falta de comprensión y anticipación de la complejidad de un
proyecto de migración a la nube, que puede llevar al fracaso
Los riesgos generales incluyen también:

la pérdida de confianza de los accionistas o de la división de negocios de la
empresa en caso de fracaso del proyecto o un riesgo que no ha sido controlado;
la sobrevaloración de los beneficios de la solución;
el incumplimiento de la solución en relación con las expectativas iniciales
generadas, por falta de realismo o debido a problemas técnicos que impliquen
una reducción del número de funcionalidades;
la resistencia de los miembros de la organización frente a los cambios
provocados por la nube (por ejemplo, el miedo a ser despedidos como
consecuencia de la migración).
Esta larga lista no es, por desgracia, exhaustiva, y también tenemos que
prever los riesgos relacionados con la seguridad. Todo esto se aborda en la
parte 1 del Módulo 3.
•Los riesgos relacionados con la seguridad han sido identificados y

detallados en una conferencia de la CSA (Cloud Security Alliance) en 2009
[10]
•Las organizaciones que desean poner en marcha un proyecto de
migración se ven limitadas por una serie de leyes y normas
internacionales, tales como la obligación de mantener registros de
ejecución coherentes, así como los derechos de acceso a la
documentación
•Por otra parte, aunque la posibilidad de pérdida de datos es reconocida
en los entornos del negocio de la nube, la solidez de los sistemas para
evitar este problema no ha sido todavía plenamente demostrada
•Según el mismo artículo, algunos aspectos clave de la gestión de la
vulnerabilidad y de las respuestas en caso de incidentes todavía no son
plenamente asumidos por los proveedores y han de ser demostrados
C. DISEÑO Y PLANIFICACIÓN
• Este paso incluye la planificación y el diseño detallados del
entorno de destino (memoria, CPU, espacio en disco)
• Incluye también la toma de decisiones sobre arquitectura y el
dimensionamiento de los equipos tras el estudio de los patrones
de uso de las baterías y del software
• Este paso suele formar parte de los métodos empresariales,
aunque tiene pocos puntos en común con otros, probablemente
debido a la especificidad de las plataformas. Sin embargo, en la
investigación académica, encontramos muy pocos trabajos
relacionados con esta etapa
Esta fase se divide en 4 partes:
1. Creación de un árbol de dependencias y de una tabla de

clasificación
2. Identificación de buenos "candidatos" para la nube
3. Mapeo
4. Creación de una hoja de ruta y de un plan
clasificación
Los métodos con más información sobre este tema, como el de

Amazon Web Services [7], recomiendan
-Empezar con una revisión exhaustiva de las estructuras lógicas
de las aplicaciones empresariales,
-Y clasificar las aplicaciones de acuerdo con sus dependencias,

riesgos y requisitos de seguridad y conformidad.
clasificación
Para ello, los pasos a seguir son:
•Identificar las aplicaciones y su dependencia respecto de otros
componentes y servicios
•Crear un árbol de dependencias que permita visualizar las diferentes
partes de las aplicaciones y sus dependencias hacia arriba y hacia abajo
•Crear una hoja de cálculo que enumere todas las aplicaciones y las
dependencias o simplemente hacer un árbol de dependencias en una
pizarra que refleje los diferentes niveles de interconexión de los
componentes. Este esquema debe proporcionar una imagen clara de las
aplicaciones empresariales activas. La siguiente figura muestra un
ejemplo de un árbol de dependencias [7]
1. Creación de un árbol de
dependencias y de una tabla de
clasificación
En esta etapa, podemos clasificar las

aplicaciones en diferentes categorías:
– Aplicaciones con acoplamiento fuerte
o débil
– Aplicaciones sensibles / secretas,
– Datos públicos o privados
– ....
CRM Customer Relationship Management
DB Database
OLAP OnLine Analytical Processing
LDAP Lightweight Directory Access Protocol
ERP Enterprise Resource Planning
BIDW Business Intelligence and Data Warehousing
Árbol de dependencias [7]
•A continuación es aconsejable examinar las dependencias
ascendentes y descendentes de cada aplicación con el fin de
determinar cuáles podrían ser trasladadas a la nube rápidamente
•En la mayoría de los casos, los mejores candidatos para la nube
son servicios o componentes que tienen pocas dependencias
ascendentes y descendientes. También podemos buscar las
aplicaciones más infrautilizadas que tengan una necesidad
inmediata de escalabilidad y poca capacidad, las aplicaciones más
flexibles en cuanto a su arquitectura, etc.
•No debemos priorizar las aplicaciones que requieren equipos
especializados (por ejemplo, la unidad central o equipos
especializados en cifrado)
La figura siguiente [7] ilustra este paso. Este ejemplo muestra la selección de
aplicaciones con menor número de dependencias respecto de otras aplicaciones.
3. Mapeo
Aunque no se suele mencionar, el mapeo parece una buena

práctica.
Para configurar una plataforma de informática en la nube mediante

la adaptación del software existente, es necesario un estudio
previo para mapear el SI e identificar los vínculos existentes entre
los servidores, las aplicaciones de back-office, las aplicaciones de
front-office, el nivel de privacidad de los datos, las aplicaciones
utilizadas en los escritorios y sus usuarios.
3. Mapeo
puede puede puede
Confidenciali
bit eligible bit eligible bit eligible
Tiempo real
ser ser ser
Gestión
elegible elegible elegible
dad
a estudiar puede a estudiar puede a estudiar puede
ser ser ser
elegible elegible elegible
Integración con el SI Funcionalidades estándar Recursos físicos
Elegibilidad para la nube: categorización de aplicaciones

adaptado de [20]
El mapeo incluye las siguientes etapas [9]:
Después de definir lo que va a ser migrado y lo que va a seguir funcionando localmente,
podemos definir formatos de mensajes entre aplicaciones, y predecir el desarrollo de los
traductores. A continuación hay que asignar los diferentes entornos y sus interacciones, y
luego organizar las dependencias.
4. Creación de una hoja de ruta y de un plan
•Los pasos anteriores han permitido hacerse una idea de cómo la
migración prioriza las solicitudes, estima el esfuerzo necesario para
migrar, puede predecir los costes no recurrentes implicados y evalúa el
calendario
•Las soluciones a considerar para determinar cómo se deberá construir la
plataforma en la nube serán analizadas con ayuda de una hoja de ruta de
migración a la nube
• En el ámbito empresarial, la mayoría de las empresas y de los
proveedores de servicios en la nube omiten esta fase y pasan
directamente a la siguiente, la de construcción de un proyecto
piloto, ya que éste facilita una mejor comprensión de tecnologías y
herramientas
• Las metodologías académicas recomiendan planificar en detalle la
migración [12]
D. PROYECTO PILOTO
Empezar con una versión piloto que contenga pocos datos para generar
una prueba de concepto "Proof Of Concept".
Implementar los cambios de código requeridos en la aplicación elegida

para lograr los objetivos de implementación en la nube en términos de
especificaciones técnicas y empresariales.
Se trata por tanto de una fase experimental que tiene varios objetivos [5]:
• Evaluar el valor añadido de la nueva solución,
• Familiarizar progresivamente a los usuarios con las nuevas
soluciones,
• Identificar los cambios de usos que se producirán.
• Imaginar, a partir de esta experiencia, la estrategia de migración, es
decir, la mejor manera de pasar de la situación existente a la
situación objetivo.
D. PROYECTO PILOTO
Esta prueba de concepto es sólo una pequeña parte del proyecto de
migración, que puede servir para poner a prueba funcionalidades críticas
de la aplicación en el entorno de la nube.
A continuación debemos comprobar la viabilidad técnica de la migración,

que no prepara el proceso de migración en su conjunto [5].
En general, es preferible empezar, por ejemplo, con una pequeña base de

datos (o un conjunto de datos) [7], tomando antes las precauciones de
seguridad necesarias. Luego realizar el proceso de migración hasta el
final, y someter el sistema a los procedimientos de testeo.
D. PROYECTO PILOTO
El proyecto piloto de SaaS: La implementación de este tipo de prueba es
muy sencilla ya que se realiza íntegramente en la nube. Sólo hace falta
comprar un derecho de uso por un corto tiempo.
El proyecto piloto no tiene ningún impacto sobre el SI de la empresa: tan sólo

implica a los usuarios del software probado y permite determinar la
aprehensión de las características propuestas.
Si se trata de una nueva aplicación, el impacto sobre el SI es nulo y es posible

llevar a cabo el proyecto piloto sin ninguna participación del DSI.
Sin embargo, cuando el experimento consiste en sustituir una aplicación

existente, es necesario mantener dos sistemas operativos en paralelo a lo
largo del proyecto piloto. En efecto, debe mantenerse la reversibilidad, es
decir, la posibilidad de volver al viejo sistema para los usuarios si el
experimento sale mal [4].
D. PROYECTO PILOTO
El proyecto piloto de SaaS:
El proyecto piloto suele estar formado por tres fases:
Fase 1: Justificar la elección de un proyecto piloto de SaaS. Por ejemplo, si el objetivo

es reducir los costes y aumentar la eficiencia de las aplicaciones comerciales, es
necesario un proyecto piloto de software como servicio (SaaS).
Fase 2: Evaluar a priori el grado de adopción de software como servicio en la nube y

evaluar de una forma precisa y rápida a los vendedores de SaaS para justificar las
razones de la elección de ese tipo de prueba piloto.
Fase 3: Lanzar el proyecto piloto y analizar los resultados del experimento en la nube.
Estos resultados serán utilizados para establecer un plan de transformación seguro.
D. PROYECTO PILOTO
El proyecto piloto de IaaS: La implementación de este tipo de
prueba piloto también es sencilla. Al igual que en el caso anterior
sólo necesitamos adquirir el derecho de utilización de servicios en
la nube. Se trata de una prueba técnica que sólo involucra a los
empleados del DSI. Permite afinar [4]:
• la comprensión del modelo de costes
• el conocimiento de la plataforma: el rápido dominio del
sistema, el modo de implementación, el tiempo de
implementación de una nueva aplicación, etc.
• el conocimiento de las características específicas de la
nube: problemas de latencia de red, disponibilidad real, etc.
D. PROYECTO PILOTO
El proyecto piloto de PaaS: Esta prueba es la más complicada de
las tres.
Es necesario un enfoque basado en el diseño y en la arquitectura

reales.
Es aconsejable centrarse en una pequeña parte de una aplicación

para evitar un despliegue excesivo de recursos para la prueba
piloto.
Los riesgos y los objetivos son básicamente los mismos que para
el proyecto piloto de SaaS.
D. PROYECTO PILOTO
No existe una regla que defina la duración del proyecto piloto, que puede
ser de entre dos semanas y dos meses aproximadamente.
Contrariamente a lo que se suele pensar, la duración del proyecto piloto

depende mucho más de la dimensión del sistema (tamaño de la
aplicación, número de personas que participan en la prueba) que del
tamaño de la organización.
De hecho, el equipo de usuarios involucrados rara vez supera las veinte

personas.
La elección de estas personas es muy importante. Para asegurar el éxito

de la prueba deben ser representativos de los diferentes perfiles presentes
en la empresa.
D. PROYECTO PILOTO
Criterios Descripción:
Funcionalidad Este criterio designa todos los criterios y subcriterios relativos
al conjunto de funcionalidades. Idealmente, la cobertura
mínima en términos de requisitos funcionales es el conjunto
de características de la solución existente. Todas las
Para la evaluación de la prueba piloto, deberemos definir un conjunto de
funcionalidades
criterios y subcriterios que falten
ponderados o los de
en función nuevos elementos que
su importancia, y
aparezcan serán elementos utilizados para reducir o
utilizarlos para evaluar la solución en base a la retroalimentación de losmejorar
usuarios. He aquí una posibleCada
la evaluación. clasificación
uno de [5].
los elementos, traducidos a sub-
criterios, deberán ser ponderados según su importancia y
relevancia.
Usabilidad Este criterio se refiere a los factores humanos como la
ergonomía o la calidad de la documentación. La mayoría de
los comentarios de los usuarios se refieren a la ergonomía.
D. PROYECTO PILOTO
Criterios Descripción
Fiabilidad Este criterio cubre básicamente los conceptos de fiabilidad y
disponibilidad
Rendimiento Este criterio incluye todos los criterios y subcriterios de tiempo
de respuesta y consumo de recursos. La evaluación de la
solución sobre la base de estos criterios corresponde
básicamente a los directivos. De hecho, se trata de valorar las
limitaciones de ancho de banda de la red, las limitaciones de
espacio de almacenamiento, de las aportaciones al sistema
de archivos, etc...
Sostenibilidad Este criterio incluye elementos como la capacidad de
adaptación, la facilidad de mantenimiento, la interoperabilidad
o la portabilidad.
D. PROYECTO PILOTO
Como ya hemos indicado en la Fase 1 (toma de decisiones), es

recomendable presentar los resultados en un diagrama (por ejemplo, un
radar) para mejorar la visualización de los resultados y optimizar la
comparación entre diferentes soluciones
D. PROYECTO PILOTO
Tipos de resultados para el criterio de facilidad de integración: Ejemplos de análisis:
Los criterios de puntuación van de 1 a 4 (1: no relevante, 2: bajo, 3: suficiente, 4: más
que suficiente)
Evaluación global 2 3 4
Subcriterios
El sistema operativo Sólo windows Al menos un Varios sistemas
propuesto o sólo linux windows o un operativos y la
linux, posibilidad de utilizar
posiblemente su propia imagen.
Redhat, o la
posibilidad de
utilizar su propia
imagen
D. PROYECTO PILOTO
Tipos de resultados para el criterio facilidad de integración: Ejemplos de
análisis: Los criterios de puntuación van del 1 al 4 (1: no relevante, 2: bajo, 3:
suficiente, 4: más que suficiente)
Subcriterios
Facilidad de migración Resulta difícil Migración Migración
de aplicaciones y encontrar documentada documentada
entorno de desarrollo información Eclipse instalado o Muchas
sobre migración posibilidad de herramientas de
y sobre entornos añadirlo desarrollo
Compatibilidades Java Java, Ruby, Mobile Java, Ruby, Mobile
& Web, varias & Web, varias
herramientas, pero herramientas, listas
deben ser para usar
instaladas
D. PROYECTO PILOTO
Tipos de resultados para el criterio de seguridad:
Subcriterios
Red La presencia 2+ acceso 3+ medidas
de seguro a la red correctivas
cortafuegos
Virtualización algunas VM Muchas 3+ componentes de

posibilidades de infraestructura
VM. Control del redundantes
entorno de red
virtual. Creación
de subredes y
aislamiento
D. PROYECTO PILOTO
Tipos de resultados para el criterio de seguridad:
Subcriterios
Localización de los Oferta de 2+ elección del 3+ híbrido (con
servidores alojamiento sin servidor de entre adaptación) y
elección los propuestos. posibilidad de
privado
Privacidad de los datos simplificación Certificación ISO buen cifrado
de copias de 27001
seguridad y
restauraciones
Acceso a los datos y al Acceso a Identidad Web + 3+ contraseña
entorno través de línea contraseña y cifrada
de comandos control de los
derechos de
acceso
D. PROYECTO PILOTO
Tipos de resultados para el criterio de facilidad de uso:
Subcriterios
Consola de Difícil de usar Accesible a Muy fácil
administración través de
Internet y
bastante
intuitiva
Herramientas de Fácil acceso a Herramientas Herramientas o
informes los registros de advertencia o
visualización mensajería (tiempo
global eficaces real)
D. PROYECTO PILOTO
Tipos de resultados para el criterio de facilidad de uso:
Subcriterios
Documentación Documentación Documentación Documentación
en línea completa completa para
inexistente cada producto
foro
Facilidad de contacto con Servicio de Soporte Diferentes medios
el proveedor ayuda. telefónico en de comunicación.
Comunidad línea con Respuesta rápida
activa tiempo de
espera
indicativo
D. PROYECTO PILOTO
Cuadro resumen de los resultados: A partir de las ofertas de los proveedores
analizados, creamos una tabla resumen como esta.
Proveed Proveed Proveed Proveed Proveedo Proveed Proveed Proveed Proveedo
or 1 or 2 or 3 or 4 r5 or 6 or 7 or 8 r9
Facilidad de integración 3,0 2,3 3,0 3,0 3,7 3,7 3,0 3,3 3,0
SO 4 3 3 3 3 4 4 4 3
Facilidad de migración de las 2 2 2 3 4 3 2 3 3
aplicaciones / entorno de desarrollo
Compatibilidades 3 2 4 3 4 4 3 3 3
Seguridad 3,2 2,4 3,2 3,0 3,0 1,2 1,0 3,4 3,0
Red (cortafuegos...) 3 3 4 3 3 1 1 3 4
Virtualización (aislamiento...) 3 2 4 3 3 1 1 4 3
Ubicación del servidor (nube interna o 3 2 2 2 2 1 1 4 4
externa, en Francia o en el extranjero)
Protección de datos (cifrado... ) 4 3 3 4 3 1 1 3 2
Acceso a los datos y entornos 3 2 3 3 4 2 1 3 2
Facilidad de uso 2,8 1,5 3,8 2,8 3,5 2,8 2,8 3,3 2,8
Consola de administración 2 2 3 3 3 3 3 3 3
Herramientas para informes (presencia 3 1 4 2 4 2 3 3 3
de historial de registros de calidad,
facilidad de acceso a los registros ... )
Calidad de la documentación 3 1 4 3 4 4 3 4 3
Facilidad de contacto con el proveedor 3 2 4 3 3 2 2 3 2
D. PROYECTO PILOTO
Resultados presentados en forma de radar:

Los resultados pueden ser presentados en forma de radar como los hace
Amazon Web Services [21], que presenta las ofertas IaaS a los clientes a
través de interfaces web sencillas y comprensibles (AWS Marketplace).
El cliente selecciona una infraestructura y elige las especificaciones de las

máquinas virtuales instaladas en ella (SO, herramientas, software...).
El estudio en [21] muestra a través del radar obtenido un conjunto de

cualidades necesarias para establecer una máquina virtual funcional, calidad
de servicio, etc...)
D. PROYECTO PILOTO
Ejemplo de resultados presentados en forma de radar:

E. MIGRACIÓN
La fase de migración propiamente dicha resulta relativamente fácil siempre

que los pasos anteriores hayan sido realizados de forma seria.
Esta tarea se compone a su vez de varias fases [4]:

1. Asegurar la propiedad, dominar el uso de la plataforma y agregar nuevas
cuentas de usuarios
2. Configuración inicial
3. Minería de datos y migración
4. Migración de aplicaciones y tests
5. Fin del servicio de la solución inicial
6. Formación y apoyo al usuario
E. MIGRACIÓN
1.Dominar el uso de la plataforma y agregar nuevas cuentas de
usuarios
• Una vez terminada la negociación y una vez firmado el contrato

con el proveedor, el departamento de informática recibirá la
información necesaria para acceder a la consola de administración
de la plataforma
• Debería estar familiarizado con las características de esta consola
• A continuación hay que agregar usuarios a la plataforma y
asignarles los derechos correspondientes
• Tenga en cuenta que esto no es realmente necesario en el caso de
la migración de tipo SaaS o PaaS, y sólo hacen falta algunas
cuentas de administrador en el caso de IaaS
E. MIGRACIÓN
1. Dominar el uso de la plataforma y agregar nuevas cuentas de usuarios
Hay dos formas de hacerlo: a través de una gestión manual o automática de
las cuentas.
1.1 Gestión manual

Puede ser sencilla pero tediosa. Se adapta mejor a las plataformas con un
número reducido de cuentas (no más de 50).
En ese contexto, el administrador crea cuentas nuevas con las mismas

credenciales ya utilizadas en la empresa. Los usuarios pueden cambiar
sus contraseñas o no.
Si la política de seguridad corporativa exige un cambio regular de las

contraseñas, los usuarios realizarán ese cambio manualmente en SaaS /
PaaS.
E. MIGRACIÓN
1. Dominar el uso de la plataforma y agregar nuevas cuentas de usuarios

1.2 Gestión automática
Para las organizaciones más grandes, se recomienda optar por la gestión de cuentas
automática, a partir del sistema informático inicial de la empresa.
Para ello, el DSI utilizará las APIs facilitadas por el proveedor, la cuál se encargará de los
diferentes procesos de forma automatizada.
Con la puesta en marcha de la plataforma o con la llegada de un nuevo empleado,
las cuentas se crean y extraen directamente del directorio de la empresa.
La actualización de las contraseñas también se hace mediante una sincronización
con el directorio de la empresa, sin que sea necesaria la intervención del
administrador o del usuario.
En caso de salida de un empleado y su consecuente desaparición del directorio de
la empresa, también se eliminará su cuenta de la nube. Por lo tanto es preciso
garantizar la seguridad del canal y del protocolo utilizado en la transferencia de
información confidencial como son las contraseñas. Se suele optar por SSL,
Secure.
E. MIGRACIÓN
1. Dominar el uso de la plataforma y agregar nuevas
cuentas de usuarios:
La complejidad y la duración de esta fase depende en gran medida

del tamaño de la empresa, pero también de la arquitectura
elegida, en el caso en que varias nubes estén
interconectadas.
Por razones de seguridad y de federación de identidades, se

recomienda encarecidamente el guardar las cuentas sólo
localmente, en lo que queda del sistema informático de la
empresa. El operador de la nube delega luego la
autenticación al servicio de identidad del SI, el proveedor de
identidad.
E. MIGRACIÓN
2. Configuración inicial:
Una vez creadas las cuentas de usuario, son necesarios algunos

pasos antes de poder migrar la aplicación propiamente dicha.
El primero y más obvio es la elección de un catálogo de máquinas

virtuales que serán implementadas en el caso de IaaS, o la
elección de los servicios técnicos para su uso en PaaS.
Estas opciones que ya han sido especificadas en la fase de

diseño, son ahora reales gracias a la consola de administración de
la plataforma y a las muchas configuraciones que ofrece.
E. MIGRACIÓN
2. Configuración inicial:
A continuación realizaremos la configuración de los nombres de

dominio y de las aplicaciones DNS.
Es importante utilizar los nombres de dominio de la empresa para

asegurar la coherencia de la cartera de aplicaciones. Por ejemplo,
accederá al correo electrónico desde la dirección
http://mail.empresa.com.
Finalmente es muy recomendable configurar las APIs encargadas

de rastrear las actividades del usuario con fines de seguimiento,
siendo éstas incluso obligatorias en varias jurisdicciones.
E. MIGRACIÓN
Algunas aplicaciones necesitan datos para comenzar.
Por este motivo, y con el fin de probar las aplicaciones tan pronto
como hayan sido migradas, varios proveedores de servicios en la
nube, así como las publicaciones científicas, recomiendan
empezar por la migración de los datos.
E. MIGRACIÓN
Será necesario en primer lugar entender las necesidades de la

aplicación y las diferentes soluciones de almacenamiento propuestos
por el proveedor.
La migración a la nube puede ser también una oportunidad para

mejorar la escalabilidad del sistema de almacenamiento de la
aplicación.
Si este es uno de los argumentos en los que se basaba la decisión de

migrar a la nube, tenemos que resultará conveniente:
estudiar las bases de datos de alta escalabilidad del proveedor
o utilizar una base de datos NoSQL en ausencia de una oferta
adecuada.
E. MIGRACIÓN
3. Minería de datos y migración:
La capa de acceso a datos deberá ser adaptada y algunas bibliotecas

tendrán que ser remplazadas.
Estos cambios son a menudo necesarios ya que el proveedor no

siempre dispone de la base utilizada inicialmente.
Pero incluso si estos cambios no son necesarios o son mínimos, puede

ser muy útil transformar toda la capa de datos / acceder a los datos de
la aplicación con el fin de aprovechar al máximo los beneficios de la
nube en términos de rendimiento y escalabilidad.
E. MIGRACIÓN
• También es posible desarrollar un middleware dedicado a convertir el
formato inicial de solicitudes al formato apropiado de la nueva base de datos
• Existen ya programas de este tipo [13] que facilitan en gran medida el
cambio de base de datos, minimizando los cambios a la aplicación
• Cabe señalar que si bien estas herramientas pueden ahorrar tiempo, a
veces requieren fases de pruebas muy importantes que ponen en
entredicho sus beneficios. Esto puede ser debido a la calidad de la
traducción
• Al igual que en la gestión de cuentas de usuario, existen dos formas de
gestionar la transferencia de los datos
• en caso de que sólo se migre una aplicación y el SI de la empresa siga siendo
central, al menos por un tiempo
• o si el usuario la gestiona caso por caso de forma manual o automática
E. MIGRACIÓN
- Migración manual de datos
Los usuarios se benefician de las características de importación / exportación
en las interfaces de aplicaciones SaaS / PaaS. La importación se hará, por
tanto, caso por caso, dependiendo de las necesidades del usuario y casi
siempre utilizando el formato CSV. En este caso, la migración de datos inicial
será muy corta.
- Migración manual de datos

La información es importada directamente del sistema informático de la
empresa. Como para las cuentas, el proveedor de servicios en la nube
proporciona integraciones API para la gestión de la importación. Por tanto, el
envío de nueva información a la nube puede ser automatizado, así como la
recopilación de datos que han sido tratados en la plataforma y su eventual
repatriación al SI. Debemos tener cuidado en este segundo escenario, ya que
la importación automática de los datos al SI desde una fuente externa puede
representar un riesgo para la integridad de los datos corporativos.
E. MIGRACIÓN
En todos los casos será necesario mantener una cierta sincronización

entre los datos migrados y los datos históricos durante la fase de
transición, que no será instantánea.
E. MIGRACIÓN
4. Migración de aplicaciones y pruebas
La cuestión central en esta fase será: ¿Cómo migrar parcial o

totalmente mi sistema a la nube sin alterar o interrumpir mi
actividad?
Existen dos enfoques diferentes sobre cómo lograr una migración

efectiva. Los describimos a continuación.
E. MIGRACIÓN
• El primer método consiste en realizar una simple copia de la aplicación

actual en la plataforma de una sola vez
• Para migrar a IaaS, tan sólo es necesaria una copia de los servidores
actuales en las máquinas virtuales (por supuesto con los pasos
mencionados anteriormente: configuración de cuentas, DNS, migración
de datos)
• Para migrar, pueden ser necesarios cambios de código adicionales para
aprovechar al máximo la plataforma. Este método tiene la ventaja de
reducir drásticamente el esfuerzo de migración, con el fin de centrarse
más rápidamente en el valor añadido del negocio
• Siempre podemos volver más tarde a la arquitectura de la solución para
mejorarla, hacerla más escalable, apátrida y disponible
E. MIGRACIÓN
Un estudio académico [14] ha hecho hincapié en la importancia de contar

con un servidor en la nube que no pertenezca a ningún estado, y en las
ganancias que ello representa en cuanto a flexibilidad y rendimiento.
Con este enfoque de migración, muchas ganancias de rendimiento y

funcionalidad son aplazadas, y requerirán más reingeniería, la cuál será
probablemente más cara que si los cambios se hubiesen realizado de
forma progresiva.
Este método es recomendable para proyectos urgentes, que requieran una

respuesta rápida a una necesidad concreta, así como para aplicaciones
sencillas de un solo bloque.
Sin embargo, no se recomienda para aplicaciones muy pesadas, debido al

riesgo de tener que gestionar problemas de rendimiento.
E. MIGRACIÓN
•El segundo método es mucho más flexible y mucho menos arriesgado.

Consiste en hacer el cambio a la nube “por lotes". En lugar de migrar toda la
aplicación a la vez, se suben y optimizan las partes de una en una
•Esto reduce en gran medida el riesgo de encontrarse con un comportamiento
inesperado de la aplicación tras la migración, y es ideal para sistemas
complejos que incluyen varios bloques de aplicación
•También es adecuado para una aplicación que utilice diferentes tipos de
procesos por lotes. En ese caso los diferentes procesos pueden ser movidos
de uno en uno, mientras el resto de la aplicación permanece en el servidor
local
•Este sistema permite adaptar cada proceso a la nube, optimizando su acceso
a los datos y haciéndolo totalmente modular y escalable
•Por otra parte, es mucho más fácil probar las aplicaciones o los bloques de
proceso por lotes de uno en uno, asegurándose de su calidad antes de migrar
el siguiente. Esto asegura una gran robustez de la aplicación al final de la
migración, quedando sólo por probar ciertos aspectos funcionales
E. MIGRACIÓN
•Sin embargo, probablemente se necesitará desarrollar contenedores

específicos para cada bloque para establecer la comunicación entre
las partes de la aplicación local y los datos en la nube
•Estos contenedores son fáciles de implementar y se pueden hacer
asíncronos para aumentar la tolerancia a las latencias de la red
•Este método es necesario en casos de migración híbrida, en los que
una parte de la aplicación no puede ser migrada y permanece en la
unidad central de la empresa (ya sea por razones de seguridad o
técnicas)
•Otras dos ventajas de esta migración por lotes es la capacidad de
escalar la solicitud de forma gradual, y el aprendizaje progresivo por
parte de los usuarios
E. MIGRACIÓN
•La migración terminará con una fase de pruebas intensivas, que

deberá validar todos los casos de utilización, las características y los
nuevos componentes técnicos no probados antes de que la aplicación
sea oficialmente puesta en producción
•Es necesario realizar una "duplicación" y no un "desplazamiento"
•Sólo cuando la migración haya sido validada se podrá realizar el
cambio a la nueva aplicación. Una segunda fase piloto puede ser
necesaria justo antes del cambio para validar la solución con confianza
E. MIGRACIÓN
5. Fin del servicio de la solución inicial
•Cuando el cambio a la solución migrada haya sido completado, será

posible deshabilitar la solución de software inicial
•Sin embargo no es recomendable destruirla inmediatamente
•El servidor no utilizado no necesita ser utilizado durante esta fase de
stand-by, a menos que se conceda una importancia crítica a la rapidez
de recuperación del servicio en caso de problemas con la solución en
la nube
E. MIGRACIÓN
• Las etapas de formación y desarrollo de un servicio de apoyo a

los usuarios no suelen estar incluidas en las metodologías
• La capacitación sí que suele ser abordada pero escasamente
documentada
• La mayoría de los métodos empresariales presentan un plan de
capacitación en tecnología, pero suele estar vinculado al
software disponible en SaaS
E. MIGRACIÓN
La fase de formación de los usuarios se organiza en sesiones. Las sesiones
ofertadas a los usuarios pueden ser de dos tipos [5]:
•Formación directa de los usuarios: esta fase suele ser bastante corta:
menos de 5 sesiones de un día para unas 20 a 30 personas. También se suele
recomendar el principio del embajador (véase más adelante) Las sesiones de
usuarios tienen el espíritu general de la nueva solución y de la funcionalidad
de las herramientas seleccionadas para la migración. Estas sesiones tienen
que tener en cuenta características específicas de la empresa (por ejemplo
movilidad, modo offline...)
•Formación de embajadores: Las sesiones de "embajadores", más
completas, están destinadas a un público adulto, pero más reducido. Estos
embajadores asumen luego el papel de relés, ofreciendo asistencia a los
usuarios durante los primeros meses. En ciertos casos pueden remplazar la
célula de apoyo y proporcionar personal para el seguimiento de la formación
de los usuarios
E. MIGRACIÓN
• La fase de apoyo es un paso dedicado a los usuarios de apoyo. Se

trata de un paso que puede realizarse en paralelo a las fases de
migración y de prueba piloto. Es especialmente útil en los casos en que
la población objetivo tiene un bajo grado de autonomía técnica
• Puede ser necesaria una formación de técnicos. De hecho, los
administradores del propio sistema informático pueden no tener las
competencias necesarias para migrar una aplicación a la nube debido a
la novedad de la nueva tecnología
• Por lo tanto, los desarrolladores serán potenciales receptores de
formación antes de embarcarse en el proyecto, pudiendo ser validada
su adquisición de nuevas competencias en el PoC o el proyecto piloto
F. MEJORA Y DESARROLLO DE LA NUBE
Tras la migración de la aplicación, pueden añadirse otras fases.
Estas fases son recomendadas y explicadas tanto por los

proveedores como por los científicos estudiosos del tema.
F. MEJORA Y DESARROLLO
DE LA NUBE
Posibles mejoras a la aplicación destinadas a aprovechar al
máximo los beneficios de la nube
• El objetivo es complementar y pensar en otras formas de

beneficiarse de esta migración
• Al principio, las mejoras serán "victorias rápidas" que requieren
poco esfuerzo a cambio de una ganancia rápida
• Por lo tanto, es especialmente útil reunir a las direcciones de
negocios y operativa para reflexionar sobre estas nuevas
oportunidades que pueden maximizar el retorno de la inversión
de la migración
DE LA NUBE
Seguridad: profundizar sobre los temas ya planteados suele ser
necesario o al menos significativo, ya que muy pocas veces son nulas
las posibilidades de mejora en esas áreas
Esto es especialmente importante para ciertos proveedores que

promueven la vigilancia en todo momento, lo cual se explica tanto por
su enfoque práctico como por sus experiencias negativas con usuarios
laxos y por su reputación de plataforma segura, algo vital para ellos
F. MEJORA Y DESARROLLO DE LA NUBE
En una fase de mejora de la seguridad, es lógicamente recomendable
empezar por los puntos más sensibles de la arquitectura. Según Amazon, [7]
las buenas prácticas a aplicar son como mínimo las siguientes:
• Establecer una rotación automática de las credenciales de acceso a la
plataforma
• Forzar dicha rotación cada vez que se detecte una brecha
• Aplicar una gestión rigurosa de los derechos y de la política de
usuarios
• Poner al día dicha política con cada nueva versión
• Cifrar los datos sensibles y garantizar su transferencia a través de
canales seguros
• Establecer un sistema de versiones y hacer copias de seguridad
periódicas
• Probar de forma ocasional dichas copias de seguridad sin esperar a
que sean necesarias
DE LA NUBE
• Naturalmente, cualquier mejora o uso adicional debe ser probado
antes de ser validado y puesto en producción
• Para aplicaciones de un cierto tamaño, las pruebas deben ser
automatizadas y ejecutadas para cada nueva versión para evitar
su obsolescencia
• Dichos procedimientos automáticos también deben ser migrados a
la nube y adaptados, o en caso de necesidad, diseñados
• También es necesario hacer algunas pruebas de carga de la
aplicación, y al mismo tiempo probar los recursos de este tipo que
ofrece la nube. Estas pruebas pueden conducir a una fase de
optimización
G. OPTIMIZACIÓN
Existen múltiples formas de optimizar una plataforma de servicios en la
nube:
•Para aprovechar al máximo la elasticidad, es muy recomendable para

todos los actores establecer un sistema de "auto-escalado" si no está
disponible por defecto
•Es posible adaptar la estructura de la arquitectura y almacenamiento
de la aplicación para mejorar su eficacia, su escalabilidad y su
adaptación a la nube mediante el uso de las APIs del proveedor
•También es muy recomendable desarrollar cuadros de mando y otras
herramientas de supervisión de la plataforma para disponer de los
indicadores de rendimiento necesarios
•También con el fin de optimizar y mejorar la plataforma, puede resultar
muy útil implementar la solución a través de múltiples sitios para
mejorar la disponibilidad
4. ELECCIÓN DE LA ESTRATEGIA DE MIGRACIÓN
ELECCIÓN DE LA ESTRATEGIA DE
MIGRACIÓN
• Es pertinente la pregunta"¿Cómo elegir una estrategia adaptada a

una necesidad?"
• Google proporciona un método que permite elegir entre diferentes
estrategias de migración [5]
• Las diferencias están, en el alcance del enfoque, es decir que las
diferentes estrategias incluyen más o menos pasos dependiendo
del tipo de empresa
• Las estrategias son cinco y están ordenadas desde de la más
básica a la más compleja
MIGRACIÓN
Tipo de estrategia Fases Público interesado
Estrategia 1.Estudio Este tipo de migración se refiere a las pequeñas
“Flash” 2.Migración empresas con un bajo nivel de dependencia del
SI y que tienen recursos humanos autónomos
desde el punto de vista técnico
Estrategia “Do it 1.Estudio Este tipo de estrategia también es apropiado para
yourself” 2.Formación pequeñas empresas. Pero la diferencia es que es
3.Migración necesario asegurar la formación de algunos de
sus actores para que ellos mismos realicen la
migración
Estrategia “Light” 1.Estudio Esta estrategia se adapta a las pequeñas y
2.Prueba medianas empresas a las que podemos
piloto proporcionar formación en materia de migración.
3.Formación Si existe una gran dependencia respecto de un
sistema informático, puede merecer la pena
4.Migración hacer una prueba piloto
MIGRACIÓN
Tipo de Fases Público interesado
estrategia
Estrategia 1.Estudio Esta estrategia es la que mejor se adapta a
"Estándar" medianas y grandes empresas. Además de
2.Prueba piloto
3.Soporte la realización de una prueba piloto, puede
resultar necesario organizar un soporte
4.Formación dedicado debido al nivel técnico de los
5.Migración usuarios y a su importancia numérica
Estrategia 1.Estudio En este caso se trata de grandes empresas.
"Advanced" 2. Plan de reversibilidad La dependencia del sistema de información
3.Prueba piloto es importante. Requiere no sólo la
realización de una prueba piloto, sino una
4.Soporte fase específica con un plan de
5.Formación reversibilidad que permita minimizar el
6.Migración riesgo de fracaso de la migración. Suele ser
7.Integración avanzada necesaria la implementación de un soporte
dedicado
5. HERRAMIENTAS
HERRAMIENTAS PARA MIGRAR DE UNA
NUBE A OTRA
• El RiverMeadow Cloud Migration SaaS es una herramienta que
permite migrar aplicaciones de una nube a otra
http://www.rivermeadow.com/
• Para la mejora de la interoperabilidad de nubes con
herramientas de migración de aplicaciones, consultar este
documento
http://searchcloudcomputing.techtarget.com/tip/Improving-
cloud-interoperability-with-application-migration-tools
• El siguiente documento describe cómo los proveedores afectan
a la migración de aplicaciones a la nube
http://searchcloudcomputing.techtarget.com/tutorial/How-providers-
affect-cloud-application-migration
REFERENCIAS
[1] S. Caicoya et J.G Saury, “Cloud Computing - Le guide complet”, Micro Application, Août 2011.
[2] J.F. Zhao et J.T. Zhou, “Strategies and Methods for Cloud Migration”, College of Computer Science,
Inner Mongolia University, Chine, [En ligne]. Abril 2014.
http://link.springer.com/article/10.1007%2Fs11633-014-0776-7#page-1
[3] A. Khajeh-Hosseini, D. Greenwood et I. Sommerville, “Cloud Migration: A Case Study of Migrating

an Enterprise IT System to IaaS”, Cloud Computing Co-laboratory, School of Computer Science,
University of St Andrew, UK, [En ligne]. Febrero 2010.
http://arxiv.org/ftp/arxiv/papers/1002/1002.3492.pdf
[4] G. Plouin, “Cloud Computing - Sécurité, stratégie d’entreprise et panorama du marché”, Dunod, 3e
édition, juin 2013.
[5] M. Alves, P. Cadet, P. Lemberger et M. Morel, “Intégrer Google Apps dans le SI”, Dunod,
Septembre 2010.
[6] Mark I. Williams, “A Quick Start Guide to Cloud Computing: Moving Your Business into the Cloud”,
Kogan Page, Novembre 2010.
REFERENCIAS
[7] J. Varia, “Migrating your Existing Applications to the AWS Cloud”, Amazon Web Services, [En
ligne]. Octubre 2010. http://media.amazonwebservices.com/CloudMigration-main.pdf
[8] J. Weinman, “Cloudonomics: The Business Value of Cloud Computing”, John Wiley & Sons, Inc.,
Septembre 2012.
[9] R. Buyya et J. Broberg, A. M. Goscinski, “Cloud Computing: Principles and Paradigms”, Wiley-
Blackwell, Mars 2011.
[10] Cloud Security Alliance, “Security Guidance for Critical Areas of Focus in Cloud Computing”, CSA,
[En ligne]. Abril 2009. https://cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf
[11] J. Varia, “Architecting for the Cloud: Best Practices”, Amazon Web Services, [En ligne]. Enero
2011. https://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf
[12] P. Jamshidi, A. Ahmad, et Claus Pahl, “Cloud Migration Research: A Systematic Review”, IEEE
Transactions on Cloud Computing, Vol. 1, No. 2, Juillet-Décembre 2013.
[13] T. Laszewski et P. Nauduri, “Migrating to the Cloud - Oracle Client/Server Modernization”, Oracle,
[En ligne]. 2012. http://www.oracle.com/technetwork/articles/cloudcomp/migrating-to-the-cloud-chap-3-
495856.pdf
REFERENCIAS
[14] C. Pahl et H. Xiong, “Migration Clouds – Migration Process and Architectural Concerns”, Irish
Centre for Cloud Computing and Commerce, Dublin City University, Irelande, [En ligne]. 2013.
http://doras.dcu.ie/19227/1/MESOCA13.pdf
[15] http://www.itbusinessedge.com/slideshows/show.aspx?c=90128
[16] http://www.gartner.com/newsroom/id/1684114
[17] http://everware-cbdi.com/ampsoc
[18] http://softwarestrategiesblog.com/2011/07/20/rethinking-cloud-roi-from-a-customers-perspective/
[19] Picard Johan, Courlet Juliette, Khalid Lamrini El Hariri, internal report literature review,La
migration vers le cloud, 39p, INSA LYON, January 2015
[20] http://www.it-expertise.com/le-cloud-computing-prive-au-service-des-metiers/
[21]Estelle Bissay, Flavia Chis, Caroline Monin, Charlotte Pigeon, « Étude de solutions de cloud »,
specific project, INSA LYON, January 2014

Module4 02 Migration Methodology

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Module4 02 Migration Methodology

Cargado por

Copyright:

Formatos disponibles

Módulo 4 objetivos

El objetivo de este módulo es proporcionar al

En el proceso de toma de decisiones, conviene expresar en primer lugar las

Además hay que evaluar el retorno de la inversión (ROI), hacer un análisis de

"Cuando el Director General da la orden 'Muevan algunas aplicaciones a la

Podríamos añadir una 6a opción a la lista de Gartner [15] [16].

-Data Rehost : Mover los datos a la nube.

Consiste en transferir datos empresariales a sistemas de almacenamiento más

Se llama DaaS (Data as a Service).

Este tipo de migración puede utilizarse cuando la empresa necesita información

Desde el nivel local a la nube

Desde una nube a otra (privada, pública)

Complejidad de la Fácil Moderada Difícil

• Vuelve a implementar la aplicación en un entorno físico diferente y

Implementación en la Implementación en una

Ocurre a nivel PaaS [15] [16].

En este caso el código existente se deja de lado y se procede a reconstruir la

De hecho la migración a SaaS solo implica la migración

Análisis de costes •¿Proporciona la plataforma en la nube un buen ROI (teniendo en cuenta

Sostenibilidad del •¿Es el proveedor de servicios en la nube sostenible? ¿solvente?

Cumplimiento •¿Es adecuado el modelo de nube para el sector de la empresa?

Aplicaciones •¿Permite la plataforma en la nube disponer con mayor frecuencia

Accesibilidad •¿Posibilita la plataforma la oferta de aplicaciones más accesibles a

Agilidad de los estudios •¿Permite la plataforma en la nube ahorrar tiempo

Gestión del cambio •¿Son aceptables los nuevos métodos de trabajo

Criterios Subcriterios Comentarios

•Después de analizar el proceso con ayuda de la tabla

1.El punto de vista del legislador

•Cuando una empresa se propone migrar a la nube la información de sus

•Debemos comprobar, por ejemplo, si esa migración implica o no restricciones

2. El punto de vista del usuario:

3. El punto de vista de los informáticos expertos:

Área Ventajas Impactos Cambios necesarios

OPEX: Gastos operativos

Área Ventajas Impactos Cambios necesarios

Responsable Reorientación Nuevos problemas de Aprobación de los operadores de

Análisis Agilidad Limitaciones de Creación de un centro de

Producción Agilidad Reducción en el Certificación del operador de la

• Si la decisión de migrar a la nube es favorable, se debe hacer

1. La elección del tipo de nube y del proveedor

•También está la cuestión de elegir entre una nube privada, pública

Los riesgos generales incluyen también:

•Los riesgos relacionados con la seguridad han sido identificados y

Esta fase se divide en 4 partes:

1. Creación de un árbol de dependencias y de una tabla de

Los métodos con más información sobre este tema, como el de

-Y clasificar las aplicaciones de acuerdo con sus dependencias,

En esta etapa, podemos clasificar las

Aunque no se suele mencionar, el mapeo parece una buena

Para configurar una plataforma de informática en la nube mediante

puede puede puede

ser ser ser

Integración con el SI Funcionalidades estándar Recursos físicos

Elegibilidad para la nube: categorización de aplicaciones

Implementar los cambios de código requeridos en la aplicación elegida

A continuación debemos comprobar la viabilidad técnica de la migración,

En general, es preferible empezar, por ejemplo, con una pequeña base de

El proyecto piloto no tiene ningún impacto sobre el SI de la empresa: tan sólo

Si se trata de una nueva aplicación, el impacto sobre el SI es nulo y es posible

Sin embargo, cuando el experimento consiste en sustituir una aplicación

El proyecto piloto de SaaS:

El proyecto piloto suele estar formado por tres fases:

Fase 1: Justificar la elección de un proyecto piloto de SaaS. Por ejemplo, si el objetivo