500.000 computadoras. Ese es el número que Francia puso sobre la mesa cuando anunció su migración a Linux. Quinientas mil máquinas del Estado francés moviéndose a un sistema operativo libre. Cuando lo leí tuve que releer dos veces — no porque me parezca imposible, sino porque yo viví en primera persona lo que pasa cuando alguien tira ese mismo decreto sin pensar en lo que hay debajo.
Y lo que hay debajo es un quilombo.
France Linux migration: el anuncio que todos celebran sin leer la letra chica
La Gendarmería Nacional Francesa empezó esto hace años — ellos son el caso de estudio que todo el mundo cita. Ubuntu, LibreOffice, Firefox. Funcionó. Y ahora el gobierno de Macron está empujando una expansión masiva. Los titulares son hermosos: soberanía digital, independencia de Microsoft, ahorro de licencias.
Todo correcto. Todo real.
Pero hay algo que los artículos de tecnología no cuentan: la Gendarmería es una organización con disciplina militar, un área de IT centralizada con poder real para tomar decisiones, y — dato clave — aplicaciones internas desarrolladas a medida que ellos mismos controlan. Eso no es el Estado promedio. Eso no es una municipalidad argentina. Eso no es la dependencia provincial donde yo pasé seis meses de mi vida entre 2022 y 2023 tratando de ayudar con una migración que terminó siendo uno de los fracasos más instructivos que viví.
El Frankenstein que ningún decreto puede parchear
Me llaman para consultoría en una dependencia provincial. No voy a dar nombres porque no es el punto — el punto es que esto es representativo, no excepcional. El brief inicial era simple: "queremos migrar 200 puestos de trabajo a Ubuntu para ahorrar las licencias de Windows". El ahorro proyectado: $40.000 USD por año. Razonable.
Lo que encontré cuando empecé a auditar la infraestructura:
Active Directory con 15 años de historia. Grupos de seguridad heredados de administraciones anteriores. Políticas de grupo que nadie documentó. Usuarios que tenían permisos de cosas que ya no existían. El equivalente digital de una ciudad que fue creciendo sin plan regulador.
Impresoras. Dios mío, las impresoras. Tres modelos distintos de Ricoh con drivers que solo existían para Windows XP. Una Kyocera de 2008 que el área contable usaba para formularios específicos y que tenía el driver embebido en una DLL de 32 bits que ya no compilaba en nada. Cuando pregunté si podían cambiar la impresora, la respuesta fue: "esa impresora está en el inventario del Estado, para darla de baja necesitamos un expediente que tarda dieciocho meses".
El ERP. Acá es donde todo se derrumbó. El sistema de gestión — que manejaba desde liquidación de sueldos hasta órdenes de compra — corría en una aplicación web que requería Internet Explorer 11. No Edge en modo compatibilidad. IE11 real. El proveedor del ERP era una empresa mediana que había ganado la licitación en 2011 y cuyo contrato de mantenimiento se renovaba automáticamente. Cuando los llamé para preguntar si tenían roadmap para modernizar la app, la respuesta fue: "estamos evaluando una migración para 2026".
El antivirus corporativo. Solo tenía agente para Windows. El contrato de licencia tenía dos años de vigencia restantes.
Y la lista seguía. Cada capa que levantabas revelaba otra dependencia atada a Windows no por preferencia, sino por acumulación histórica de decisiones tomadas sin considerar el lock-in futuro.
El problema técnico real: no es el OS, es el stack completo
Aquí está la cosa que los anuncios políticos no capturan: Windows no es solo un sistema operativo. En una organización con más de 50 personas, Windows es la infraestructura. Es el directorio, es la gestión de políticas, es el SSO, es la integración con la impresora, es el cliente del ERP, es el visor de PDF con firma digital del AFIP.
Migrar el OS sin migrar el stack es como cambiar el motor de un auto sin tocar la transmisión. El auto no va a andar.
Lo que realmente necesitás para que una France Linux migration funcione a escala — o cualquier migración gubernamental — es esto:
# Auditoría real de dependencias antes de tocar nada
# Este script lo armé para la dependencia — busca ejecutables que llamen a componentes Windows-only
#!/bin/bash
# Escaneá todos los accesos a shares de red y dependencias de aplicaciones
# Correlo ANTES de planear cualquier cosa
echo "=== Auditando dependencias críticas ==="
# Verificá qué aplicaciones están registradas y sus requerimientos
wmic product get name,version > apps_inventory.txt
echo "Inventario de apps guardado en apps_inventory.txt"
# Buscá referencias a IE en shortcuts y configuraciones
grep -r "iexplore" /c/Users --include="*.lnk" --include="*.url" 2>/dev/null \
| tee ie_dependencies.txt
echo "Dependencias de IE en ie_dependencies.txt"
# Auditá GPOs aplicadas al usuario actual
gpresult /H gpo_report.html
echo "Reporte de GPOs en gpo_report.html"
# Listá impresoras instaladas con sus drivers
Get-Printer | Select-Object Name, DriverName, PortName \
| Export-Csv printers_audit.csv
echo "Impresoras en printers_audit.csv"
Esto parece básico. Y lo es. Pero en la dependencia donde trabajé, nadie había hecho este audit antes de anunciar la migración internamente. El anuncio llegó primero. La realidad llegó después.
La alternativa que terminé recomendando — y que implementamos parcialmente — fue una estrategia de migración por capas:
# Fase 1: Reemplazá aplicaciones, no el OS
# Instalá los equivalentes libres sobre Windows primero
# Medí adopción y problemas ANTES de cambiar el OS
# LibreOffice en lugar de Microsoft Office
winget install TheDocumentFoundation.LibreOffice
# Thunderbird en lugar de Outlook (donde no había Exchange crítico)
winget install Mozilla.Thunderbird
# Firefox como browser principal
winget install Mozilla.Firefox
# Fase 2: Migrá el directorio a algo compatible con Linux
# Samba AD o migración a FreeIPA — esto solo SI tenés tiempo real
# No lo hagas en paralelo con el cambio de OS
# Fase 3: Recién ahí considerás cambiar el OS
# Y solo en los puestos donde validaste que no hay dependencias rotas
Resultado final de los seis meses: migramos 23 puestos de 200. Los 23 que no tenían dependencias críticas de las aplicaciones legacy. El resto siguió en Windows. El ahorro fue de $4.600 USD anuales — no $40.000. Y eso con seis meses de trabajo de consultoría que claramente no salió gratis.
¿Fracaso? Depende cómo lo mirás. Yo lo veo como el resultado honesto de un problema que nadie quiso auditar antes de prometer resultados.
Los errores que se repiten en cada migración gubernamental
Error 1: Confundir el OS con la infraestructura completa. Ya lo cubrimos. Pero vale repetirlo porque es el error más común y el más caro.
Error 2: Subestimar el costo del cambio humano. La usuaria de contabilidad que lleva 20 años usando Excel no es un problema técnico — es un problema de capacitación, de confianza, de flujo de trabajo embebido en la memoria muscular. LibreOffice Calc es excelente. Pero si la persona tiene que googlear cómo hacer algo que antes hacía con Ctrl+Shift+Algo, esa persona va a odiar Linux antes de darle una chance real.
Error 3: El proveedor del ERP como punto de fallo único. Esto es estructural en el Estado argentino — y sospecho que en muchos estados europeos también. Si el sistema de gestión crítico lo controla un tercero con un contrato de larga vigencia, vos no podés migrar. Punto. No hay Linux que te salve de eso.
Error 4: Ignorar el hardware. Las impresoras, los scanners, los lectores de huellas digitales, los dispositivos de firma digital. Linux tiene soporte de hardware excelente para hardware moderno. El hardware gubernamental tiene una esperanza de vida de 15 años y un proceso de licitación que hace que renovarlo sea casi imposible en el corto plazo.
Error 5: Anunciar antes de auditar. Este es el que más duele porque es puramente político. Se anuncia la migración como victoria, se genera expectativa, y cuando la realidad técnica aparece, el proyecto ya tiene inercia política que hace difícil ser honesto sobre los obstáculos.
Esto, dicho sea de paso, aplica a cualquier proyecto técnico de gran escala. El mismo patrón que vi con la migración de OS lo vi con proyectos de agentes de IA que prometen automatizar sin entender el contexto real. El anuncio siempre supera a la implementación.
FAQ: France Linux migration y migraciones gubernamentales
¿Francia realmente puede lograr migrar 500.000 computadoras a Linux? Técnicamente sí, políticamente sí, pero no de un día para el otro y no sin inversión masiva en middleware, capacitación y reemplazo de aplicaciones legacy. La Gendarmería lo logró en 10 años con recursos dedicados. Una migración masiva del Estado completo es otro orden de magnitud.
¿Por qué la migración de la Gendarmería funcionó y otras fallan? Tres razones: control centralizado de las aplicaciones (las desarrollaron internamente), estructura organizacional con capacidad de imponer cambios, y tiempo — no lo hicieron en un año. Cuando una organización depende de software de terceros que no controla, el margen de maniobra se reduce drásticamente.
¿Cuál es el costo real de una migración a Linux en el sector público? El ahorro en licencias es real pero parcial. El costo real incluye: consultoría de auditoría (que nadie presupuesta), capacitación de usuarios (que nadie presupuesta), desarrollo o reemplazo de aplicaciones incompatibles (que nadie presupuesta), y el costo de productividad perdida durante la transición (que nadie presupuesta). En mi experiencia, el primer año la migración cuesta más de lo que ahorra.
¿Linux Desktop está listo para el usuario corporativo promedio? Sí y no. Ubuntu LTS, Fedora, Linux Mint — son sistemas sólidos para uso general. El problema no es el sistema operativo sino el ecosistema alrededor. Si tus aplicaciones críticas son web-based y modernas, la migración es relativamente simple. Si dependés de software propietario heredado, el OS es el menor de tus problemas.
¿Tiene sentido que Argentina siga este camino? En teoría, absolutamente — la soberanía digital y el ahorro en licencias son argumentos reales. En la práctica, el Estado argentino tiene el mismo Frankenstein de infraestructura heredada, más una capa adicional de fragmentación porque cada provincia, cada municipio, cada organismo tiene su propio stack. Una migración coherente requeriría coordinación que históricamente ha sido difícil de sostener entre administraciones.
¿Qué debería pasar primero para que una migración así funcione? Auditaría primero las aplicaciones, no el OS. Inventario completo de dependencias. Luego migraría las aplicaciones a alternativas web-modernas mientras el OS queda igual. Y solo cuando el stack de aplicaciones es OS-agnostic, cambiaría el OS. Este proceso lleva años, no meses. Y requiere que los proveedores de ERP y software gubernamental modernicen sus stacks — lo cual a veces requiere cambiar las condiciones de licitación para exigir compatibilidad multiplataforma desde el contrato.
Francia tiene razón en el destino, pero el camino es más largo de lo que parece
No soy escéptico de la migración a Linux. Soy escéptico de la velocidad y de la superficialidad con que se planea.
Francia tiene razones legítimas y capacidad real para ejecutarlo — tienen una tradición de IT gubernamental más consolidada, empresas como Atos que pueden dar soporte a escala, y una voluntad política que en este caso parece tener continuidad. Si lo hacen bien, en diez años van a tener un caso de estudio increíble.
Pero "hacerlo bien" significa auditar el stack completo antes de anunciar fechas. Significa invertir en modernizar las aplicaciones legacy, no solo en cambiar el OS. Significa capacitar a los usuarios de verdad, no mandarles un tutorial de YouTube. Significa tener un plan para el proveedor del ERP que solo soporta IE11.
La misma honestidad que necesitás para planear una migración de criptografía post-quantum — que también parece lejana hasta que de repente no lo es — la necesitás para una migración de OS a escala gubernamental. El diablo está en las dependencias, no en el sistema operativo.
Yo lo aprendí con 23 máquinas migradas de 200 posibles y seis meses de trabajo. Francia lo va a aprender a escala de medio millón de computadoras.
Espero que lo aprendan antes del anuncio, no después.
¿Pasaste por algo similar? ¿Trabajaste en migraciones de infraestructura pública o corporativa? Me interesa comparar notas — especialmente si tenés experiencias con Active Directory en entornos Linux o con ERP legacy que sobrevivió contra toda lógica. Los comentarios están abiertos.
Comentarios (0)
Deja un comentario
Artículos Relacionados
Contribuir al kernel de Linux con IA: leí el hilo de HN y tengo una opinión que no le va a gustar a nadie
324 puntos en HN. Los comentarios divididos entre 'jamás' y 'ya está pasando'. Yo metí el historial completo de git de Linux en una base de datos y lo que encontré me obliga a tomar partido — aunque la respuesta no le va a gustar ni a los pro-IA ni a los puristas.
TigerFS: un filesystem adentro de PostgreSQL (y por qué esta obsesión colectiva me parece un síntoma)
Alguien metió un filesystem completo adentro de PostgreSQL. El año pasado yo metí el historial de git de Linux en una base de datos. Hay un patrón acá que vale la pena entender — no como curiosidad, sino como síntoma de cómo pensamos la abstracción.
La criptografía que usás para firmar digitalmente tiene fecha de vencimiento: qué publicó NIST y cómo migrar tu HSM
NIST finalizó los estándares post-quantum en agosto de 2024. RSA y ECDSA tienen deadline de 2035. Si firmás documentos, JWTs o certificados con un HSM, esto te afecta ahora — te explico ML-DSA, cómo impacta al hardware, y qué hacer esta semana.