Migrar a Microsoft 365 no es comprar licencias: todo lo que pasa antes de que el correo funcione
La versión que suele venderse es simple: se compran las licencias, se crean los usuarios y la empresa "ya está en Microsoft 365".
La versión real la conocen quienes han vivido una migración mal ejecutada: correos de clientes cayendo en spam durante semanas, historiales incompletos, usuarios con dos buzones sin saber cuál usar y, en algunos casos, el dominio de la empresa siendo utilizado para enviar correos fraudulentos porque nadie configuró correctamente la autenticación del correo.
Activar las licencias es, literalmente, la parte más fácil del proyecto.
Todo lo demás es lo que distingue una migración de un accidente prolongado.
Primero la identidad, luego el correo
Antes de mover un solo buzón hay que responder una pregunta:
¿Cómo se van a autenticar los usuarios?
¿Las cuentas vivirán únicamente en la nube o se sincronizarán con el Active Directory local?
La decisión parece pequeña, pero condiciona contraseñas, accesos a otros sistemas y la administración futura del entorno.
Y hay otro paso que suele doler más de lo esperado: limpiar el directorio.
Usuarios que ya no trabajan en la empresa, cuentas compartidas, grupos que nadie utiliza e información desactualizada. Migrar desorden a la nube solo significa tener el mismo desorden, ahora con un costo mensual por licencia.
El DNS público: donde las migraciones se ganan o se pierden
Hay una pregunta que debería hacerse antes de cualquier proyecto de Microsoft 365:
¿Quién tiene acceso al DNS de tu dominio?
Sorprendentemente, muchas empresas no lo saben.
El dominio fue registrado hace años por un proveedor que ya no existe, por un ex empleado o en una cuenta cuya contraseña nadie recuerda. Y descubrirlo el fin de semana de la migración suele convertirse en una emergencia.
Pero tener acceso al DNS es apenas el comienzo.
El DNS público es el sistema que le dice al resto del mundo dónde entregar el correo de tu empresa y cómo verificar que los mensajes que envías son legítimos. Durante una migración hay que modificar, validar y monitorear registros críticos, entre ellos:
- MX, para dirigir el correo al nuevo servicio.
- Autodiscover, para la configuración automática de los clientes.
- SPF, para definir qué plataformas pueden enviar correo en nombre de tu dominio.
- DKIM, para firmar digitalmente los mensajes.
- DMARC, para indicar qué hacer cuando un correo no supera las validaciones de autenticación.
Un error en cualquiera de estos registros puede provocar que:
- Tus correos lleguen a spam.
- Algunos sistemas dejen de enviar correo.
- Se interrumpa temporalmente la recepción de mensajes.
- Tu dominio quede expuesto a intentos de suplantación y fraude.
Y hay otro detalle que suele olvidarse: muchas empresas tienen impresoras, aplicaciones, sitios web, ERPs o plataformas de terceros enviando correos con su dominio. Si nadie identifica esos sistemas antes de la migración, dejan de funcionar el día del cambio.
Por eso, una migración a Microsoft 365 también es un proyecto de inventario y de gobierno del DNS público.
Las licencias se compran en minutos.
Recuperar la reputación de un dominio o descubrir por qué un sistema dejó de enviar correos puede tomar semanas.
Migrar los datos sin detener la operación
El historial de correo, los calendarios y los contactos deben copiarse desde el sistema de origen, ya sea:
- Un Exchange local.
- Un hosting con IMAP.
- Otro proveedor de correo.
Cada plataforma tiene sus propios métodos y limitaciones.
La estrategia que mejor funciona suele ser la migración por olas con coexistencia. Los datos se sincronizan por adelantado mientras todos siguen trabajando y el cambio definitivo ocurre cuando el buzón del usuario ya está listo.
El famoso "hagámoslo todo el fin de semana" puede funcionar en empresas muy pequeñas.
En organizaciones medianas o grandes, normalmente es la receta perfecta para un lunes caótico.
Lo que casi todos olvidan: seguridad y adopción
Seguridad desde el primer día
Una migración debería terminar, como mínimo, con:
- Autenticación multifactor obligatoria.
- Bloqueo o control de reenvíos automáticos hacia el exterior.
- Revisión de las configuraciones de seguridad predeterminadas.
- Revisión de los permisos administrativos y de las cuentas privilegiadas.
Muchas de las cuentas comprometidas en Microsoft 365 no se deben a ataques sofisticados. Se deben a configuraciones que nunca se revisaron.
Respaldo del nuevo entorno
Microsoft opera la plataforma.
Eso no significa que tenga una estrategia de respaldo diseñada para las necesidades específicas de tu negocio.
La retención estándar no sustituye una política de respaldo propia ni elimina la necesidad de contar con copias de seguridad independientes.
Gestión del cambio
Decirle a los usuarios el viernes que "el lunes cambia el correo" no es gestión del cambio.
Una migración exitosa suele incluir:
- Comunicación previa.
- Guías simples.
- Sesiones breves de capacitación.
- Soporte reforzado durante la primera semana.
La diferencia parece menor, pero suele determinar si la migración se recuerda como una mejora o como un problema.
Cuando una migración está bien hecha, nadie habla de ella
Una migración bien ejecutada es sorprendentemente aburrida.
Los usuarios llegan un lunes, su correo funciona, el historial está completo, las aplicaciones siguen enviando mensajes y nadie necesita abrir un ticket de soporte.
Ese aburrimiento es el resultado de semanas de preparación, pruebas y validaciones que las licencias, por sí solas, no incluyen.
Y si tu empresa migró a Microsoft 365 hace tiempo, vale la pena hacer una última pregunta:
¿Alguien verificó que SPF, DKIM y DMARC quedaron correctamente configurados y que todos los sistemas que envían correo siguen funcionando, o simplemente dejó de doler y todos asumieron que había quedado bien?