Cómo migrar un servidor de Windows a Linux sin perder datos: planificación, servicios, usuarios y seguridad

Migrar un servidor de Windows a Linux no debe empezar copiando archivos, sino entendiendo qué servicios, usuarios, permisos, datos, aplicaciones y dependencias existen. El objetivo no es “cambiar de sistema operativo” de forma improvisada, sino trasladar funciones críticas sin perder información, sin romper accesos y sin dejar brechas de seguridad.

Una migración correcta combina inventario, respaldo, pruebas, sincronización, validación, corte controlado y plan de retorno. Para archivos, Windows ofrece herramientas como Robocopy, que permite copiar datos con opciones de permisos, atributos, propietarios, auditoría, reintentos y logs; en Linux, rsync permite sincronizar archivos preservando permisos, propietario, grupo, enlaces y marcas de tiempo mediante su modo archivo.

1. Primero: definir qué estás migrando realmente

Un servidor Windows puede cumplir muchas funciones: archivos compartidos, impresión, Active Directory, DNS, DHCP, aplicaciones internas, IIS, SQL Server, bases de datos, scripts, tareas programadas, copias de seguridad, carpetas de usuarios o sistemas heredados. Antes de instalar Linux, debes separar cada función y decidir si será reemplazada, migrada, integrada o retirada.

2. Inventario obligatorio antes de tocar datos

El inventario debe incluir carpetas compartidas, tamaño, propietarios, grupos, usuarios, permisos, cuotas, archivos ocultos, tareas programadas, certificados, puertos abiertos, servicios, aplicaciones instaladas, bases de datos, dependencias, rutas, scripts y responsables. Microsoft Storage Migration Service se usa en ecosistemas Windows para inventariar servidores y facilitar migraciones de almacenamiento hacia Windows Server o Azure; aunque no migra directamente hacia Linux, muestra la importancia de una fase formal de inventario antes del traslado.

# Carpetas compartidas
Get-SmbShare | Select-Object Name, Path, Description

# Permisos de carpetas compartidas

Get-SmbShareAccess -Name "NombreDelRecurso"

# Servicios instalados

Get-Service | Sort-Object Status, Name

# Tareas programadas

Get-ScheduledTask | Select-Object TaskName, TaskPath, State

# Puertos en escucha

netstat -ano | findstr LISTENING

# Usuarios locales

Get-LocalUser
Get-LocalGroup

3. Elegir la distribución Linux correcta

Para servidores empresariales, no conviene elegir Linux solo por preferencia personal. Debes considerar soporte, ciclo de vida, repositorios, experiencia del equipo, compatibilidad con hardware, integración con Active Directory, documentación, seguridad, copias, monitoreo y herramientas de administración.

4. Respaldo antes de migrar: no existe migración sin copia verificable

Antes de copiar datos al nuevo servidor Linux, debes tener un backup completo, verificable y restaurable del servidor Windows. No basta con “copiar carpetas”; también debes guardar configuraciones, permisos, bases de datos, certificados, tareas programadas, claves de aplicación y documentación de servicios.

En bases de datos, la estrategia depende del motor. PostgreSQL documenta pg_dump como herramienta para extraer una base en archivo script o formato de archivo; combinado con pg_restore, permite restaurar selectivamente objetos y trasladar datos entre máquinas o arquitecturas. MariaDB documenta mariadb-dump como respaldo lógico para copiar bases o colecciones de bases hacia otro servidor.

# PostgreSQL
pg_dump -Fc -f respaldo_app.dump base_app
pg_restore -l respaldo_app.dump

# MariaDB / MySQL compatible

mariadb-dump --databases base_app > respaldo_base_app.sql

# Comprimir respaldos

tar -czf respaldo-config-windows.tar.gz carpeta_exportada/

5. Migrar archivos sin perder estructura ni permisos

Para servidores de archivos, el reto no es solo copiar gigabytes. El reto es conservar nombres, fechas, estructura, atributos, permisos, propietarios y comportamiento esperado por los usuarios. Robocopy puede copiar datos entre ubicaciones Windows y recursos compartidos, con opciones como copia en modo backup, reintentos, multihilo y registro detallado.

Una opción práctica es preparar el servidor Linux con Samba, exponer temporalmente un recurso compartido de destino y copiar desde Windows hacia ese recurso usando Robocopy. Luego se validan conteos, tamaños, permisos y accesos reales desde estaciones de usuario.

robocopy "D:\Datos" "\\linux-filesrv\datos" /MIR /COPY:DATSO /DCOPY:DAT /R:2 /W:5 /MT:16 /LOG:C:\logs\migracion_datos.log

# /MIR      replica árbol de directorios

# /COPY     define qué información se copia

# /DCOPY    define datos de directorios

# /R /W     reducen reintentos y espera

# /MT       copia multihilo

# /LOG      deja evidencia

Cuando los datos ya están en Linux o se migran entre servidores Linux, rsync es una herramienta central. Su modo archivo -a preserva recursividad, enlaces, permisos, marcas de tiempo, grupo, propietario y dispositivos; opciones adicionales permiten preservar ACLs y atributos extendidos según el sistema de archivos y privilegios disponibles.

# Copia desde un origen Linux a destino Linux
rsync -avh --progress /datos/ usuario@nuevo-servidor:/datos/

# Simular antes de ejecutar

rsync -avhn --delete /datos/ usuario@nuevo-servidor:/datos/

# Preservar ACLs y atributos extendidos cuando aplique

rsync -aAXHv --numeric-ids /datos/ usuario@nuevo-servidor:/datos/

6. Samba: reemplazar un servidor de archivos Windows

Samba permite que un servidor Linux comparta archivos e impresoras con clientes Windows. Ubuntu documenta que Samba puede configurarse como servidor de archivos o impresión para clientes Windows, y también como miembro de un dominio Active Directory cuando se necesita autenticación centralizada.

Si la empresa ya tiene Active Directory, lo recomendable no suele ser crear usuarios locales duplicados en Linux, sino unir el servidor Samba al dominio para que los usuarios sigan autenticándose con sus credenciales corporativas. Ubuntu indica que un servidor Samba debe unirse al dominio AD antes de servir archivos e impresoras a usuarios de Active Directory.

[datos]
   path = /srv/samba/datos
   browseable = yes
   read only = no
   valid users = @"DOMINIO\Usuarios Datos"
   create mask = 0660
   directory mask = 0770

Para compatibilidad avanzada con permisos Windows, Samba ofrece el módulo vfs_acl_xattr, que almacena ACLs NTFS en atributos extendidos. Esto puede ayudar cuando el servidor Linux será accedido principalmente por clientes Windows mediante Samba y se necesita conservar semántica de permisos cercana a NTFS.

7. Usuarios y autenticación: AD, SSSD, Winbind o usuarios locales

La migración de usuarios debe decidirse con cuidado. En empresas con Active Directory, Linux puede integrarse al dominio usando SSSD, realmd o Samba Winbind. Red Hat documenta que SSSD es el componente recomendado para conectar directamente sistemas RHEL con Active Directory, y también reconoce Samba Winbind como alternativa para acceso a recursos AD.

8. Migrar aplicaciones y servicios: no todo tiene equivalente directo

Algunos servicios migran con facilidad; otros requieren rediseño. Una aplicación web en IIS puede migrarse a Nginx/Apache si usa tecnologías compatibles, pero una aplicación muy dependiente de componentes Windows, COM, rutas locales, autenticación integrada o librerías específicas puede necesitar contenedor, reescritura, compatibilidad .NET moderna o mantenerse temporalmente en Windows.

9. Bases de datos: exportar, probar y medir tiempos

La migración de bases de datos exige pruebas separadas. Hay que medir tamaño, tiempo de exportación, tiempo de importación, codificación, usuarios, permisos, procedimientos almacenados, extensiones, jobs, índices, collation, drivers de aplicación y compatibilidad de consultas.

PostgreSQL destaca que pg_dump puede respaldar una base y que los formatos de archivo combinados con pg_restore ofrecen un mecanismo flexible de archivo y transferencia. MariaDB advierte que los respaldos lógicos con mariadb-dump pueden generar archivos grandes y restauraciones lentas en datasets grandes, por lo que conviene probar tiempos reales antes del corte.

1. Exportar respaldo desde Windows o servidor origen.
2. Importar en Linux en entorno de prueba.
3. Comparar número de tablas, registros y tamaños.
4. Ejecutar consultas críticas de la aplicación.
5. Validar usuarios y permisos.
6. Probar backup y restore desde el nuevo servidor Linux.
7. Medir tiempo total para definir ventana de corte.

10. Seguridad del nuevo servidor Linux

No tiene sentido migrar datos a Linux y dejar el servidor abierto o mal configurado. La seguridad debe aplicarse desde el primer arranque: actualizaciones, firewall, SSH con llaves, usuarios mínimos, sudo controlado, SELinux/AppArmor, logs, backups, monitoreo y revisión de servicios activos.

OpenSSH documenta opciones como PermitRootLogin, PasswordAuthentication, AllowUsers, AllowGroups y AllowTcpForwarding, útiles para endurecer acceso remoto. En un servidor migrado, SSH debe quedar limitado a administradores autorizados, preferentemente mediante llaves y acceso por VPN o IPs permitidas.

# Actualizar
sudo apt update && sudo apt upgrade
# o
sudo dnf upgrade

# Revisar servicios activos

systemctl --type=service --state=running --no-pager

# Revisar puertos

sudo ss -tulpen

# Configuración SSH recomendada

sudo nano /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers adminlinux

sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

11. Pruebas antes del corte definitivo

La fase de pruebas debe simular usuarios reales. No basta que el administrador pueda ver carpetas. Deben probar los grupos de contabilidad, logística, gerencia, TI, soporte externo y usuarios comunes. También hay que probar aplicaciones, rutas UNC, impresión, scripts, backups, antivirus/EDR, monitoreo y restauración.

12. Sincronización final y ventana de corte

La migración ideal tiene al menos dos copias: una copia inicial grande y una sincronización final corta. La primera puede hacerse días antes; la segunda se realiza durante la ventana de corte, cuando los usuarios dejan de escribir en el servidor Windows. Esto reduce tiempo de parada y evita pérdida de cambios recientes.

1. Avisar ventana de mantenimiento.
2. Bloquear escritura en el servidor Windows.
3. Ejecutar sincronización final.
4. Exportar/importar cambios finales de base de datos.
5. Cambiar DNS, alias o rutas compartidas.
6. Probar con usuarios clave.
7. Monitorear logs y rendimiento.
8. Mantener Windows en solo lectura durante periodo de seguridad.
9. Cerrar migración solo después de validación formal.

13. Documentar equivalencias: lo que estaba en Windows y dónde quedó en Linux

La documentación evita confusión después del cambio. Cada recurso Windows debe tener su equivalente Linux: ruta, servicio, puerto, dueño, backup, usuario técnico, ubicación de logs, archivo de configuración y procedimiento de recuperación.

14. Errores comunes que causan pérdida de datos o caída

15. Checklist final de migración Windows a Linux

16. Preguntas clave

Recomendamos

En resumen

Migrar un servidor de Windows a Linux sin perder datos exige planificación, no improvisación. Primero se inventarian servicios, carpetas, usuarios, permisos, aplicaciones y bases de datos. Luego se prepara Linux, se hacen respaldos verificables, se copian datos con herramientas adecuadas, se prueban permisos, se sincroniza en la ventana de corte y se mantiene el servidor original en solo lectura hasta confirmar que todo funciona.

La migración será exitosa cuando los usuarios puedan trabajar igual o mejor que antes, los datos estén completos, los permisos sean correctos, los servicios estén monitoreados, los backups funcionen y la seguridad de Linux haya sido endurecida desde el primer día.