Comenzaremos por la parte técnica de la planificación, en este punto se debe decidir que tipo de migración se va a llevar a cabo y cómo. Esto nos servirá para dividir la migración en pequeños pasos o tareas que hagan la gestión del proyecto mucho más fácil. Cuanto más nivel de detalle se alcance en la descripción de las tareas, más sencillo será después planificar que recursos humanos y temporales asignarle.

Cosas a tener en cuenta

Este documento no pretende ser un manual exhaustivo de cómo realizar una migración en términos técnicos. Solo es una guía en la que se intenta establecer una serie de pasos o procedimientos que ayudarán a planificar y ejecutar una migración a software libre.

Tipos de migración

Existen diferentes tipos de migración. No siempre es posible llevar a cabo todos los tipos de migración y se debe decidir cual conviene más en cada caso concreto.

Migración de los servicios (servidores)

En este tipo de migraciones solo las aplicaciones de los servidores se migran, esto es posible solamente si existe un reemplazo compatible (en la mayoría de casos para aplicaciones de servidores como correo electrónico, paginas web, etc... sí que existen alternativas libres) con los clientes.

Por ejemplo, si nuestro servidor ofrece servicio de autenticación de usuarios en un dominio Microsoft Windows, carpetas compartidas, servicios de correo electrónico y páginas web se puede migrar a un entorno con GNU/Linux como sistema operativo, OpenLDAP y Samba para la autenticación de usuarios en dominios Microsoft Windows y carpetas compartidas, Postfix o Sendmail para los servicios de correo electrónico y Apache Web Server o LightHTTPD como servidor de páginas web o directorios WebDAV.

La ventaja de este tipo de migración es que las aplicaciones instaladas en los clientes no se alteran en ningún momento, es decir, los usuarios de las aplicaciones cliente no notan ningún cambio. Además estos usuarios no necesitarán formación dado que continúan manejando las mismas aplicaciones. Esta es una gran ventaja, ya que los usuarios, al no tener que aprender a usar nuevas herramientas, seguirán siendo, al menos, tan productivos como antes de la migración del servidor.

Además, es muy probable que la productividad de los usuarios aumente, ya que en términos generales, los servidores basados en GNU/Linux soportan una carga mayor que aquellos utilizando software privativo. De esta manera, servidores que antes de la migración soportaban una carga alta de transacciones, al ser migrados podrán soportar aún más transacciones con el mismo hardware, con lo que los usuarios notarán una disminución del tiempo de respuesta del servidor, y por tanto la productividad de estos usuarios puede llegar a aumentar de manera considerable, ya que podrán realizar más tareas en mismo tiempo.

Los únicos usuarios que necesitan formación en las nuevas aplicaciones (si no la poseen ya) son los técnicos encargados del mantenimiento y buen funcionamiento de los servidores. Por lo general éste colectivo de profesionales suele ser mucho mas receptivo a los cambios, debido a su mayor conocimiento de los sistemas, que los usuarios finales.

Siempre que se realice una migración de algún servidor, es importante que el técnico o administrador encargado de dicho servidor sea participativo en la migración. De esta manera podrá aprender durante la migración las tareas básicas de administración del nuevo sistema.

Si conseguimos que el administrador sea participativo, podemos conseguir que los costes de formación sean nulos para tareas sencillas, y para tareas más sofisticadas podemos reducirlos considerablemente.

En caso de que los servidores necesiten ofrecer servicios que únicamente dispongan de software propietario, podemos realizar una migración parcial. Para realizar esta tarea, podemos migrar el servidor a software libre, reemplazando todos los posibles servicios que tengan una alternativa basada en software libre. Para aquellos que no exista una alternativa viable, o que no se deseen cambiar, podemos realizar una migración parcial por virtualización. De esta manera, corremos otro sistema operativo encima del servidor con software libre, sobre el que se instalan únicamente los servicios que no se deseen/puedan migrar. Para realizar esta virtualización, podemos utilizar máquinas virtuales como QEmu o Innotek VirtualBox. Este tipo de soluciones es muy atractiva ya que aislamos el software privativo del libre, con lo que los fallos de seguridad de esa máquina virtual quedan completamente aislados del sistema operativo real.

Migración de los usuarios (clientes)

Se puede llegar a este tipo de migración de tres maneras, una es que se haya realizado la migración de los servidores en una etapa anterior, otra es que se disponga de aplicaciones para los clientes compatibles con las aplicaciones propietarias instaladas en los servidores y sean software libre. El otro supuesto que puede desembocar en este tipo de migración es que la empresa no disponga de servidores, con lo cual los "clientes" son máquinas aisladas y su software no mantiene ninguna relación con otra máquina externa.

En este tipo de migración son sólo las máquinas cliente las que migran su software. La desventaja es que son los usuarios finales los que padecen el cambio y por lo tanto éste debe ser gestionado de la mejor manera posible para evitar el posible rechazo de las nuevas aplicaciones por parte de los usuarios, haciendo especial hincapié en la formación.

Si la migración de software se hace de forma abrupta, es muy probable que los usuarios rechacen el cambio o que incluso se opongan a él.

Hay que tener en cuenta, además, que realizar este tipo de migración software puede producir un decremento de la productividad de los usuarios, ya que durante un tiempo (en general entre una y dos semanas) los usuarios tendrán problemas de adaptación. Afortunadamente, las HIG [*] implementadas por el software libre, sobre todo en los entornos de escritorio, son seguidas a rajatabla en muchas aplicaciones libres, por lo que este paso, aunque tarden un par de semanas en adaptarse los usuarios, implicaran un notable incremento de productividad posteriormente. Por tanto, podemos considerar la penalización de productividad inicial como un pequeño obstáculo debido al cambio, pero que a medio o largo plazo proporcionará beneficios de productividad notables.

[*] HIG, siglas del inglés, Human Interface Guidelines (guía para interfaces humanas), son las especificaciones de usabilidad de las aplicaciones para que estas se puedan utilizar de la manera más amigable. En el caso del escritorio GNOME, podemos encontrar estas guías en:
http://developer.gnome.org/projects/gup/hig/2.0/

En el caso de que haya aplicaciones indispensables que no puedan migrarse, se puede optar por una adaptación parcial, como hemos comentado anteriormente en el caso de la migración de servicios. Para conseguir esto, disponemos de más herramientas que en el caso del servidor, ya que además de la estrategia de la virtualización, podemos utilizar aplicaciones de emulación.

Migración completa

Este tipo de migración es una combinación de los dos anteriores. Se trata de hacer la migración tanto de los servidores como de los clientes. En este caso se debe destacar que todo ha de estar muy bien planificado de antemano ya que en una migración no se pueden dejar cabos sueltos. Se debe estar bien seguro de los pasos a seguir y las acciones a tomar puesto que tanto el cliente como el servidor cambian al mismo tiempo y pueden surgir errores o incompatibilidades inesperadas que hagan peligrar el éxito de la migración. Para realizar este tipo de migración, ha de considerar siempre realizarlo en dos pasos, migrando inicialmente los servicios y, posteriormente, los usuarios.

Migración de aplicaciones

En los anteriores tipos de migración, se considera que se cambia tanto de aplicaciones como de sistema operativo, ya sea en los servidores, en los clientes o en ambos. En este caso, solo cambian algunas aplicaciones. Se suele dar este caso sobre todo cuando al analizar las aplicaciones que se utilizan en la empresa aparecen muchas aplicaciones no migrables u otros factores que no permiten una migración total. De esta manera se escogen las aplicaciones que tienen una clara alternativa en software libre y se migran, dejando las demás inalteradas.

Aunque este tipo de migraciones son mucho más sencillas y rápidas que las migraciones que hemos comentado anteriormente, pueden suponer un ahorro importante respecto al coste económico necesario para realizarlas. Para comprobarlo, nos serviremos de un ejemplo. Una licencia de Microsoft Office cuesta aproximadamente 600 euros, mientras que OpenOffice.org no sólo es gratuito, sino que podemos actualizarlo siempre sin ningún coste y el entorno de trabajo es prácticamente idéntico al del software privativo.

Estrategias de migración

En este apartado vamos a ver las distintas posibilidades que tenemos para realizar la migración. Trataremos de describir las alternativas, mostrando tanto las ventajas como las desventajas de cada una de ellas. De esta manera, podremos elegir la alternativa adecuada a la hora de realizar la migración en nuestra empresa.

Tenga en cuenta que no existen únicamente estas posibilidades, y que en función de sus necesidades puede optar por una en concreto, o mezclar varias alternativas. Por ejemplo, si dispone de dos departamentos en su empresa que desea migrar, puede utilizar estrategias de migración distintas para cada departamento, pero siempre teniendo una estrategia global de migración para no pender de vista las operaciones que desea realizar. De esta manera en departamentos con muy pocos equipos a migrar puede utilizar el sistema de migración en un solo paso. En cambio, en el área de sistemas puede utilizar una migración progresiva en grupos.

Antes de describir las diferentes estrategias para realizar la migración, es importante seguir estos consejos:

• Recuerde siempre dedicar los medios necesarios para informar y formar a los usuarios y de este modo evitar el rechazo.
• Motive a sus empleados a usar los nuevos sistemas, esto hará la transición más llevadera y permitirá que los usuarios se esfuercen en aprender a utilizar el nuevo software.
• Dedique tiempo a escoger la estrategia de migración adecuada para su empresa. Estudie las ventajas y desventajas de cada estrategia e identifique los posibles riesgos y cómo solucionarlos.

Migración en un único paso

Esta migración es la más rápida de realizar, pero tiene muchos posibles inconvenientes. Se trata de realizar toda la migración a software libre de una sola vez. Esta estrategia de migración depende, generalmente, del tamaño de la empresa (o el grupo seleccionado) y las aplicaciones que se utilicen y consiste en cambiar todo el software por sus equivalentes en software libre en los equipos de la empresa a la vez.

Dado que toda la migración se va a llevar a cabo en un solo paso, se recomienda tener muy bien planificadas las tareas a llevar a cabo, así como bien definida la lista de software a instalar en los equipos y las configuraciones a establecer para los diferentes servicios. No se debe dejar nada a la improvisación y hay que ser muy meticuloso a la hora de realizar el cambio.

Todos los usuarios cambiarán del viejo sistema al nuevo el mismo día. Es recomendable llevar a cabo el cambio durante un fin de semana o un día festivo.

Esta opción de migración suele ser la mas adecuada para pequeñas empresas o administraciones en las cuales el número de equipos es muy reducido y en rara ocasión disponen de más de un servidor. Pero debido a la cautela que se ha de tener al planificar el cambio este camino de migración puede resultar complicado en empresas grandes, con más de 50 equipos y más de 1 ó 2 servidores.

Este camino de migración no es adecuado para empresas con un elevado número de equipos.

Una de las ventajas de optar por este camino de migración es que no se necesitará mantenimiento de dos sistemas diferentes (el viejo y el nuevo), porque el viejo sistema desaparece definitivamente. Las desventajas son que, de no haber planeado correctamente la migración, puede no terminarse a tiempo y además existe el peligro de que los usuarios rechacen la migración.

Una buena precondición para seguir este camino de migración es que el personal de TI ya posea el conocimiento necesario sobre software libre, ya sea porque lo utilizan a nivel privado o porque las aplicaciones o servicios individuales basados en software libre (como un servidor de e-mail bajo GNU/Linux) ya se utilizaban oficialmente en la empresa. Si además el personal de la empresa está abierto a nuevas tecnologías e interesado en el Software Libre las cosas serán más fáciles.

Ventajas:

• No se tienen que mantener dos sistemas simultáneamente. El nuevo sistema reemplaza al anterior.
• Es muy práctico para empresas pequeñas.
• Es la estrategia de migración más económica.

Desventajas:

• Se dispone de poco tiempo para realizar la migración.
• Los errores en la migración se pagan caros, no se puede utilizar el sistema antiguo mientras se arreglan estos errores.
• Los empleados descubren el nuevo sistema de forma abrupta. Pueden rechazar la migración.
• Requiere de una formación previa de los usuarios.

Migración Piloto e Implantación

Esta estrategia de migración suele ser la más adecuada para empresas con gran número de equipos y más de un servidor. Se procederá primero a la migración de las aplicaciones en un grupo reducido de equipos. Por ejemplo en una migración de servicios y clientes se puede utilizar un servidor y un equipo como piloto, aunque el número de equipos que formen parte de la migración piloto puede seleccionarse en función de las necesidades. De hecho, es habitual utilizar un departamento de la empresa como grupo piloto, para estudiar alternativas de migración posteriormente para el resto de la empresa.

Una vez instaladas las nuevas aplicaciones en los equipos piloto, se procederá a la comprobación de su correcto funcionamiento y a la verificación de que cumplen con los requisitos establecidos.

Si no se dispone de máquinas físicas suficientes (como suele suceder con los servidores) se tendrán que utilizar máquinas virtuales para simular los equipos piloto. Por ejemplo se puede instalar una distribución de GNU/Linux en una máquina virtual ejecutándose sobre Microsoft Windows o viceversa.

Después del período de evaluación se procederá a la instalación definitiva en el resto de máquinas. Este período de evaluación debe ser lo suficientemente largo para que de tiempo a comprobar que todo funciona de la manera esperada. Esta es la razón principal por la que se utiliza uno o varios equipos pilotos: comprobar la corrección de funcionamiento. Si no evaluamos esta corrección adecuadamente, no sirve de nada utilizar esta estrategia de migración. Como cualquier otro camino de migración se requiere una buena planificación de todas las tareas a llevar a cabo, la ventaja de este método es que se pueden corregir errores inesperados o incompatibilidades no contempladas sin perder la funcionalidad o la productividad actual del sistema de información actual de la empresa.

Evidentemente, una vez se compruebe que la prueba piloto funciona correctamente, pasaremos a implantar la migración el resto de equipos, pero con el conocimiento de conocer de antemano los problemas a los que nos vamos a enfrentar. Esta es una de las estrategias más utilizadas por la empresas, sobre todo cuando existen una cantidad de aplicaciones o servicios no migrables a los que se debe dar soporte.

Ventajas:

• La prueba piloto nos permite conocer los riesgos que se corren al realizar la migración.
• Permite comprobar cómo va a ser realizada la migración.
• Se identifica inequívocamente el software no migrable, con el consiguiente ahorro de tiempo posteriormente.
• Permite crear un proceso de migración que se aplicará posteriormente, cuando se implante en el resto de equipos.
• Permite formar a los usuarios antes de que se implante el sistema ya migrado.

Desventajas:

• Se tiene que mantener el sistema piloto simultáneamente al sistema actual.
• Se necesitan más recursos para realizar la migración.
• Durante la prueba piloto, perderemos recursos humanos, ya que los implicados en esta prueba tengan una pérdida de productividad.

Transición por fases en grupos

Esta es una opción adecuada si se tienen identificados claramente grupos funcionales dentro de la empresa y se pretende ir integrando software libre paulatinamente. Los grupos de usuarios migran del viejo sistema propietario al nuevo software libre consecutivamente. Esto tiene la ventaja de que a medida que se vayan realizando las migraciones de los grupos se irá ganando experiencia y se aprende de los errores cometidos. De esta manera si algo falla al migrar un grupo funcional se evitará que falle al migrar el siguiente grupo.

Si los grupos no están ya establecidos, elegir un tamaño de grupo adecuado es esencial para contener los riesgos y gestionar los recursos. El inconveniente de este camino de migración es que en ciertos escenarios el migrar grupo a grupo requiere duplicar recursos (mantener al mismo tiempo el sistema propietario antiguo y el nuevo sistema basado en software libre) o un alto grado de compatibilidad entre aplicaciones propietarias y aplicaciones de software libre. Para ilustrar esto se puede observar el siguiente ejemplo:

Una empresa dispone de 2 servidores y 6 grupos funcionales. Uno de los servidores se utiliza para dar servicios de autenticación, almacenamiento compartido, acceso a una aplicación de gestión vía web todo con software propietario. El otro servidor se utiliza como apoyo en caso de fallo del servidor principal. En este entorno se pueden tomar varias decisiones, una de ellas puede ser implementar el nuevo servidor basado en software libre y comenzar a migrar los grupos, una vez finalizada la migración de todos los grupos el servidor que antes actuaba como servidor principal de software propietario ya no será necesario, así que se puede proceder a migrar dicho servidor. Si se está seguro de la compatibilidad de los clientes con el nuevo software libre se puede sustituir en una primera etapa los servidores y después proceder a migrar los grupos por fases.

Esta estrategia de migración es muy interesante, y mezcla la migración en un único caso junto a la prueba piloto. De esta manera, los usuarios se van adaptando paulatinamente al nuevo sistema, la transición se hace de forma progresiva, de manera que si algo falla, únicamente afectará al grupo sobre el que se ha decidido realizar la migración primaria. De esta manera, como ya hemos comentado antes, podemos subsanar esos errores para que el siguiente grupo sobre el que se realice la migración no padezca de este error y la migración sea más rápida.

Se puede aprovechar la migración para hacer cambio del hardware de los PC al mismo tiempo, reemplazando las máquinas en un grupo y luego instalando las sustituidas (si son mejores) en lugar de las viejas máquinas del siguiente grupo.

Además, este tipo de migración, al realizarse poco a poco dentro de la estructura empresarial, permite dosificar el esfuerzo de la empresa en adaptarse al nuevo software. De esta manera, cuando la migración esté a mitad, sólo habrá un grupo implicado activamente en la migración; el resto, o utilizarán el sistema antiguo (con lo cual no verán mermada su productividad) o llevarán utilizando el sistema migrado a software libre (por lo que la productividad será igual o mayor a los que aún no han migrado).

Ventajas:

• La migración no afecta a todo el sistema.
• Se puede aprovechar la migración para realizar una renovación del hardware.
• Permite identificar posibles errores antes de que se produzcan en otros grupos.
• Si algo falla, solo afecta al grupo que está actualmente en transición.
• Como la migración se hace por grupos, sólo hay un grupo cada vez que pierda productividad.

Desventajas:

• Conviven dos sistemas simultáneamente: doble trabajo para los administradores.
• Puede haber problemas de sincronismo entre ambos sistemas.
• Es más costoso que el resto de métodos, tanto económica como temporalmente.
• Si la empresa sobre la que se realiza la migración es grande, puede ser la única manera de realizar la migración.

Transición de usuario a usuario

Básicamente la misma opción de la transición en grupos, pero con un grupo compuesto por una sola persona. Este método necesita escasos recursos, sin embargo resulta ineficaz para grandes administraciones. Además es muy lento, por lo que la migración puede extenderse durante un largo periodo de tiempo. Siempre que se pueda, es preferible utilizar alguna de las otras estrategias, a no ser que se trate de migración de sistemas críticos, donde tengamos que realizar una migración muy poco a poco para que la transición afecte al sistema de forma muy progresiva.

Inventario

Una vez elegida una estrategia de migración, lo que debemos hacer es analizar cómo va a afectar la migración a las aplicaciones y servicios que actualmente se están empleando en la empresa.

Inventario de software

El inventario de software realizado en la etapa anterior permitirá identificar las aplicaciones que realmente se utilizan en la empresa y servirá como guía para establecer qué Software Libre se va a implantar.

Se espera que la mayoría, pero no todas, las aplicaciones tengan disponible su equivalente funcional que se ejecute nativamente en un cliente GNU/Linux. Y hay casos especiales (ideales) en los que los equivalentes funcionales son también lo que se conoce como "aplicaciones puente". En general, una vez decidida la lista de aplicaciones utilizadas que requieren un equivalente funcional en software libre, se debe decidir que aplicaciones proporcionan las mismas funciones en software libre. Hay muchos recursos on-line que le pueden guiar en este proceso.

• Enlaces del proyecto SourcePYME
• Tabla de equivalencias/reemplazos/análogos de software Windows en GNU/Linux
• Linuxquestions.org: "Software equivalents to Windows Software"
• www.novell.com: "Novell Linux Desktop Equivalents of Windows Software"

Si no se está familiarizado con el software libre, la tarea de decidir qué software va a sustituir al actual requerirá algo de trabajo de investigación por parte del personal encargado de migrar los sistemas. Aunque, independientemente de si se está familiarizado con el software libre o no, también se puede contratar los servicios de un consultor externo que ayude a la empresa en este punto.

En caso de no encontrar una aplicación en software libre equivalente a la aplicación propietaria utilizada actualmente, la mejor práctica sería que la misma empresa la desarrollase si tiene recursos suficientes, y la liberara bajo una licencia libre o que la empresa colabore en el desarrollo de la herramienta necesitada junto con el resto de la comunidad de software libre. "Caminante no hay camino, se hace camino al andar".

Inventario de hardware

Al tener inventariado el hardware se conoce en detalle de qué máquinas se dispone para la migración, incluyendo máquinas retiradas. Este inventario permitirá comprobar la compatibilidad del hardware con el nuevo software (tarjetas gráficas, impresoras, etc...). También permitirá planificar si se va a adquirir nuevo hardware o no.

Se pueden recuperar máquinas ya retiradas para implementar nuevos servicios, como por ejemplo un servidor de impresión, un servidor de correo electrónico o incluso un servidor de almacenamiento compartido o servidor web. (En teoría cualquier GNU/Linux se puede ejecutar en una máquina con un procesador compatible con la arquitectura Intel 386, pero para obtener un rendimiento aceptable se recomienda que si se utilizan máquinas retiradas, éstas no tengan un procesador inferior a la categoría Pentium)

Como el inventario de software nos permite saber con precisión del hardware que disponemos, podremos clasificar el hardware en una de las siguientes categorías:

Hardware soportado nativamente por el núcleo Linux

El núcleo Linux presente en la mayoría de distribuciones GNU/Linux actuales, incorpora de serie soporte para gran cantidad de hardware. De hecho, el 90% de los equipos funcionarán sin necesidad de instalar controladores adicionales al soportado por el núcleo. Ésta es una ventaja competitiva de GNU/Linux, ya que nos olvidamos, salvo en casos contados, de tener que buscar controladores para el hardware. Podemos consultar una lista del hardware soportado por el núcleo Linux en http://hardware4linux.info/ y en http://www.mandriva.com/en/hardware/

Hardware soportado por controladores libres

Para el núcleo Linux, existe gran cantidad de hardware que, aunque no está soportado directamente por drivers nativos, tienen soporte de la comunidad de software libre con drivers completamente libres. Normalmente, estos drivers acaban por incorporarse al núcleo del sistema.

Con los drivers libres, el 90% del hardware actual funciona sin problemas, simplemente basta con conectar el hardware y el núcleo de Linux se encarga de cargar los drivers adecuados para cada tipo de hardware.

Hardware soportado por controladores privativos

Es posible, que cierto tipo de hardware, funcione completamente solo mediante drivers propietarios. Este problema va desapareciendo paulatinamente y atañe principalmente a las aceleradoras de gráficos 3D. Este tipo de hardware puede hacerse funcionar perfectamente con Linux, pero no se dispone de drivers libres que permitan el funcionamiento. Afortunadamente, hay multitud de proyectos de drivers libres que se encargan, poco a poco de conseguir drivers libres para estos dispositivos, con lo que a largo plazo, esto deja de ser un problema.

Actualmente, aceleradoras gráficas nVIDIA y algunas tarjetas inalámbricas tienen este problema.

Hardware soportado por adaptadores de drivers privativos

Hay cierto tipo de hardware que, simplemente, no tiene ningún driver. En muchas ocasiones, podemos hacer funcionar ese hardware perfectamente mediante herramientas de adaptación de drivers. Generalmente, este problema aparece con los drivers de algunas tarjetas inalámbricas de última generación.

Para hacer funcionar este hardware, podemos utilizar herramientas como NDISwrapper para utilizar los drivers de otros sistemas operativos (en este caso de Microsoft Windows) con el núcleo de Linux hasta que tengamos un driver libre.

La solución de adaptar drivers de otros sistemas operativos privativos para hacerlos funcionar con el núcleo Linux no es una buena idea, y solo debemos utilizar esto como algo temporal hasta disponer de drivers libres.

Aún así, hay que tener en cuenta que la mayoría del hardware no necesita de este tipo de software para hacerlo funcionar. Esto es solo útil en hardware muy determinado y. generalmente para equipos portátiles que incorporen adaptadores de red inalámbricos poco comunes.

Hardware que funciona, pero sólo en versiones recientes del kernel Linux

Gran parte del software que no funciona, se debe a que muchas de las distribuciones actuales tienen un proceso de publicación que se alarga desde los 3 meses hasta 1 año (bien, Debian es una excepción, ya que sus versiones estables han tardado hasta 5 años en aparecer). Durante este proceso, los programadores y los empaquetadores de la distribución tienen que fijar un núcleo base, una versión idéntica para todos los desarrolladores. De esta manera se garantiza que todos los paquetes (unidades instalables de software libre donde se gestionan las dependencias entre ellas de forma automática, generalmente ficheros .deb o .rpm) que se desarrollan para esa distribución. Es decir, muchas de las distribuciones no disponen de la última versión del núcleo.

Hay que tener en cuenta que el desarrollo del núcleo de Linux es muy veloz, incluso algunas revisiones duran sólo horas. Por tanto, es muy posible que el hardware no esté soportado por la distribución GNU/Linux elegida en ese momento.

Hay que utilizar siempre la última versión de la distribución GNU/Linux elegida para realizar la migración. De esta manera no sólo accedemos a las últimas mejoras en el núcleo, sino que podremos utilizar hardware más moderno.

Hardware que funciona, pero con un controlador libre antiguo no mantenido

Aunque generalmente no se da el caso, hay hardware que por ser muy antiguo (cuando se dice "muy", realmente es "muchísimo", es decir, hardware de hace más de 15 años) simplemente no tiene soporte. Es un caso extremadamente extraño, ya que los usuarios GNU/Linux tienden a alargar al máximo la vida útil de sus equipos. En este caso, simplemente podremos instalar una versión de la distribución GNU/Linux algo antigua, de esta manera podremos seguir usando el hardware aunque no dispongamos de las últimas mejoras del núcleo. De todas maneras, estos casos son extremadamente raros, ya que el núcleo Linux muy adaptable y las últimas versiones pueden utilizarse incluso con equipos muy antiguos, ya que los drivers suelen adaptarse a las últimas versiones.

Hardware que funciona, pero con limitaciones

Hay cierto tipo de hardware que funciona con limitaciones. Es posible que adaptadores de pantalla con salida de televisión funcionen perfectamente, exceptuando esa salida. Lo mismo ocurre con algunos adaptadores de pantalla que, pese a disponer de aceleración 3D por hardware, sólo funcionan en modo 2D.

Generalmente, estos dispositivos disponen de un driver propietario y es la versión libre la que no consigue sacarle todo el partido al hardware. En la mayoría de los casos es porque los fabricantes de hardware no dan las especificaciones de sus dispositivos a los desarrolladores de controladores libres, por lo que a estos no les queda más remedio que investigar cómo funcionan estos dispositivos, por lo que sólo pueden dar soporte a las funciones que son capaces de comprender.

Hardware que no soporta GNU/Linux

Para finalizar con el inventario de hardware, hay que tener en cuenta el hardware que simplemente no funciona. Esto, como hemos comentado en anteriormente, sólo ocurre en determinadas ocasiones:

• El hardware es demasiado nuevo, y aún no se ha incluido soporte en el núcleo.
• El hardware es extremadamente antiguo, y ya no funciona en versiones modernas del núcleo.
• El hardware depende de software específico para un sistema operativo concreto, con lo que al no funcionar en GNU/Linux este software, no podemos utilizarlo.

Es muy complicado encontrar hardware que no funcione en las versiones modernas de Linux. Si no lo hace, probablemente sí lo haga a corto plazo.

Conclusión

Es importante categorizar el hardware del que disponemos en las categorías de los puntos anteriores. De esta manera detectaremos el hardware que no podemos utilizar en la migración, con lo que podremos buscarle una alternativa (bien adquiriendo nuevo hardware o esperando a que haya soporte para incluir ese hardware en la migración).

Aunque es posible encontrar hardware que no funcione con el sistema operativo GNU/Linux, generalmente no existen incompatibilidades que impidan por completo la migración. Si el hardware no funciona, generalmente no es culpa de los desarrolladores de GNU/Linux, sino de la empresa fabricante del hardware, que no muestra las especificaciones para poder desarrollar controladores libres.

Diagrama de red

Una vez se han estudiado los cambios en el software y en el hardware se procederá a reflejar dichos cambios en el diagrama de red de la empresa.

• ¿Se van a instalar nuevos servidores de servicios?
• ¿Se van a adquirir nuevos equipos de usuario?
• ¿Nuevas impresoras?
• ¿Se va a cambiar la conectividad entre equipos? Por ejemplo si se disponía de varias impresoras compartidas en distintos equipos de usuario y ahora se han centralizado en un servidor de impresión.

Es vital para futuros proyectos y futuros cambios tener bien documentado todo el proceso de migración. El diagrama de red es uno de los documentos más explicativos e importantes y se debe mantener actualizado.

Antes de la migración

Como podemos observar en el primer diagrama de red, tenemos un conjunto de 10 clientes que se conectan a través de un switch y un enrutador a Internet. En este caso, los clientes PC01 y PC02 disponen de impresoras que son compartidas en red.

Generalmente, cuando se hace una migración se aprovecha para actualizar la red o alguno de los equipos. Supongamos que se adquiere un equipo nuevo, para dotar al sistema de un entorno de red más estable, de manera que incluyamos un servidor de impresoras. De esta manera, si los usuarios en los equipos PC01 o PC02 apagan el equipo o reinician, no se interrumpe el servicio de estas impresoras.

Podemos incluso utilizar, como ya comentamos anteriormente, hardware antiguo para realizar estas tareas, ya que el hardware necesario para montar un servicio de impresión en red generalmente no tiene que ser muy potente.

Después de la migración

En el segundo diagrama de red podemos comprobar cómo al instalar el servidor de impresión, los equipos que realizaban esas tareas pueden utilizarse como el resto, sin interrumpir el servicio en ningún momento. Además, como el servicio de impresión está ahora localizado en un solo equipo, se puede optimizar este para gestionar de la manera más eficiente esa tarea especializada.

Aproveche la migración para realizar cambios estructurales en la red de equipos, así como cambios de hardware y relocalización de equipos dentro de sus instalaciones.

Diagrama de estructura

Al igual que con el diagrama de red, se debe contemplar cualquier cambio en el diagrama de estructura. Esto es, contemplar cualquier cambio en la posición física de los equipos de la empresa. Tener una buena documentación en este aspecto facilitará la tarea de los administradores de identificar dónde está cada equipo si la cantidad de máquinas de la empresa supera los 10 equipos.

Antes de la migración

Como podemos observar en el diagrama de estructura previo a la migración, los servidores de impresión anteriores estaban separados en lugares distintos. En cambio, en el diagrama de estructura posterior, al incluir un servidor de impresión dedicado, ahora se encuentras estructuralmente juntos. Esta es una manera de centralizar los recursos.

Después de la migración

Siempre que sea posible, debemos tener servidores dedicados para los servicios que queramos ofrecer. No necesariamente un servidor por cada servicio, pero sí hay que tener bien definida las funciones de los equipos clientes de los servidores, para mantener los servicios que ofrecen estos servidores de forma independiente de los clientes que se conecten a ellos. Evidentemente, esto se debe realizar en la medida de lo posible. De todas formas, tenga en cuenta que la mayoría de las averías en los servicios de la empresa son provocados por los usuarios, de manera que si aislamos estos servicios en servidores dedicados, la fiabilidad será mucho mayor.

Elección de la estrategia de migración

Después de haber recopilado toda la información sobre la empresa y conocer cuáles son los tipos y estrategias de migración más comunes se debe decidir qué camino de migración se va a seguir para planificar en detalle todas las tareas a llevar a cabo. Debemos, por tanto, seleccionar el tipo y la estrategia de migración en función de las necesidades de su empresa.

En caso de disponer tanto de clientes como de servidores que proporcionen servicios, deberá ver si necesita migrar sólo una parte o ambos. Además, puede aprovechar la migración para relocalizar los equipos dentro de diferentes unidades estructurales (esto se plasma en el diagrama de estructura) y cómo se relacionan los equipos dentro de la red interna empresaria (en el diagrama de red). Además, deberá tener en cuenta de qué hardware y software dispone actualmente, ya que puede que no sea posible realizar la migración de algunos equipos debido a esto.

Por tanto, tenemos que tener en cuenta y sopesar multitud de factores para poder realizar una migración a software libre con éxito.