Server 2012 está oficialmente al final de su vida útil, y el fin del soporte de Server 2012 R2 es el 23 de octubre de 2023 – así que, naturalmente, no está solo: los servidores 2012 deben actualizarse cuanto antes. Por supuesto, usted quiere minimizar el tiempo y el esfuerzo dedicados a ello, y automatizar la mayor parte posible de esa actualización.

En esta guía, cubriremos las opciones para actualizar Server 2012 a 2022 / 2019, preservando la plena funcionalidad de las aplicaciones del servidor, las bases de datos, los perfiles de usuario, los recursos compartidos y los datos. Tenga en cuenta que este mismo proceso funciona también para servidores que no son 2012; simplemente nos centramos en 2012 debido a su fin de vida en 2023.

Existen dos enfoques principales para actualizar Server 2012:

Actualización in situ de 2012 a 2019 / 2022: En esta opción, usted actualiza el servidor 2012 a un SO más reciente, instalando una versión de servidor más nueva “encima” del 2012 original.
Actualización por migración de Server 2012 a un nuevo Server 2019 / 2022: En este enfoque, usted transfiere el contenido de su servidor 2012 a un servidor independiente que ejecuta 2022 / 2019.

¿Solo quiere saber cómo automatizar la actualización de 2012 a 2022 / 2019, y no necesita un tutorial general?
Haga clic aquí para omitir e ir a la parte con el proceso de actualización real.

¿Es posible la actualización in situ de 2012 a 2022 para su servidor?

Aquí tiene un cuadro de las rutas de actualización de Windows Server (crédito: Microsoft.com)

Como puede ver en el cuadro anterior, no es posible realizar una actualización in situ de 2012 a 2022 directamente. Sin embargo, para servidores locales (físicos o virtuales), es posible hacerlo en 2 “saltos”:

Primero, actualice su Server 2012 / 2012r2 a Server 2016
Después, actualice el Server 2016 a 2022

Tenga en cuenta, sin embargo, que no es posible actualizar in situ los servidores Azure o AWS – no de la manera “tradicional”. Para servidores alojados en la nube como esos, debe utilizar una “actualización por migración” descrita a continuación.

Actualización in situ vs actualización por migración: pros y contras

La principal ventaja de una actualización in situ (cuando es realmente posible) es que – al menos a primera vista – suena muy simple e indolora. Al fin y al cabo, solo instala un nuevo SO Windows Server (dos veces), y no tiene que lidiar con la reinstalación de sus aplicaciones / datos. Todo lo que necesita hacer es:

Instalar Windows 2016 “encima” de su actual Server 2012 o Server 2012r2
Una vez hecho, instalar Server 2022 (o Server 2019) “encima” del 2016

Ambos pasos pueden realizarse descargando y montando la ISO apropiada.

Desafortunadamente, la realidad no siempre es tan simple. Hay 3 preocupaciones principales en torno a las actualizaciones in situ:

Está destruyendo su servidor actual y funcional: El principal problema de las actualizaciones in situ es que, una vez que empieza, ya no tiene un servidor funcional, y no lo tendrá hasta que el nuevo esté plenamente operativo. Así es como están diseñadas las actualizaciones in situ. Por supuesto, tiene una copia de seguridad del 2012 original (algo absolutamente imprescindible en cualquier actualización in situ), pero restaurarla no siempre es tan sencillo. Y el propio proceso de actualización a menudo puede llevar mucho tiempo – durante el cual, de nuevo, no tiene un servidor operativo. Este es un problema inherente a las actualizaciones in situ, que a menudo las descarta para servidores de misión crítica.

El proceso de actualización no siempre es fluido: Sobre el papel, “simplemente instalar un nuevo SO dos veces” no suena tan mal. Desafortunadamente, la cruda realidad es que las instalaciones de SO in situ suelen ir menos bien de lo esperado. Si hay problemas relacionados con el SO en el servidor de origen, su instalación puede que ni siquiera comience hasta que los solucione. Además, cualquier administrador de TI que haya realizado algunas actualizaciones in situ puede decirle lo que se siente al ejecutar un proceso de actualización durante 3 horas solo para toparse con un error como “0x800F081E The installation failed in the SAFE_OS phase with an error during INSTALL_UPDATES operation”.

El resultado final debe verificarse a fondo: Suponiendo que haya podido completar el proceso de actualización in situ (2012 a 2016, luego 2016 a 2022 o 2019), el siguiente paso es verificar a fondo cada componente y cada aplicación del servidor. Está salvando una brecha de unos 10 años, y no mediante una instalación limpia, sino mediante una serie de actualizaciones. Es importante asegurarse de que todos los componentes del SO siguen siendo funcionales y se comportan como se espera.

En resumen: en teoría, las actualizaciones in situ suenan prometedoras. En la práctica, no siempre es así. Vale la pena intentarlo en algunos casos, normalmente para servidores que no son de misión crítica – y cuando funciona, ahorra una gran cantidad de tiempo y esfuerzo. Para la mayoría de los servidores, sin embargo, la actualización in situ no es el mejor enfoque en general.

De hecho, muchos fabricantes afirman abiertamente que las actualizaciones in situ deben evitarse – como VMWare aquí: “La actualización in situ del sistema operativo invitado (entre versiones principales del SO, como Windows Server 2016 o Windows Server 2019 a Windows Server 2022) no está recomendada. La mejor práctica es instalar una nueva versión principal del SO en una nueva VM”.

¿Hay una forma mejor de actualizar de 2012 a 2019 / 2022?

Con todo esto en mente, la pregunta inmediata es – si la actualización in situ no es una buena idea, ¿qué se puede hacer en su lugar? La respuesta es – una actualización por migración de 2012 a 2022 / 2019.

Migración: un camino diferente para actualizar de Server 2012 a Server 2022 o Server 2019

La actualización por migración es la alternativa a las actualizaciones in situ “a la antigua”: usted instala un nuevo Server 2022 o 2019, y transfiere a él el contenido del 2012 / 2012r2. El resultado final es que tiene todo funcionando en el reemplazo 2022 / 2019.

Está claro que la actualización por migración elimina de inmediato 2 de las desventajas de la actualización in situ descritas anteriormente:

No destructiva, con poco o ningún tiempo de inactividad: Su servidor original permanece operativo en todo momento, y no se destruye ni se ve afectado de ninguna manera. Solo cambia al servidor de destino cuando está plenamente operativo y listo para usarse – lo que minimiza (o incluso elimina) el tiempo de inactividad y el riesgo.

Instalación limpia, partiendo del SO más reciente: No arrastra consigo 10 años de actualizaciones incrementales y 3 versiones diferentes del SO. En su lugar, ejecuta directamente el SO más reciente.

Queda el 3er punto: el propio proceso de actualización.

El problema de la migración es que, si la hace manualmente, puede consumir una enorme cantidad de tiempo y esfuerzo. Reinstalar aplicaciones, reconstruir configuraciones, intentar recordar cómo se montó todo en su momento, copiar datos y permisos, recursos compartidos, personalización, todas esas pequeñas cosas que hacen que un servidor funcione – la lista sigue, y el trabajo de esa lista puede durar días (por no hablar del error humano).

Afortunadamente, hay una solución para esto: la migración puede automatizarse utilizando un software de migración de servidores dedicado – Zinstall WinServ – y este tutorial le mostrará cómo.

Esto funciona para cualquier combinación de plataformas: 2012 físico a 2022 físico, físico a VM / nube, VM 2012r2 local a un servidor AWS 2019, una VM Azure con Server 2012 a una VM Azure con Server 2022 (sí, puede usar esto para lograr en la práctica la “imposible” actualización in situ de Azure).

Todo esto es migración nativa, no virtualización de aplicaciones / lift-and-shift / clonación. Las aplicaciones se instalan realmente en el servidor de destino, los recursos compartidos se configuran, los datos y ajustes se transfieren; lo único que no se transfiere es el propio SO antiguo.

Una migración automatizada elimina la última desventaja, y permite realizar actualizaciones de 2012 a 2022 / 2019 de forma limpia, eficiente y segura.

Veamos cómo se hace.

Demostración en vídeo – migración de Server 2012 a 2022 / 2019

Antes de empezar: audite sus servidores 2012, haga copias de seguridad y planifique

Audite sus servidores: En un entorno típico, tendrá varios tipos de servidores diferentes. Habrá servidores orientados a roles, centrados en roles de Windows Server como controlador de dominio, Active Directory, IIS, Exchange, DNS, DHCP. La migración de roles no está automatizada y debe hacerse manualmente.

El grupo más común, sin embargo, es el de los servidores de aplicaciones y archivos, que ejecutan las verdaderas aplicaciones de negocio (LOB) y almacenan los datos de la empresa. Normalmente superan con creces en número al grupo basado en roles.

Los servidores de aplicaciones y archivos pueden migrarse automáticamente y a gran escala, utilizando software de migración de servidores (como se muestra a continuación).

En la fase de planificación, debe preparar una lista de los servidores del entorno y averiguar de qué es responsable cada uno. Solo con saber cuántos servidores de roles y cuántos servidores de aplicaciones tiene, ya es un gran paso. Dado que la migración de servidores de aplicaciones puede automatizarse, podrá elaborar una estimación bastante precisa del tiempo y el esfuerzo que requerirá la migración.

Verifique que sus copias de seguridad están actualizadas y son realmente restaurables: Cualquier actualización importante puede salir mal, y sin una copia de seguridad válida y actualizada, corre el riesgo de perder todo lo que tenía en el servidor. ¡Asegúrese de verificar que su copia de seguridad no está dañada y está lista para restaurarse si es necesario!

Decida el tipo de reemplazo: Una vez que haya decidido reemplazar un servidor, tiene varias opciones respecto a cuál será el reemplazo. Puede ser un servidor físico local con Windows 2022 / 2019, un servidor VM local (ESX / Hyper-V, por ejemplo), o un servidor en la nube fuera de sus instalaciones (como una migración a Azure o a Amazon AWS). Si utiliza WinServ, es compatible con cualquiera de esas transferencias, por lo que la dificultad de la migración no varía significativamente según su elección.

Cómo actualizar Server 2012 a Server 2022 / 2019

El proceso siguiente describe los pasos para actualizar de Server 2012 / 2012 R2 a un nuevo Windows Server 2016 / 2019 / 2022.

Cubriremos la migración local (el servidor de destino está en la misma red que el de origen) y la migración externa (el servidor de destino está fuera de las instalaciones, como una migración de servidor a Azure / AWS).

Cómo actualizar Server 2012 a Server 2022 / 2019 – migración local

Ejecute Zinstall WinServ en ambos servidores.
Seleccione el primer escenario, “Moving between two machines”, en ambos servidores.
En el servidor 2012, elija la opción “This is the Source” y déjelo en marcha. Quedará a la espera de la conexión del nuevo.
En el Server 2022 / 2019 de destino, elija la opción “This is the Target”.
WinServ detectará automáticamente el servidor de origen. Alternativamente, si los servidores están en subredes diferentes, puede especificar manualmente la dirección IP del servidor de origen.
Si desea seleccionar exactamente lo que quiere transferir, utilice el menú Advanced. Si solo quiere transferirlo todo, no necesita entrar en el menú Advanced.
Haga clic en Next y luego en Go para iniciar la migración.
La transferencia tardará un poco (dependiendo de la cantidad de datos que tenga que transferir), y le informará cuando haya terminado (también genera un registro de texto del proceso).

¡Eso es todo! Ese es el proceso de migración completo. Por supuesto, no es toda la migración: tuvo que preparar el servidor antes de ejecutar esto, y debe revisar los resultados (ver más abajo), pero acaba de automatizar la mayor parte del trabajo tedioso de la actualización.

Cómo actualizar Server 2012 a Server 2022 / 2019 – externa (Azure, AWS o cualquier actualización indirecta)

Ejecute Zinstall WinServ en ambos servidores.
En el servidor de origen, seleccione la 3ª opción, “Moving from Machine to Container”. Esto permite capturar el servidor en un único archivo contenedor (una “imagen migrable”), y luego desplegar desde este al servidor de destino.
Elija dónde guardar el contenedor (un recurso compartido de red, un NAS, incluso un disco USB – cualquier tipo de almacenamiento), y pulse Go para realizar una captura completa del servidor de origen en esa ubicación.
Una vez hecho, haga que el contenedor sea accesible en el servidor de destino. Por ejemplo, si el destino es un servidor alojado en la nube, suba el contenedor a un almacenamiento en la nube al que el servidor de destino pueda acceder.
Ejecute WinServ en el nuevo servidor 2022 / 2019, y seleccione la 4ª opción, “Moving from Container to Machine”
Cuando se le solicite, indique la ubicación donde está almacenado el contenedor.
Si desea seleccionar exactamente lo que quiere transferir, pulse el menú Advanced. Si solo quiere transferirlo todo, no necesita entrar en el menú Advanced.
Haga clic en Next y luego en Go para iniciar la migración.
La transferencia tardará un poco (dependiendo de la cantidad de datos que tenga que transferir), y le informará cuando haya terminado.

Cómo tratar las aplicaciones incompatibles:

Algunas aplicaciones heredadas de terceros que se ejecutan en Windows Server 2012 pueden ser incompatibles con Windows Server 2022 / 2019. Esta parte es igual para las actualizaciones in situ “a la antigua” y para las actualizaciones por “migración”, ya que la limitación es una propiedad de la propia aplicación.

En 2012, las aplicaciones incompatibles son bastante menos comunes que en Server 2003 / 2008, pero aún puede ocurrir – normalmente con software heredado que no se ha actualizado para versiones más recientes del SO.

Tenga en cuenta que “antiguo” no significa necesariamente “no funcionará”. Muchas aplicaciones siguen funcionando sin problemas.

Si estas aplicaciones no pueden eliminarse de inmediato y son fundamentales para el funcionamiento continuo de la organización, la opción recomendada para preservar su funcionamiento es realizar una migración virtualizada de esas aplicaciones a una instancia virtual de Server 2012 que se ejecute en el nuevo servidor de reemplazo. Después, continúe tomando las medidas necesarias para retirar progresivamente esas aplicaciones y dejar de ejecutar las instancias 2012 virtualizadas.

WinServ es genérico respecto a las aplicaciones, y puede migrar incluso aplicaciones personalizadas e internas que el mundo exterior nunca ha visto – siempre que sean capaces de ejecutarse en el nuevo servidor. Aquí tiene una lista parcial de aplicaciones comunes que nuestros clientes han migrado en el pasado:

SQL Server
MS SQL
MySQL
SAP (incluido SAP Business One)
Oracle
Sybase
DB2
Java Application Server
Crystal Reports
Avaya
PeopleSoft
JD Edwards Enterprise One (JDE E1)
Citrix
Apache (solo Windows)
WebSphere
Microsoft Dynamics
…y muchas, muchas más

Después de la migración:

Una vez que se completa el proceso de migración, es hora de verificar los resultados.

Es posible que deba ajustar el DNS de su dominio para que apunte al nuevo servidor donde sea necesario. Por ejemplo, cambiando la entrada DNS de su antiguo servidor CRM a la dirección del nuevo servidor.
Lo mismo ocurre con los scripts de inicio de sesión y la política de GPO.
Inicie todas las aplicaciones y consolas que utilice y verifique que se cargan correctamente.
Utilizando una estación de trabajo cliente, verifique que los clientes pueden acceder correctamente al servidor migrado y que sus aplicaciones se ejecutan sin problemas.

¡Felicidades! Su actualización de 2012 a 2022 / 2019 ya está completa.

¿Está listo para actualizar su Server 2012 a 2022 / 2019?

Obtenga Zinstall WinServ aquí

¿Busca licencias de evaluación / precios por volumen / más información?

Escríbanos a sales@zinstall.com para obtener ayuda.

Cómo actualizar Server 2012 a Server 2022 / 2019 – in situ o por migración