Migrar un clúster Windows Server Failover Cluster (WSFC) que hospeda grupos de disponibilidad Always On y cambiarlo de un dominio Active Directory a otro es una operación que, bien planificada, puede realizarse con minutos de inactividad y sin exponer los datos al riesgo de pérdida. En esta guía práctica se describe paso a paso cómo conseguirlo teniendo en cuenta tanto sistemas operativos modernos —que admiten la migración directa del clúster— como versiones antiguas que exigen un clúster paralelo o una reconstrucción controlada.

Resumen del escenario

Las organizaciones suelen encontrarse con la necesidad de mover sus servicios críticos a un nuevo bosque o dominio por fusiones, adquisiciones o reestructuraciones de seguridad. Cuando el servicio afectado es un clúster WSFC con SQL Server Always On, intervienen varios componentes que dependen de Security Identifiers (SID) y de objetos de dominio: la cuenta del clúster, las cuentas de los recursos Network Name, los registros DNS, los testigos de quórum y, por supuesto, las instancias de SQL Server y sus credenciales. El reto consiste en trasladar todo este ecosistema manteniendo la alta disponibilidad y con capacidad de revertir si surge algún imprevisto.

Migración directa con sistemas operativos recientes

Windows Server 2019, 2022 y 2025 incorporan de forma nativa la funcionalidad Cluster Name Account Migration, que permite cambiar el dominio de un clúster sin desmontarlo. La gran ventaja es que no se necesita reinstalar SQL Server ni volver a crear los grupos de disponibilidad; los metadatos del clúster se preservan y la interrupción real se reduce a los reinicios de los nodos.

Ventajas de la ruta directa

• No hay que reconstruir el clúster ni reinstalar aplicaciones.
• Se evita copiar o mover bases de datos de forma masiva.
• El tiempo de corte se limita a uno o dos reinicios.
• Se disminuye la complejidad operativa y el riesgo de error humano.

Pasos operativos

1. Crear una copia de seguridad exhaustiva de todas las bases, del master y del msdb. Verificar que los archivos se restauran correctamente en entornos de prueba.
2. Poner fuera de línea los recursos Network Name para detener la publicación de SPN en el dominio antiguo.
3. Ejecutar el cmdlet Remove‑ClusterNameAccount -Cluster CLUSTER01 para borrar los objetos de equipo relacionados con el clúster en el dominio de origen.
4. Detener el servicio ClusSvc, sacar cada nodo del dominio y dejarlo en grupo de trabajo. Reiniciar.
5. Unir cada nodo al nuevo dominio xyz.com y reiniciar de nuevo.
6. Iniciar ClusSvc y configurar su inicio como automático.
7. Poner en línea los recursos Network Name y recrear sus objetos con
   New‑ClusterNameAccount -Name CLUSTER01 -Domain xyz.com -UpgradeVCOs.
8. Validar el clúster con Test‑Cluster y comprobar la visibilidad de los oyentes Always On.

Durante todo este proceso, las bases de datos permanecen montadas; el downtime experimentado por la aplicación suele ser inferior a diez minutos y se circunscribe a los reinicios del sistema operativo.

Migración con reconstrucción o clúster paralelo

Las versiones anteriores a Windows Server 2019 carecen de la característica de migración directa, por lo que existen dos enfoques: reutilizar el hardware actual desmontando nodo a nodo, o desplegar un clúster paralelo y transferir la carga mediante un distributed availability group. La elección dependerá de la ventana de mantenimiento disponible, la edad del hardware y los acuerdos de nivel de servicio.

Preparativos clave

• Inventariar permisos NTFS, cuentas de servicio y trabajos de SQL Agent: todos los SID cambiarán al pasar de dominio.
• Definir un plan de reversión que permita volver al clúster original con rapidez; por ejemplo, manteniendo las LUN intactas y dejando los recursos offline en lugar de eliminarlos.
• Si se usan claves de cifrado (TDE, DPAPI), exportar certificados y guardar copias protegidas.

Método reutilizando hardware

Consiste en sacar un nodo del clúster antiguo, formatearlo lógicamente y agregarlo como nodo inicial de un clúster nuevo en el dominio destino. Se repite hasta migrar todos los nodos; al final se produce el failover definitivo. Los pasos resumidos son:

1. Expulsar un nodo del clúster en el dominio abc.
2. Desinstalar failover instance de SQL Server o quitar la réplica Always On.
3. Sacar el servidor del dominio abc y unirlo a xyz.
4. Crear un clúster mononodo en xyz e instalar la instancia FCI o la réplica AG correspondiente.
5. Mover o presentar las LUN, ajustar permisos y adjuntar las bases de datos.
6. Repetir el proceso con los nodos restantes y cambiar el rol primario cuando todo esté sincronizado.

Método con infraestructura nueva

Cuando se dispone de hardware o máquinas virtuales adicionales, la opción más segura consiste en levantar desde cero un clúster completo en el nuevo dominio y sincronizar los datos mediante un distributed availability group. De este modo, la producción sigue operativa en abc hasta que el equipo de bases confirma la replicación y planifica un failover casi instantáneo.

Aspecto	Clúster paralelo	Reutilizar hardware
Downtime	Mínimo (segundos)	Moderado (cada nodo necesita reinstalar SQL Server)
Requisitos de hardware	Nuevos servidores o VM	Ninguno adicional
Complejidad	Alta (dAG, doble monitorización)	Media (mover LUN, permisos)
Plan de reversión	Inmediato: se mantiene el clúster original intacto	Requiere volver a unir nodos a abc

Consideraciones universales

Nombre de red y resolución DNS

Utilice alias DNS o un equilibrador de carga interno para el oyente Always On. De esa forma, el connection string de la aplicación no cambia y se gana flexibilidad ante futuras migraciones. Tras mover el clúster, actualice el registro A o el CNAME en la nueva zona DNS y limpie la caché de los clientes sensibles.

Cuentas de servicio y permisos

Cree en el dominio destino las cuentas de servicio con los mismos nombres que en el dominio origen, aunque el SID sea distinto. Otorgue solo los privilegios mínimos: «Log on as a service», acceso a las LUN y permiso de «Perform Volume Maintenance Tasks» si se usa instant file initialization. Tras la migración, ejecute xp_logininfo para confirmar la resolución de SID.

Test y validaciones

• Test‑Cluster para validar redes, almacenamiento y Active Directory.
• DBCC CHECKDB en todas las bases de datos, idealmente con la opción WITH PHYSICAL_ONLY durante la ventana de mantenimiento.
• Comprobación manual de SPN: use setspn -L y verifique que los registros estén en el contenedor correcto xyz.
• Pruebas de failover controlado entre réplicas antes de pasar a producción.

Estrategia de reversión

Si el primer nodo migrado presenta errores graves, basta con sacarlo del nuevo dominio, volver a unirlo a abc y ponerlo online en el clúster original. El resto de nodos no habría cambiado y el servicio puede restablecerse en minutos. Conserve copias de seguridad recientes y evite eliminar objetos de dominio hasta que la migración finalice con éxito.

Buenas prácticas adicionales

• Mantener scripts de automatización con los cmdlets de clúster y Always On para garantizar repetibilidad.
• Aplicar etiquetado de discos coherente; tras el cambio de dominio pueden cambiar las rutas de acceso a los LUN.
• Actualizar la documentación de referencia: diagramas de red, direcciones IP y rangos de puertos utilizados por SQL Server.
• Revisar las políticas de firewall internas, en especial si el nuevo dominio pertenece a otra zona de seguridad.
• Comprobar la integración con SCCM, SCOM u otras herramientas de monitorización; a veces requieren volver a aprobar los agentes.

Conclusión

Migrar un clúster SQL Server Always On a un nuevo dominio es un proyecto delicado pero manejable cuando se comprende la dependencia entre WSFC, Active Directory y la capa de base de datos. Con sistemas operativos modernos, la ruta de migración directa es rápida y fiable; para entornos antiguos, la estrategia de clúster paralelo ofrece máxima seguridad a costa de más infraestructura. En todos los casos, la combinación de backups verificados, automatización y pruebas repetibles garantiza que el servicio permanezca disponible y que la organización disponga de un camino claro de reversión si surge algún contratiempo.