El Exchange Server, el servidor de correo que la empresa mantiene dentro de casa, llegó al fin del soporte de Microsoft el 14 de octubre de 2025 — tanto la versión 2016 como la 2019. Según la propia Microsoft, eso significa que el producto dejó de recibir soporte técnico para los problemas que surjan, corrección de errores que afectan la estabilidad, corrección de fallas de seguridad e incluso actualización de husos horarios. El servidor sigue encendido y funcionando con normalidad. Lo que cambia es que, si mañana aparece una vulnerabilidad nueva, ya nadie va a corregirla.
Una cobertura publicada poco después del plazo señaló que las empresas de sectores regulados — finanzas, salud, servicios esenciales — corren el riesgo de fallar una auditoría de cumplimiento si siguen operando un sistema sin soporte, además de quedar más expuestas a un ataque. Un servidor de correo sin actualización es una puerta abierta, y es justo el tipo de puerta que quien ataca sabe buscar primero.
Para quien aprueba el presupuesto, la pregunta ya no es si la migración va a ocurrir, sino cuándo, y con qué nivel de sobresalto. Hecha con método, el cambio del servidor de correo interno a Microsoft 365 (el antiguo Office 365) pasa casi sin que nadie lo note. Hecha con prisa, es justo ahí donde se pierde el mensaje de un cliente.
El riesgo de dejar el correo como está
La situación más común es conocida: alguien instaló ese servidor de correo hace años, armó las reglas y los buzones como la empresa necesitaba en ese momento, y ya no trabaja ahí. Quien hoy responde por la TI sabe que el sistema funciona, pero evita tocarlo — porque no puede explicar todos los engranajes que dependen de él, y el miedo a tumbar el correo de la empresa pesa más que la incomodidad de dejarlo quieto.
El problema es que "dejarlo quieto" tenía una fecha de vencimiento, y ya pasó. Microsoft enumera cuatro cosas que simplemente se detuvieron: soporte técnico para dudas o incidentes, corrección de errores que comprometen la estabilidad, corrección de fallas de seguridad y actualización de husos horarios. Las tres primeras suelen aparecer en el peor momento posible — cuando algo ya se rompió o cuando un atacante ya encontró el camino.
Es el tipo de situación que proveedores de servicios gestionados como Skills IT ven con frecuencia: el servidor no avisa que está desactualizado, simplemente sigue funcionando hasta el día en que se detiene — o hasta que alguien de afuera encuentra una falla que ya nadie va a corregir. Mientras tanto, cada mes que pasa es un mes más sin corrección, acumulado sobre el anterior.
La propia Microsoft recomienda empezar a planear la salida del Exchange Server cuanto antes, y señala la migración a Microsoft 365 como el camino más directo — un solo movimiento para dejar atrás la actualización de servidor, la compra de equipos y el mantenimiento de la sala técnica, y pasar a estar siempre en la versión más reciente del correo, sin necesitar otro proyecto de actualización dentro de unos años.
Por qué el camino habitual no resuelve
El camino habitual, cuando por fin se toma la decisión, suele ser uno de dos extremos: seguir posponiendo hasta que el servidor realmente falle, o intentar resolverlo todo en un fin de semana, sin inventario y sin pruebas, con la esperanza de que "solo hay que copiar los buzones a la nube".
Una investigación de Osterman Research con profesionales de TI de empresas medianas y grandes que estaban migrando sus sistemas de comunicación, publicada en 2020, encontró que casi la mitad considera que garantizar que todo siga funcionando durante la migración — sistemas activos, accesos disponibles, nada roto en el camino — es la parte más difícil del proceso. Justo detrás, 37% señaló como difícil administrar la convivencia entre el correo viejo y el nuevo mientras ambos siguen activos al mismo tiempo.
Esto tiene un motivo práctico: mientras el cambio no se completa, un mensaje dirigido a alguien ya migrado sigue llegando al servidor viejo hasta que el apuntador de entrega de internet cambie hacia la nueva dirección. Si nadie vigila esa ventana, el mensaje se pierde ahí — no porque la migración haya fallado, sino porque nadie revisó lo que seguía llegando al lugar equivocado.
Otro "camino habitual", todavía más arriesgado, es intentar mover todos los buzones de una sola vez, sin separarlos por grupos. La propia Microsoft recomienda lo contrario incluso para empresas pequeñas — mover los buzones poco a poco, revisando cada tanda antes de pasar a la siguiente, aun cuando el límite técnico permitiría mover todo junto.
Lo que tiene que existir en la práctica
Una migración de correo bien hecha se apoya en mecanismos concretos, no en cruzar los dedos.
Un inventario de buzones y de lo que depende de cada uno. Antes de mover nada, alguien necesita listar quién usa cada dirección y qué sistemas externos le envían correo — facturación, cobros, alertas de equipos, el portal de un proveedor. Esto es justo lo que suele faltar cuando la migración "descubre" un sistema roto recién cuando ya terminó.
Migración por etapas, no todo de una vez. Grupos pequeños primero — un área, una sucursal —, con revisión antes de pasar al siguiente grupo. Un error detectado a tiempo, en un puñado de buzones, es fácil de corregir; el mismo error repartido por toda la empresa no lo es.
Un período de convivencia entre el servidor viejo y el nuevo. Mientras el cambio no termina, los dos sistemas siguen activos y un mensaje puede llegar a cualquiera de los dos. Alguien necesita vigilar esa ventana hasta que la entrega apunte definitivamente a la nueva dirección.
Revisión antes de apagar lo que queda atrás. Cada buzón migrado se revisa — historial, carpetas, contactos — antes de apagar cualquier servidor viejo. Apagar primero y revisar después es como un mensaje perdido se vuelve definitivo.
Un plan para el historial y los archivos adjuntos antiguos. No todo necesita pasar al nuevo sistema el primer día; lo que importa es decidir, y dejar la decisión por escrito, en vez de dejar mensajes viejos atrás por descuido.
Así es como trabaja Skills IT: inventario antes de tocar cualquier buzón, migración por etapas con revisión entre una y otra, y el servidor viejo solo se apaga después de que el nuevo ya demostró que está recibiendo todo correctamente.
Lo que la empresa gana después
La ganancia más directa es dejar de mantener un equipo dentro de casa: sin compra de servidor nuevo dentro de unos años, sin sala refrigerada que mantener, sin nadie de guardia esperando que el disco no falle en un fin de semana. El costo de mantener ese servidor — energía, hardware, el tiempo de quien lo cuida — desaparece de la planilla y se convierte en una cuota mensual previsible, dentro de lo que ya define el contrato.
También hay una ganancia para quien usa ese correo todos los días: un buzón más grande, siempre en la versión más reciente, integración nativa con calendario, archivos y reuniones — sin necesitar otro proyecto de actualización más adelante. Y para quien decide, la ventaja central es dejar de tener que cruzar los dedos: con el servidor de correo fuera de casa y siempre actualizado, la pregunta deja de ser "¿esto todavía aguanta?" y pasa a ser qué quiere hacer la empresa con el tiempo que quedó libre.
Ninguna de estas ganancias depende de la prisa. Dependen de que la migración se haya hecho con inventario, por etapas, con revisiones en el camino — lo opuesto al fin de semana improvisado que suele ser el origen del mensaje perdido.
Preguntas para decidir la migración
Antes de fijar una fecha de inicio, vale la pena llevar estas preguntas a la próxima conversación entre la dirección y quien responde por la TI:
- ¿Alguien sabe, hoy, qué sistemas externos dependen de una dirección de correo específica? Facturación, cobros, alertas de equipos, portal de clientes — si la respuesta no está escrita en ningún lado, la migración lo va a descubrir a la fuerza, un sistema roto a la vez.
- ¿Existe un inventario de los buzones activos y de los que solo siguen ahí por el historial? Migrar sin saber qué contiene cada buzón es decidir a ciegas qué se queda y qué se pierde.
- ¿Quién va a revisar cada tanda de buzones antes de pasar a la siguiente? Sin ese paso, un error pequeño al inicio se vuelve un problema grande al final.
- ¿Qué pasa con el historial de correo cuando se apague el servidor viejo? La respuesta tiene que existir antes del apagado, no después.
- ¿Quién es el responsable único de esta migración, dentro y fuera de la empresa? Una migración sin dueño definido es la receta más común para un mensaje perdido.
