Migracion de Sistemas Computacionales

MIGRACIÓN DE SISTEMAS COMPUTACIONALES
Naguanagua, Junio 2015
Universidad de Carabobo
Facultad Experimental de Ciencias y Tecnología
Departamento de Computación
Metodologías para la Evaluación del Desempeño de
Sistemas Computacionales
Realizado por:
Carlos Gómez CI: 21254227
Jesús Jiménez CI: 23421010
Presentado a:
Dra. Mirella Herrera

Migración de Sistemas Computacionales
Durante el ciclo de vida de un software, puede surgir la necesidad de modificarlo para
ejecutarse en un entorno diferente. A fin de migrar un sistema a un entorno diferente, se debe
determinar las acciones necesarias para lograr la migración, y luego desarrollar y documentar
los pasos requeridos para efectuar la migración.
Específicamente, se puede definir la migración de sistemas como el conjunto de
actividades para actualizar, modificar o eliminar equipos informáticos y recursos
relacionados a la tecnología y sistemas de información incluyendo el área de
telecomunicaciones. Tiene por finalidad el traslado del sistema a un nuevo ambiente
operativo, conservando su funcionalidad y datos originales. En todos los casos se persigue
posibilitar el mantenimiento y posterior adecuación a nuevos requerimientos.
Entre las causas por las cuales se realiza migración de sistemas destacan las siguientes:
● Ya no existe soporte para el sistema actual.
● No son suficientes las capacidades del hardware actual.
● El mantenimiento del sistema actual resulta ser muy costoso.
● El sistema actual puede no ser compatible con nuevas tecnologías que se desee
incluir.
Es importante acotar que la migración no debe efectuarse sólo con el propósito de
solventar las situaciones anteriores, lo más ideal sería efectuar la migración antes de
presentarse la situación para así prevenirlas.
La migración es un proceso de cambio que puede efectuarse tanto en los elementos del
software como del hardware. Toda migración incluye una serie de pasos a seguir:
● Determinación de la causa de la migración – Recolección de datos.
● Planificar el momento y procedimiento de migración.
● Evaluar los resultados de la migración.
Un proceso de migración no puede darse sólo con la sustitución del software, pues están
involucrados factores de preparación y previsión que deben ser tenidos en cuenta. Todas las
migraciones deben basarse en una cuidadosa planificación para evitar posibles pérdidas de
información o funcionalidad.
Antes de tomar cualquier decisión, hay que tener en cuenta cuáles son las
funcionalidades del nuevo software. Cuando se tienen varias opciones, los responsables del
proceso de migración deben conocer las ventajas e inconvenientes de cada producto. Se

aconseja consultar a los usuarios y explicarles las razones por las que se va a llevar a cabo la
migración y cómo les afectará, para ayudar al éxito del proceso.
Más allá de la migración:
Para solventar los problemas antes planteados, no solo se cuenta con la migración. De
hecho se han propuesto diferentes soluciones que se pueden agrupar en dos categorías,
además de la migración:
a) Reconstrucción:
La reconstrucción implica reescribir las aplicaciones existentes, y dependiendo de la
documentación y conocimiento disponible sobre el sistema actual, puede tratarse desde una
reingeniería hasta el rediseño de un sistema completamente nuevo. Esto último ya fue
referido como abandono del sistema para su sustitución por otro nuevo.
b) Encapsulamiento:
Con encapsulamiento se hace referencia al desarrollo de una envoltura de software
(wrapper) sobre la aplicación existente, con el fin de dotarlo de interfaces con componentes
periféricos que permiten sacarlo de su aislamiento.
La primera es muy poco probable que sea una verdadera opción. La solución casi
siempre recae sobre el encapsulamiento o la migración. El encapsulamiento se puede más
como una solución temporal al problema, quedando la migración como la opción que
verdaderamente representa solidez y previsibilidad futura.
En efecto, en situaciones donde por diferentes motivos se descartan las opciones de
reconstrucción y de encapsulamiento, la migración del sistema a un ambiente abierto se
convierte en la mejor alternativa. Si bien esta es la opción más compleja, las ventajas que se
obtienen a largo plazo justifican ampliamente el esfuerzo que será requerido.
Aquí debe reconocerse que un trabajo de migración es normalmente un proyecto de
ingeniería de sistemas, que por su importancia merece el calificativo de crítico. Esto es así
tanto por la relevancia de los entornos migrados (datos y aplicaciones), que deberán ofrecer
finalmente la misma eficiencia y operatividad que ofrecían en el entorno anterior, como así
también por la necesidad de hacer mínimo el impacto en todos los niveles de la organización.
Se hace referencia aquí al objetivo de enfrentar un cambio de cultura tecnológica, para el que
habrá que prever recursos técnicos y humanos, y que deberá ser acompañado del necesario
entrenamiento del personal y usuarios.
Además, durante el proceso de cambio del sistema será muy importante prever cuál será
la gestión de su evolución posterior; con el fin de evitar que la situación presente vuelva a
repetirse o al menos resulte menos traumática. La gestión de la evolución debe consistir en el
ofrecimiento de una respuesta rápida, preparada y eficiente a los cambios que se produzcan
en el entorno, ya sean de índole tecnológica o de gestión del propio negocio.

Estrategias de migración
Las estrategias de migración reconocen los dos enfoques siguientes:
a) Habilitación gradual:
La nueva aplicación es construida gradualmente en la plataforma de destino, haciéndose
cargo en forma progresiva de las funcionalidades de la aplicación original, por lo que en este
proceso ambas aplicaciones están integradas en un único sistema con una transferencia
gradual de responsabilidades de una a otra. Con este enfoque la información está duplicada y
es necesario un importante esfuerzo de coordinación para asegurar la integridad y
consistencia de los datos.
b) Habilitación súbita:
La aplicación original mantiene todas sus prestaciones mientras la aplicación en la nueva
plataforma es construida, implementada y probada. Las bases de datos de esta última son
progresivamente actualizadas hasta el momento en que se decide la transferencia del control,
momento en que la aplicación original queda desafectada y sus bases de datos quedan como
referencia únicamente para consulta. Se debe tener en cuenta que antes del desarrollo del
nuevo sistema, es imprescindible tener una comprensión intensiva del sistema a ser migrado.
En cualquier sistema a ser migrado, algunas características son comunes con todo
proyecto de ingeniería de software, tales como metodología de desarrollo, testing y selección
del modelo de bases de datos. Otras, son específicas de la migración, por lo que se puede
clasificarlas en dos grandes categorías: aquellas que conciernen al sistema a migrar, y, las
específicas del sistema migrado, para lo cual es necesario entender las características
intrínsecas de los datos, las interfaces y las aplicaciones involucradas, en cualquier proceso
de migración.
Consecuentemente, antes de tomar cualquier decisión sobre la estrategia de migración, se
debe realizar un estudio intensivo a los efectos de cuantificar los riesgos y beneficios, con el
fin de justificar acabadamente la migración a un nuevo sistema, según lo proponen Espiñeira
y Sheldon (2005).
Los pilares de todo el proceso de migración:
Una migración debe apoyarse en tres pilares básicos, a saber: 1) una metodología, 2) un
conjunto de herramientas y 3) técnicas de pruebas y personalización. La metodología
garantiza, en primer lugar, un procedimiento sistemático que asegura que el trabajo realizado
sea controlable y sus resultados predecibles. En segundo lugar, que se dispone de un
repositorio con toda la información necesaria para abordar la migración: cadenas de
programas, programas fuente, estructura de bases de datos, librerías de funciones, etc. En
tercer lugar, contempla la obtención del modelo de negocio a migrar, a partir de la
información contenida en el repositorio, y considera además la realización de los planes de
prueba de las aplicaciones migradas. Por último, define las reglas de generación del código
migrado, conforme a los estándares establecidos, las librerías de funciones usadas y cualquier
otra consideración de interés. Las herramientas de migración permiten obtener un modelo del
negocio a migrar, que lo hace independiente de los lenguajes de las aplicaciones, con lo cual

el modelo obtenido resultará válido en caso de ser necesarias futuras migraciones a otras
tecnologías. Estas herramientas deben permitir, también, la incorporación de las reglas
básicas del negocio a los efectos de obtener aplicaciones optimizadas para su funcionamiento
en el entorno informático existente en una empresa.
Las técnicas de pruebas y personalización incorporan las reglas de generación
introducidas por la metodología a los fines de obtener aplicaciones funcional y
operativamente fiables y las optimizan para su funcionamiento en el entorno informático
existente en la empresa.
La utilización de estos tres pilares permite asegurar el éxito del proyecto, manteniendo
los plazos y costos de realización dentro de las previsiones.
Metodologías para la migración de sistemas:
ISO/IEC 14764
Éste estándar internacional titulado “Ingeniería de Software – Proceso del ciclo de vida
del software – Mantenimiento”, describe los requerimientos para el mantenimiento del
software. En la sección 5.5 de este estándar, se define y plantea una metodología para la
migración de software como parte del proceso de mantenimiento del software así como
también otras actividades que se deben realizar antes y después del proceso de migración.
Entradas El antiguo entorno
El nuevo entorno
Proceso Plan de Migración
Para que se pueda controlar de forma adecuada la migración de un sistema, se
debe crear un plan de migración, además de documentarlo y ejecutarlo. Las
actividades de planificación deberían incluir:
● Análisis de requerimientos y definición de la migración
● Desarrollo de herramientas de ayuda a la migración
● Conversión de datos y productos software
● Ejecución de la migración
● Verificación de la migración
Notificación del intento
a) Declaración de por qué el antiguo entorno ya no se va a soportar.
b) Descripción del nuevo entorno, con su fecha de disponibilidad.

c) Descripción de otras opciones de soporte disponibles, una vez que el apoyo
al antiguo entorno se ha retirado.
Implementación de las operaciones y entrenamiento
Operaciones paralelas del antiguo y el nuevo entorno se pueden llevar a cabo
para facilitar la transición al nuevo ambiente. Durante este
periodo, se proporcionará la formación necesaria
Notificación del final
Cuando llega la migración programada, la notificación se enviará a todos los
interesados.
Revisión post-operación
Una revisión posterior a la operación se realiza para evaluar el impacto del
cambio al nuevo entorno.
Archivado de datos
Los datos utilizados por o asociados con el entorno anterior, deberán ser
accesibles de acuerdo con los requisitos del contrato de protección de datos y
de auditoría aplicables a los datos.
Soporte
Se basa en los procesos de la norma ISO/IEC 12207.
Salidas Plan de Migración
Herramientas de Migración
Notificación de Intentos
Producto Software Migrado
Notificación de Finalización
Datos archivados
Guía para el Plan de Migración a Software Libre en la Administración Pública
Nacional (APN) de La República Bolivariana de Venezuela:
Esta guía fue desarrollada por el Centro Nacional de Tecnologías de Información con
el fin de servir de referencia a diferentes Entes Gubernamentales que requieran migrar su
Plataforma Tecnológica de Información desde un entorno de Software Propietario a un

entorno basado en el Software Libre para el uso y/o prestación de servicios de Tecnologías de
Información y Comunicación (TIC).
Esta guía propone las siguientes fases para la migración efectiva:
Fase Actividades
Recolección de Información Esta fase brindará los datos necesarios que hacen falta
para empezar todo el proceso de migración, para esto se
deben tomar en cuenta 3 aspectos principales que
influyen directamente en la Plataforma Tecnológica e
Informática de cualquier ente o institución:
● Inventario de Capital Humano.
● Inventario del Hardware utilizado en la
institución.
● Inventario del tipo de Software que utiliza la
institución.
Capacitación Uno de los puntos claves en el proceso de migración es
el entrenamiento que se le debe proporcionar a los
usuarios, el mismo debe contribuir a que el factor de
resistencia al cambio sea lo más bajo posible y las
metodologías de aprendizaje a utilizar deben incentivar
a la autoformación e investigación.
La capacitación se divide en dos tipos:
● Capacitación del personal técnico.
● Capacitación del usuario final.
Migración Parcial La Migración Parcial contempla el combinar el uso de
sistemas operacionales propietarios con la instalación
en éstos de herramientas de software libre que así lo
permitan, ir recopilando información mediante ensayos,
pruebas o investigación acerca de las herramientas y
aplicaciones de software libre que más se adapten a la
plataforma deseada, identificación de los servicios
ofrecidos a los usuarios y las características de la
plataforma que los soporta.
Migración Total La Migración Total contempla el cambio total del

sistema. Se migran todos los servicios y se diseñan
herramientas Open Source.
Soporte posterior a la migración Se refiere a la resolución de problemas de primer nivel
que pueda tener el usuario al momento de operar el
equipo ya migrado.
Debe existir un personal de soporte técnico encargado
de resolver estos problemas. La cantidad de personal
técnico por usuario dependerá del tipo y eficiencia de la
plataforma tecnológica de la institución, del tipo de
aplicaciones que utilice y del plan de atención al
usuario que se diseñe.
Documentación de la migración Se deberá documentar todo el proceso paso a paso
resaltando las experiencias que se consideren relevantes
y que puedan ser de utilidad en migraciones a realizar
en otros entes u organismos gubernamentales. Se
deberá documentar todas las pruebas realizadas en el
laboratorio (pruebas de hardware y pruebas de
software), de manera que pueda ser utilizada como
material de apoyo y/o referencia para otras
instituciones. La documentación de estas pruebas
permitirá elaborar un manual de procedimientos y/o
protocolos de pruebas, para usar en el laboratorio. La
documentación deberá realizarse en un formato
estándar, donde se detalle:
● Descripción de la actividad realizada
● Objetivo y resultados obtenidos, estos servirán
como protocolos de pruebas para futuras
aplicaciones y hardware que necesite ser
verificado.
También deberá realizarse un documento donde se
definan las políticas de uso interno del laboratorio.
ITIL v3:
ITIL, Según la organización CA Technologies se ha convertido rápidamente en el
estándar de mejores prácticas para la administración de servicios y en el lente a través del
cual se visualiza y mide el valor de los servicios. Aunque las tasas de adopción varían, no hay

duda de que muchas organizaciones de TI están recurriendo a ITIL en un intento por mejorar
la calidad y rentabilidad de los servicios que brindan al negocio.
El ciclo de vida ITIL esta compuesto por:
 Estrategia del Servicio (Service Strategy)
 Diseño del Servicio (Service Design)
 Transición del Servicio (Service Transition)
 Operación del Servicio (Service Operation)
 Perfeccionamiento Continuo del Servicio (Continual Service Improvement)
El módulo de migración (manual) está dividido en los ciclos de vida ITIL para su fácil
desarrollo y trazabilidad de los pasos a desarrollar, en cada uno de los procesos y su
ejecución.
1. Service Strategy: En el ciclo de vida Service Strategy es el encargado de toda la
evaluación estratégica a seguir paso por paso, esta muestra la conformación del proyecto,
como visualizarlo y ejecutarlo para todos los otros ciclos de vida ITIL.
Service Strategy
Gestión Financiera
Gestión del Portafolio de Servicios
Gestión de la Demanda
2. Service Design: En el ciclo de vida ITIL Service Design se planea el proceso que se
pensó en ciclo de vida ITL Service Strategy y ponen los puntos de acción que se deben llevar
a cabo y como ejecutarla en este ciclo de vida todos los procesos son válidos ya que cada uno
toca una parte esencial de cómo se lleva a cabo la migración.
Service Design
Gestión del Catálogo de Servicios
Gestión de la Capacidad
Gestión de la Disponibilidad
Gestión de la Seguridad de la Información
Gestión de Proveedores

3. Service Transition: En el ciclo de vida ITIL Service Transition es el encargado de
hacer el tránsito de del diseño a la puesta en marcha, la gestión de cambios no aplica ya que
la migración no se hace estado de operación, y el resto de procesos si aplica.
Service Transition
Planificación y Soporte a la Transición
Gestión de Cambios
Gestión de la Configuración y Activos del Servicio
Validación y Pruebas
Evaluación
Gestión del Conocimiento
4. Service Operation: En el ciclo de vida ITIL Service Operation se pone en marcha
todo lo diseñado y se gestiona para no tener inconvenientes en la operación, el modo de
ejecución es con el personal de soporte.
Service Operation
Gestión de Eventos
Gestión de Incidencias
Gestión de Peticiones
Gestión de Problemas
Gestión de Accesos
5. Continual Service Improvement: En el ciclo de vida ITIL Continual Service
Improvement se generan los informes correspondientes para ser evaluación y generar un plan
de mejora.
Continual Service Improvement
Proceso de mejora de CSI
Informes de servicio

Proyecto sourcePYME:
A través de éste se busca promover los beneficios del software libre. Está coordinado por
AIMME en cooperación con AIMPLAS, ITI y UPV y promovido por el IMPIVA. El
proyecto, aparte de colaborar en la adaptación de software ya existente y facilitar su
implantación en las pymes de estos sectores, ha desarrollado una guía de buenas prácticas
para la migración desde sistemas propietarios.
La guía plantea las siguientes fases:
Requisitos
Un factor crucial para el éxito de la migración es el análisis en profundidad de la
situación de partida. Esta tarea usualmente consumir a gran parte de los recursos iniciales del
proyecto, tanto en tiempo como en mano de obra. De todas maneras, un conocimiento
detallado de los documentos o las aplicaciones de base de datos evita realizar ajustes
imprevistos durante la migración y permite el establecimiento de planes de actuación con
suficiente antelación. Además, la determinación de la situación de partida es también la base
para identificar los requisitos funcionales del nuevo sistema.
Aspectos importantes a tener en cuenta en este contexto incluyen, por ejemplo, los
siguientes:
 Bases de datos y estructuras de datos
 Documentos y formatos de documentos
 Aplicaciones y sus interfaces
 Funcionalidades disponibles
 Disponibilidad de datos y aplicaciones
 Atajos y problemas
 etcétera
En este punto se da una visión global de qué es lo que debemos saber sobre la empresa,
sus sistemas de información y su funcionamiento, para maximizar las posibilidades de éxito
en una migración a software libre.
La fase de requisitos se divide en los siguientes puntos:
1. Estado actual
1.1. Descripción general de la empresa
1.2. Aspectos técnicos
1.3. Aspectos de recursos humanos
1.4. Aspectos Legales
1.5. Recursos temporales
1.6. Recursos económicos
2. Objetivos

Planificación
Una vez se ha llevado a cabo la toma de requisitos, ya se conoce perfectamente el estado
de la empresa en cuanto a software se refiere. Es el momento de empezar a planificar la
estrategia que se va a seguir para llevar la migración a buen término y lograr los objetivos
establecidos en el punto anterior.
El trabajo del proyecto comienza estableciendo un plan que describa el camino a seguir
para llegar al objetivo. El plan de migración debería contener como mínimo la siguiente
información: fecha final del proceso de migración, recursos materiales y humanos,
participación de terceras partes, hitos durante el proceso de migración y costes. La
planificación del proyecto es también la base para una gestión eficiente de la migración.
Este es el momento de tomar decisiones en base a la información recogida y de estas
decisiones depende en gran medida el éxito de la migración.
La fase de planificación se divide en los siguientes puntos:
1. Planificación técnica
1.1. Cosas a tener en cuenta
1.2. Inventario
1.3. Diagrama de red
1.4. Diagrama de estructura
1.5. Elección de la estrategia de migración
2. Planificación de comunicaciones
3. Planificación de recursos humanos
3.1. Miedo a lo desconocido
3.2. El temor de que el CV pierda importancia
3.3. Saber es poder
4. Plan de contingencia
5. Planificación temporal
5.1. Planificación de pruebas
6. Plan de evaluación
7. Planificación económica
Implantación
Ha llegado el momento de poner en práctica todo lo que se ha estado planificando,
cuantos más recursos se hayan dedicado a la planificación del proyecto, menos incidencias se
encontrarán a la hora de ponerlo en marcha y realizarlo. En este punto se debe empezar a
ejecutar paso a paso todas las tareas planificadas, formación e implantación técnica.
La fase de implantación se divide en los siguientes puntos:
1. Formación
1.1. ¿Cómo realizar la formación?
2. Implantación técnica
2.1. Instalando muchos equipos
2.2. Migrando datos de usuarios a sistemas GNU/Linux

2.3. Realización de copias de seguridad
2.4. Emulación de aplicaciones
2.5. Servidores de archivos
2.6. Bases de datos
2.7. Sistemas de monitorización y administración
2.8. Otros elementos a migrar
3. Consejos de implantación
3.1. Introducir nuevas aplicaciones en un entorno familiar
3.2. Lo fácil primero
3.3. Mirar hacia adelante
Evaluación
Ejecutar el plan de evaluación y continuar monitorizando el sistema en el tiempo
identificando carencias o mejoras para incrementar paulatinamente la calidad del sistema de
información de la empresa.
Para evaluar si la migración ha tenido éxito, podemos valorar los siguientes puntos:
 ¿Se ha migrado el Sistema Operativo de manera satisfactoria?
 ¿Se han migrado las aplicaciones?
 ¿Se han adaptado los usuarios?
 ¿Se ha mejorado con el cambio?
Directrices IDA de migración a software de fuentes abiertas:
Este documento fue desarrollado por European Comunities y adaptado al español por la
Comisión Europea y el Ministerio de Administraciones Públicas de España. El objeto de estas
directrices es doble:
1. Ayudar a los Administradores a decidir si se debe emprender una migración a
OSS (Open Source Software).
2. Describir en lenguaje técnico claro cómo se debería llevar a cabo dicha
migración.
Estas directrices van dirigidas a gestores y profesionales de Tecnología de la Información
(TI) que estén planificando o ejecutando una migración a software de fuentes abiertas (OSS).
Se basan en la experiencia práctica de los autores y en el contenido de un número limitado de
experiencias públicamente accesibles. Estas directrices se han validado en el proceso de
migración a OSS realizado por el Tribunal de Cuentas de Schwerin en el Lander alemán de
Mecklenberg Vorpommern.
Cualquier ejercicio de migración debe incluir, en general, lo siguiente:
1. Una fase de definición del proyecto y de recopilación de datos, en la que se
contemplen:
A. La descripción del conjunto de condiciones iniciales relevantes consistentes,
por ejemplo, en:

a) arquitectura o arquitecturas de los sistemas,
b) aplicaciones y sus datos asociados,
c) protocolos y normas empleados,
d) hardware,
e) el entorno físico, como el ancho de banda de la red, la ubicación,
f) los requisitos sociales como el idioma o idiomas y la capacitación del
personal;
B. Un conjunto de condiciones finales con el mismo detalle,
C. Una descripción de cómo llegar de las condiciones iniciales a las condiciones
finales;
2. Una justificación de la migración, incluido el coste asociado a la misma;
3. Una o más fases piloto preparadas para probar si el plan y la justificación funcionan.
Los datos de estas fases piloto pueden luego alimentar el modelo de costes usado en
el plan,
4. Despliegue del plan
5. Seguimiento de la experiencia real en relación con el plan.
Metodología Caso de estudio – Estrategia Reactiva:
El autor presenta una estrategia para casos donde la necesidad de migrar sea por una
situación imprevista. Aunque estas situaciones son muy variables se pueden marcar ciertos
lineamientos en común para abordar las mismas.
1. Notificación del problema: El cliente reporta un problema que puede ser del
hardware, de software o la combinación de ambas. El especialista debe tratar de
obtener:
- Breve descripción de la situación.
- Número y Mensaje que arroja el sistema.
2. Descripción del ambiente:
- Describir la plataforma software instalada, con un nivel de detalle en el
que se conozcan las versiones y “releases” instalados, de cada uno de los
subsistemas manejados.
- Determinar si en la instalación se han realizado modificaciones propias a
los estándares del producto.
- Describir la configuración del hardware e interconexiones.
3. Determinación detallada del problema:
- Elaborar un diagnóstico lo más exacto y detallado posible del problema.
4. En búsqueda de una solución factible:
- Apelar a la experiencia y memoria del o los especialistas de servicio a
cargo del problema.
- Buscar en las Bases de Datos de Fallas reportadas, para conocer si ha
ocurrido una falla del tipo en cuestión.
- Consultar a los laboratorios de desarrollo de productos, con una espera
máxima de 48 horas para la respuesta. Mientras se espera, de ser posible,

debe proveerse al cliente una solución momentánea para que al menos
preste servicio a las aplicaciones más importantes para la instalación.
5. Plan de acciones para la solución:
- Cambiar valores en algunos parámetros.
- Aplicar correctivos al producto.
- Cambiar los índices de rendimiento.
- Chequear el Hardware aplicando algunos tests.
- Cambiar el hardware y/o software.
6. Pruebas de los cambios para la solución definitiva:
- Entonar el sistema: Se requieren mediciones que nos permitan corroborar
que los cambios contribuyeron a la solución del problema.
- Chequear el efecto que pudiera generar algún cambio realizado para la
solución del problema.
Metodología Caso de estudio – Estrategia Proactiva:
 Identificación preliminar del problema: Se realizan los estudios preliminares
para diagnosticas la situación actual. Es muy probable que sea necesario instalar
algunas aplicaciones que permitan monitorear el sistema, su carga de trabajo y el
consumo que ésta realiza sobre los diferentes recursos del sistema para así
obtener de una manera sistemática los datos reales y hacer a un lado la intuición.
 Un requisito fundamental para el inicio de cualquier proyecto planificado debe
considerar la concientización de la alta gerencia en general, puesto que para
cualquier proyecto (entonación, planificación de capacidades, migración, prueba
de nuevos productos, respaldos/recuperación, etc.), se requiere invertir en tiempo,
recurso humano y dinero, para su implantación y puesta en marcha. Además de
consideraciones especiales, en cuanto a: accesos a las instalaciones en horas no
laborales, permanencia de personal externo a la empresa, traslado de equipos,
incluso situaciones en las que se hacen necesarias modificaciones de la planta
física de la empresa, acceso a información confidencial y otras como posible
acceso a llamadas telefónicas internacionales, paradas planificadas del sistema
con su consecuente implicación para la empresa.
 Una vez ganada la alta gerencia, el siguiente paso consiste en conformar un
equipo interdisciplinario que involucre al personal técnico especialista en el
hardware instalado y por instalar, especialistas en soporte a software (Sistemas
Operativos, Redes, Aplicaciones), operadores del sistema, especialistas en
evaluación del desempeño. Participando en conjunto, tanto personal perteneciente
a la empresa en sí, como un líder que coordine el equipo de trabajo, de acuerdo a
las actividades a realizar y velando por la sinergia del mismo.

 A partir de la información recolectada durante el diagnóstico, se elabora un
plan detallado de trabajo en el que se estipulan para cada actividad: orden de
ejecución, tiempo estimado de duración, los recursos empleados y los
responsables. Cabe señalar, que pueden existir actividades que se realicen
paralelamente en el tiempo.
 Ejecución del plan: En este paso el líder lleva el control de las actividades, su
avance en el tiempo y posibles ajustes de las mismas.
 Prueba y verificación de los efectos esperados.
Comparación de las Metodologías:
Metodología/
Parámetros
ITIL Proactiva Reactiva ISO/
IEC
14764
APN IDA SourcePYME
Calidad de
documentación
disponible
Buena - - Buena Regular Buena Regular
Tiempo
invertido
Alto Alto Bajo Alto Regular Regular Alto
Habilitación
gradual o
súbita
Súbita Súbita Súbita Súbita Gradual Súbita Súbita
Cantidad/
Calidad de
artefactos
generados
Alta Baja Baja Baja Alta Regular Alto
Densidad de
las fase:
Recolección de
información
- Alta Alta Baja Regular Regular Alta
Densidad de
las fase:
Planificación
Alta Alta Regular Baja Baja Regular Alta
Densidad de
las fase:
Evaluar los
resultados
Alta Baja Regular Baja Regular Baja Alta

Bibliografía
 Guía para el plan de migración a software libre en la Administración Publica
Nacional (APN) de la República Bolivariana de Venezuela. Centro Nacional de
Tecnologías de Información.
 International Standard ISO/IEC 14764 IEEE Std 14764-2006. Second Edition (2006).
Software Engineering- Software Life Cycle Processes – Maintenance.
 Maria Elena Ciolli (2007) Testing de migracion de aplicaciones distribuidas a
entornos Web.
 Romero Pedro. Migración a un sistema de información colaborativo empresarial.
Caso de estudio: Sistema de venta de repuestos a los trabajadores de General Motors
Venezolana, C.A.
 Daniel Enrique Rodriguez. Migración de la herramienta ofimática OTRS a CA
Service Desk Manager en Mesas de Ayuda en Servicio Corporativo utilizando las
buenas practicas ITIL.
 Proyecto SourcePYME. Migración al software libre – Guía de buenas prácticas.
Instituto Tecnológico de Informática.
 Aliaga Varillas, Nick Jonathan, Londoñe Ñahuincopa, Jose Luis (2011). Proyecto de
Metodologia para la migración de Sistemas Educativo Distribuido a entornos web.
 Directrices IDA de migración a software de fuentes abiertas. Netproject Ltd.
 Aguirre, J., (Octubre de 2004). Esquema Estratégico para un Proceso de Migración
de Sistemas Tecnológicos e Informáticos para una Empresa Operadora de
Información. Instituto Politécnico Nacional de México.

 Galiano, J., (Septiembre de 2012). Proceso de Migración de Sistemas Web.
Aplicación al Sistema de Recomendación REJA. Universidad de Jaén, Escuela
Politécnica Superior (Jaén).

Migracion de Sistemas Computacionales

Más contenido relacionado

La actualidad más candente

Similar a Migracion de Sistemas Computacionales

Más de Jesus Jimenez

Migracion de Sistemas Computacionales