Interoperable Europe incorporó iGloo, una solución open source en desarrollo para facilitar migraciones de equipos Windows a Linux conservando parte de la configuración del usuario.
Qué está confirmado
La herramienta puede transferir perfiles, redes Wi-Fi, configuración de monitores, aplicaciones equivalentes y controladores de hardware. También busca extender la vida útil de equipos que no cumplen requisitos de nuevas versiones de Windows.
Por qué puede interesar al sector público
Las Administraciones con grandes parques de puestos de trabajo afrontan costes de renovación, licencias, soporte y compatibilidad. Una herramienta que reduzca el trabajo manual de migración puede facilitar pilotos de soberanía de puesto y reutilización de hardware.
Arquitectura y compatibilidad
La migración no debería analizarse de forma aislada. Directorio, identidad, aplicaciones corporativas, VPN, firma, impresión y gestión de dispositivos condicionan el resultado. El inventario previo de dependencias es esencial.
Seguridad y privacidad
Perfiles, contraseñas y configuraciones requieren controles de cifrado, integridad y acceso. Los equipos deberían probarse antes de incorporarse a producción y mantener políticas corporativas de actualización.
Contratación y sostenibilidad
El uso de software abierto puede ampliar opciones de soporte, pero la Administración debe definir quién mantiene la solución, cómo se actualiza y qué componentes siguen dependiendo de terceros.
Qué medir
Equipos migrados, incidencias, aplicaciones incompatibles, tiempo por puesto, satisfacción y ahorro de hardware son indicadores útiles.
Qué debería probar España
Un piloto controlado sobre perfiles representativos permitiría medir compatibilidad real antes de plantear una migración a mayor escala.
Fuentes
Fuente principal: Interoperable Europe.
Conclusión
iGloo puede reducir una de las barreras prácticas de migrar a Linux, pero la decisión pública debe apoyarse en pruebas, compatibilidad y un modelo de soporte sostenible.
El problema que intenta resolver iGloo: migrar no es instalar un sistema operativo
En una organización grande, cambiar Windows por Linux implica mucho más que ejecutar un instalador. Cada puesto puede tener aplicaciones, perfiles, impresoras, certificados, unidades de red, configuraciones de pantalla y preferencias que el usuario espera conservar.
iGloo intenta automatizar parte de ese traslado y reducir el trabajo manual por equipo. El valor potencial es especialmente alto cuando existen cientos o miles de dispositivos.
La migración debe tratarse como un programa de cambio y no como una operación técnica aislada.
Inventario de hardware antes de decidir
La primera fase debería identificar modelo, CPU, memoria, almacenamiento, GPU, periféricos y estado del equipo. No todo el parque tendrá el mismo nivel de compatibilidad.
Algunos dispositivos pueden requerir controladores específicos o funciones que todavía dependen de Windows. El inventario ayuda a separar candidatos sencillos de equipos problemáticos.
También permite estimar cuántos dispositivos podrían prolongar su vida útil evitando una renovación prematura.
Inventario de aplicaciones
El software suele ser la principal barrera. Navegadores y ofimática pueden tener alternativas, pero aplicaciones sectoriales, firma, drivers o herramientas heredadas pueden bloquear una migración.
La Administración debería clasificar aplicaciones en cuatro grupos: nativas en Linux, sustituibles, accesibles por web y sin alternativa viable.
Este análisis debe hacerse por perfil de usuario, porque no todos los empleados necesitan las mismas herramientas.
Perfiles de usuario y datos locales
Documentos, favoritos, redes Wi-Fi y configuraciones pueden trasladarse automáticamente, pero conviene definir qué información debe migrarse y cuál debería permanecer en repositorios corporativos.
Una migración puede ser una oportunidad para reducir datos locales y reforzar almacenamiento centralizado o sincronizado.
Las credenciales requieren especial cuidado y no deberían copiarse mediante métodos inseguros.
Directorio, identidad y SSO
El puesto Linux debe integrarse con identidad corporativa. Si los usuarios necesitan nuevas cuentas locales independientes, la carga de soporte y los riesgos aumentan.
Los mecanismos de SSO, certificados y políticas de acceso deberían probarse antes del piloto.
La migración debe mantener procesos de alta, baja y cambio de permisos comparables a los del entorno existente.
Firma electrónica y servicios públicos
Las Administraciones dependen de certificados, firma, navegadores y componentes específicos. Estos elementos deben validarse con procedimientos reales, no solo comprobando que la aplicación abre.
El piloto debería incluir expedientes, firma, impresión, videoconferencia, VPN y acceso a aplicaciones corporativas.
Una sola incompatibilidad en un proceso crítico puede hacer inviable la migración de un perfil completo.
Seguridad del nuevo puesto
Linux no elimina la necesidad de hardening, actualizaciones y protección de endpoint. La organización necesita una configuración base documentada y controles alineados con sus políticas.
La gestión centralizada de parches, cifrado de disco, firewall, logs y antivirus o EDR debe definirse antes del despliegue masivo.
Las guías del ENS legible por máquina ilustran la oportunidad de convertir requisitos de seguridad en configuraciones verificables.
Soporte y administración remota
Los técnicos necesitan herramientas para inventario, soporte remoto y gestión de configuración. Cambiar el puesto sin adaptar soporte puede aumentar tiempos de resolución.
Soluciones abiertas como RustDesk, analizada también en Digitalización Pública, muestran que el soporte remoto puede formar parte de una estrategia de soberanía si existe control de infraestructura y accesos.
Las sesiones deben quedar registradas y utilizar identidades individuales.
Formación del usuario
La interfaz y las aplicaciones cambiarán. Incluso cuando las funciones sean equivalentes, los hábitos pueden generar resistencia y pérdida temporal de productividad.
La formación debería adaptarse a tareas reales: correo, documentos, reuniones, archivos y aplicaciones corporativas.
Los materiales breves y el acompañamiento durante las primeras semanas pueden reducir tickets y frustración.
Piloto por perfiles, no por voluntarios
Un piloto formado solo por usuarios técnicos puede producir una visión demasiado optimista. Conviene seleccionar perfiles representativos: administrativos, técnicos, dirección y atención.
Las métricas deben incluir incidencias, tiempo de soporte, rendimiento, satisfacción y compatibilidad.
El grupo piloto debería utilizar el sistema durante tiempo suficiente para descubrir problemas que no aparecen el primer día.
Reutilización de hardware y sostenibilidad
Una de las ventajas potenciales de iGloo es prolongar la vida de equipos que no cumplen requisitos de nuevas versiones de Windows. Esto puede reducir inversión y residuos electrónicos.
El ahorro debe compararse con el coste de migración y soporte. Mantener hardware muy antiguo puede aumentar fallos y consumo.
La decisión debe basarse en el ciclo de vida completo y no solo en el precio de sustitución.
Software abierto y soberanía
iGloo encaja con la agenda europea de código abierto, pero la soberanía no consiste únicamente en elegir Linux.
La Administración necesita control sobre configuración, repositorios, actualizaciones y conocimiento operativo.
También debe evitar sustituir una dependencia por otra mediante componentes propietarios imprescindibles.
Compatibilidad documental
Los formatos de oficina deben probarse con documentos complejos: macros, plantillas, firmas, formularios y hojas con funciones avanzadas.
La interoperabilidad debe medirse con socios externos y otros organismos, no solo dentro del equipo piloto.
Los formatos abiertos pueden reducir fricción, pero la transición requiere planificación.
Despliegue por fases
Después del piloto, la migración puede organizarse por perfiles, unidades o ubicaciones. Empezar por grupos con mayor compatibilidad permite generar experiencia antes de abordar casos difíciles.
La herramienta de migración debe conservar logs y permitir saber qué se transfirió correctamente y qué requiere revisión.
Un procedimiento de rollback puede ser necesario durante las primeras fases.
Coste total
La comparación debe incluir licencias, hardware, soporte, formación, migración, aplicaciones alternativas y productividad. Ahorrar en un componente puede aumentar otro.
También conviene calcular el coste recurrente de mantener repositorios, imágenes y herramientas de gestión.
La transparencia sobre estos costes permite decidir con evidencia y evitar debates puramente ideológicos.
Qué relación tiene con interoperabilidad pública
Un puesto soberano sigue necesitando conectarse a servicios comunes, APIs y plataformas. Casos como Information Mediator recuerdan que la independencia del escritorio debe convivir con estándares de servicio.
El navegador y las aplicaciones web pueden reducir dependencia del sistema operativo si se diseñan correctamente.
Por ello, modernizar aplicaciones heredadas puede ser tan importante como migrar el puesto.
Qué puede probar una Administración española
Un organismo puede seleccionar 50 o 100 equipos de perfiles representativos, ejecutar iGloo y medir tiempo por migración, incidencias y ahorro potencial.
El piloto debería documentar cada incompatibilidad y decidir si se resuelve, sustituye o excluye.
La decisión de escalar debe basarse en esos resultados y no en una prueba de laboratorio.
Preguntas frecuentes
¿iGloo convierte automáticamente cualquier PC a Linux?
Busca automatizar parte del proceso, pero la compatibilidad de hardware y aplicaciones debe evaluarse.
¿Migrar a Linux elimina licencias?
Puede reducir algunas, pero seguirá habiendo costes de software, soporte e infraestructura.
¿Es necesario formar usuarios?
Sí. La productividad inicial depende en gran medida de la adaptación a nuevas herramientas.
¿Puede convivir con Windows?
Una estrategia por perfiles puede mantener entornos mixtos mientras se migra de forma progresiva.
Conclusión operativa
iGloo aborda una parte concreta pero costosa de la soberanía del puesto: trasladar perfiles y configuraciones sin reconstruir manualmente cada equipo. Su valor dependerá de compatibilidad, gestión y soporte.
La migración sostenible exige inventario, pruebas, formación y una arquitectura corporativa capaz de funcionar en más de un sistema operativo.
Gestión centralizada de configuración
Una migración masiva necesita una imagen base, políticas corporativas y mecanismos para distribuir cambios. Administrar cada equipo Linux de forma manual eliminaría buena parte del ahorro que pretende conseguirse con iGloo.
La organización debería definir cómo aplica configuraciones, actualizaciones y políticas de seguridad y cómo comprueba que los equipos mantienen el estado esperado.
Aplicaciones web como acelerador de la migración
Cuanto mayor sea el porcentaje de servicios accesibles desde navegador, menor será la dependencia del sistema operativo. Modernizar aplicaciones heredadas hacia interfaces web estándar puede abrir la puerta a entornos mixtos.
La interoperabilidad de navegador, firma y autenticación debe probarse en procedimientos reales y no solo con páginas informativas.
Esta lógica se conecta con la agenda europea de servicios públicos digitales, donde la disponibilidad multicanal y la reducción de dependencias son elementos cada vez más relevantes.
Impresión y periféricos: el detalle que puede bloquear una unidad
Escáneres, lectores de tarjetas, impresoras especiales o dispositivos de laboratorio pueden no disponer del mismo nivel de soporte. El inventario debe incluir periféricos y no limitarse al ordenador.
Los pilotos deberían seleccionar puestos con hardware representativo y documentar qué controladores funcionan, cuáles requieren ajustes y cuáles obligan a mantener Windows.
Gestión de incidencias durante la transición
Las primeras semanas suelen concentrar dudas y problemas. Conviene etiquetar los tickets relacionados con la migración para distinguir formación, incompatibilidad, configuración y fallos de hardware.
Esta clasificación permite medir si las incidencias disminuyen con el tiempo y qué áreas necesitan documentación adicional.
Modelo híbrido como opción permanente
No todas las organizaciones necesitan llegar a un parque completamente Linux. Un entorno híbrido puede ser sostenible si la identidad, las aplicaciones y los documentos funcionan de forma coherente.
La decisión debería basarse en perfiles de uso y coste total, evitando objetivos puramente porcentuales que obliguen a migrar puestos donde el retorno es bajo.
Cómo documentar el resultado de un piloto
El informe debería recoger tiempo medio de migración, porcentaje de datos trasladados correctamente, aplicaciones problemáticas, incidencias, satisfacción y ahorro estimado. También debe incluir los casos excluidos y la razón.
Con esta información, otra unidad puede repetir el proceso con menos incertidumbre y la Administración puede decidir si escala, ajusta o detiene la migración.
Qué ocurre con aplicaciones que no pueden migrarse
Algunos sistemas heredados pueden requerir Windows durante años. En lugar de bloquear toda la estrategia, la Administración puede aislar esos casos mediante virtualización, acceso remoto o equipos específicos, siempre que el coste y la seguridad lo justifiquen.
Esta excepción debe documentarse y revisarse periódicamente. Una aplicación que hoy no tiene alternativa puede disponer de una versión web o compatible más adelante.
Repositorios y actualizaciones de software
El entorno Linux necesita una política clara sobre repositorios autorizados, versiones y ventanas de actualización. Permitir instalaciones arbitrarias puede generar una superficie de soporte difícil de controlar.
Las aplicaciones corporativas deberían distribuirse mediante canales gestionados y contar con un procedimiento para validar nuevas versiones antes del despliegue general.
Una decisión basada en evidencia, no en preferencias
La comparación entre Windows y Linux debe apoyarse en requisitos, coste, compatibilidad, seguridad y productividad. Diferentes perfiles pueden llegar a conclusiones distintas dentro de la misma organización.
El valor de iGloo está precisamente en reducir el coste de experimentar y medir una migración real. Si el piloto demuestra ahorro y estabilidad, puede ampliarse; si revela incompatibilidades relevantes, esa evidencia también es útil.
La documentación del piloto debería quedar disponible para futuras unidades y proveedores, de modo que cada nueva migración no tenga que repetir el mismo diagnóstico desde cero.
Fotografía: cottonbro studio / Pexels.