Guía de migración a Microsoft 365 sin perder correo

Una migración de correo bien hecha se nota porque el lunes siguiente nadie llama enfadado. Esta es la forma de conseguirlo: no hay truco de “exportar e importar un viernes por la noche y ya”. Hay inventario, DNS pensado, una decisión explícita entre corte (cutover) y coexistencia (staged), un plan para los PST que nadie sabía que existían, los móviles que se quedan colgados del IMAP antiguo y un test del lunes que se hace de verdad, no de palabra.

En Tenerife vemos el mismo patrón una y otra vez. El hosting barato se queda pequeño, el panel se cae, o alguien pide Teams y OneDrive “como el de la otra empresa”. Se compran las licencias, se cambian los MX un jueves a las 20:00 y el viernes hay usuarios con el Outlook en bucle, móviles que no mandan y un comercial en el sur que ha perdido la carpeta de presupuestos que solo estaba en un PST del portátil. El correo no es un servicio más. Es la identidad de la empresa delante del cliente. Tratarlo como un cambio de contraseña es el origen del enfado.

Esta guía es el plan por fases que usamos cuando el objetivo es no perder mensajes, calendarios ni la cara el lunes. El producto y las licencias están en Microsoft 365 para empresas en Tenerife. Aquí no hay lista de planes Business Standard. Hay el orden que evita el desastre, y los errores que siguen saliendo cada mes.

Fase 0: inventario antes de tocar nada (sobre todo, antes de tocar el DNS)

Empieza por las personas, no por el tenant. Lista de buzones: quién es persona, quién es un alias, quién es una cuenta genérica (info@, reservas@, admin@), quién es un buzón compartido disfrazado de usuario y quién ya no trabaja aquí pero sigue recibiendo facturas de proveedores. Esa última categoría es oro: si la cortas sin aviso, el proveedor “deja de escribir” y tú crees que la migración falló. Si la dejas viva sin dueño, alguien va a leer correo ajeno en el tenant nuevo.

Inventaría clientes de correo. Outlook clásico, “nuevo Outlook”, Apple Mail, Thunderbird, webmail del panel antiguo, aplicaciones de móvil (Outlook, Mail de iOS, Gmail app apuntando a IMAP). Cada uno se rompe de una forma distinta. Apple Mail con un perfil viejo es especialmente dado a duplicar o a no soltar el servidor anterior. El comercial que “solo usa el móvil” es el que más tarde se queja y el que menos ha hecho copia.

Inventaría lo que no es el buzón y se va a perder si nadie lo nombra: calendarios compartidos, delegaciones (“María ve el calendario de Dirección”), listas de distribución, reglas de bandeja, firmas con imagen alojada en el hosting, buzones de archivo, PST en Escritorio y en “Documentos/Outlook”, y el famoso “tengo el correo también en el Gmail personal porque así lo veo”. Ese Gmail personal es una bomba de RGPD y de duplicados. Anótalo. No lo ignores para no tener la conversación incómoda.

Inventaría DNS y el resto del dominio. Dónde está el registrador, quién tiene el usuario, cuáles son los MX actuales, si hay SPF, DKIM, DMARC, si la web está en el mismo hosting que el correo (muy habitual) y si hay servicios que usan el mismo dominio para algo que no es correo: la plataforma de reservas, el ERP en la nube, un Moodle, un reenvío de un dominio antiguo. Cambiar MX no debería tumbar la web. Cambiar los nameservers enteros, sí puede. Por eso el inventario distingue “tocamos registros de correo” de “nos llevamos el DNS entero”.

Inventaría el resto de archivos. El correo es el titular; OneDrive y SharePoint son el segundo acto. Si la empresa vive de una unidad de red, no prometas que “con 365 ya no hace falta servidor” el mismo fin de semana. Esa decisión es de arquitectura, no de buzón, y está en servidor on-premise frente a cloud. Mezclar las dos mudanzas es la forma más limpia de no saber si falló el DNS o el mapeo de la unidad Z.

Cierra la fase 0 con una copia. Copia de buzones (export, backup del hosting, o una herramienta de migración que retenga) y copia de PST locales. El día que un usuario diga “me falta el 2019”, vas a querer esa red. Las copias de 365, una vez dentro, son otro diseño: retención, papelera, backup propio. El servicio está en copias de seguridad cloud. Antes de entrar, al menos no tires el origen hasta 30 días después de un lunes tranquilo.

Fase 1: tenant, identidades y el DNS que la gente subestima

Crea el tenant con el dominio verificado, pero no cambies los MX todavía. Verifica el dominio con el registro TXT, monta las cuentas, asigna licencias y decide UPN (el inicio de sesión). Lo más limpio es que el login sea el mismo que el correo: ana@empresa.com, no ana@empresa.onmicrosoft.com de por vida. Eso se hace ahora, no a los tres meses con 20 móviles ya configurados.

Aplica MFA a los administradores el día uno, y al resto antes del corte, no después. El momento de la migración es el momento en el que más phishing vas a recibir: “confirma tu nueva cuenta”, “tu buzón se migra aquí”. Avisa a la plantilla por un canal que no sea solo el correo que estás tocando: WhatsApp interno, reunión, cartel. Suena artesanal. Evita que alguien entregue la contraseña nueva a un dominio parecido.

Prepara los registros que vas a necesitar y escríbelos en una hoja, con TTL. MX hacia 365, SPF que incluya Microsoft y lo que aún tenga que salir por el servidor antiguo o por una pasarela, DKIM del tenant, DMARC al menos en vigilancia (p=none) las primeras semanas. El error clásico es un SPF que se queda solo con el hosting viejo: el correo nuevo sale de 365 y el mundo lo marca como spam. El otro error clásico es un SPF de 12 includes que se pasa de diez búsquedas DNS. Menos poesía, más comprobación con las herramientas de Microsoft y con un envío real a Gmail, Outlook.com y a un cliente.

El TTL bajo (300–600 segundos) uno o dos días antes del corte te permite rectificar. Un TTL de 24 horas el viernes es una forma de pasar el fin de semana esperando a que el planeta se entere. Coordina con quien tenga el panel del DNS. Si el registrador es un proveedor que tarda 48 horas en coger el teléfono, ese es un riesgo del proyecto, no una anécdota. En Canarias, además, confirma la hora: “a las 18:00” de un técnico en Madrid no es tu 18:00.

No toques los nameservers si no hace falta. Si la web, la tienda o el aula virtual cuelgan de esos DNS, un cambio de proveedor de DNS “porque 365 lo pide” (no lo pide: pide registros) es un corte colateral. Añade registros. No te lleves el dominio entero de rebote.

Cutover o staged: elige con el tamaño, no con el miedo

Cutover significa: un momento de corte. Se copian los buzones (o se copian justo antes), se cambian los MX, todo el mundo apunta a 365. Es limpio, corto y exige que el inventario esté bien. Encaja en empresas de pocas decenas de buzones, con un solo dominio, sin Exchange híbrido y con capacidad de parar un viernes por la tarde o un sábado. El riesgo es concentrado: si algo falla, falla para todos. La ventaja es que no vives tres meses en el limbo de “unos están aquí y otros allá”.

Staged (o una coexistencia más larga, o un híbrido con Exchange) significa: vas por lotes. Primero gerencia y un piloto, después administración, después el resto. Los MX pueden apuntar a un sitio que enruta, o usas herramientas de reenvío y de migración continua. Encaja cuando hay muchos buzones, cuando hay un Exchange local, cuando no puedes parar el hotel en pleno puente o cuando hay departamentos que no se pueden tocar en temporada. El riesgo se diluye y se alarga. El coste oculto es la coexistencia: calendarios compartidos entre “los ya migrados” y “los que no”, delegaciones rotas, y usuarios que reenvían a Gmail “mientras tanto” y luego no saben cuál es el buzón bueno.

Hay un tercer camino que no es ni cutover ni staged de libro: IMAP a 365 más un corte de MX, sin copiar historial completo. Es más barato y más rápido. Es también la forma de que alguien pierda diez años de hilos el día que el hosting borre la cuenta. Si eliges no traer historial, fírmalo con gerencia. “No pasa nada, está en el móvil” no es un archivo. El móvil guarda un trozo, sin garantía, y se pierde al cambiar de teléfono.

Nuestra regla práctica. Menos de 25 buzones, hosting común, un dominio: cutover en fin de semana, con piloto de 3 usuarios 48 horas antes (cuentas de prueba o voluntarios pacientes). Más de 40 buzones, o Exchange, o dos sedes con calendarios cruzados: staged o híbrido, aunque duela el calendario. Entremedias: cutover si el inventario está limpio y hay un partner que no desaparece el domingo; staged si el director comercial “no puede tocarse hasta abril”.

Lo que no es un método: “vamos migrando al que se queje”. Eso genera dos realidades, reglas rotas y un SPF esquizofrénico. Elige, escribe la fecha, comunica. La gente aguanta un corte anunciado. No aguanta un limbo de tres semanas en el que el correo a veces llega y a veces no.

PST, archivos locales y el buzón que “ya no está”

El PST es el cadáver en el armario de casi todas las migraciones desde hosting o desde Outlook antiguos. Es un archivo local que Outlook usa como almacén. Puede tener el correo que el usuario “archivó” para que el buzón del servidor no se llenara. Ese correo no está en el IMAP. No se va a copiar solo. Si no lo buscas, el usuario dirá el lunes que “falta todo 2022” y tendrá razón.

Busca PST en perfiles de Windows, OneDrive personal (sí, a veces están ahí, mal sincronizados), discos externos y esa carpeta “copia correo” de 2018. Importarlos a 365 se puede hacer por Outlook o por herramientas. Hazlo por lotes y avisa: un PST de 8 GB no se importa en diez minutos y el Outlook se va a quejar. No lo hagas en el mismo instante del corte si puedes evitarlo; adelántalo o déjalo para la semana 2, con el usuario ya estable en el buzón nuevo.

Ojo con importar basura. Un PST lleno de spam de 2015 no merece un sitio en el tenant. Un PST con facturas y contratos, sí. El usuario tiene que elegir, con una hora de acompañamiento, no con un “impórtame todo”. El “todo” hincha el OneDrive, el buzón y la factura de almacenamiento, y luego nadie encuentra nada.

Los adjuntos enormes y las carpetas públicas (si venías de Exchange) merecen un dueño. SharePoint y un buzón compartido no son lo mismo. Si la empresa usaba una carpeta pública como archivo de la gestoría, diseña el destino antes del corte. Si no, el lunes habrá un “eso estaba en el Outlook de todos” que ya no está en el de nadie. La vida después del buzón —Teams, SharePoint, OneDrive sin el final_v7.xlsx por WhatsApp— es otro artículo: Teams, SharePoint y OneDrive en la oficina. No prometas esa productividad el mismo lunes del corte. Primero, que llegue el correo.

Conserva el origen un mes. El panel antiguo, en solo lectura si puedes, con los buzones sin borrar. El coste de un mes de hosting es ridículo frente a una reclamación de un hilo con un cliente. Quien borra el origen el domingo porque “ya estamos en 365” confunde ganas de cerrar el ticket con profesionalidad.

Móviles, Outlook de escritorio y el resto de dispositivos

El móvil es donde se gana o se pierde la percepción de la migración. Un iPhone con un perfil IMAP viejo puede seguir enviando por el servidor anterior —o fallar en silencio— mientras el escritorio ya está en 365. La instrucción tiene que ser concreta: quitar la cuenta antigua, añadir la cuenta de Microsoft 365 (moderna, con MFA), no “poner otra vez la misma contraseña en el mismo sitio”.

Prepara una hoja de una página con capturas para iOS y Android, y un horario de soporte el día del corte. Si tienes 30 móviles y un solo técnico, no van a salir todos a las 10:00. Prioriza dirección, administración y el teléfono que atiende al público. El resto puede vivir un día con el webmail de office.com. Dilo. El webmail no es un fracaso; es el plan B que evita que alguien se invente un reenvío a Gmail.

En escritorio, decide si usáis Outlook clásico o el nuevo, y no mezcles sin criterio. El perfil nuevo debe nacer limpio, no “convertido” desde un IMAP enfermo. Si el Outlook arrastra un OST corrupto, el usuario verá fantasmas: mensajes que están y no están. Crear perfil nuevo es más corto que diagnosticar un OST durante tres horas. Los Mac con Apple Mail: o Mail bien apuntado a Exchange/365, o Outlook para Mac. Lo que peor funciona es “ya se apañará el Mail con IMAP hacia 365”. Se apañará hasta que no.

Impresoras que escanean a correo, alarmas, SAI, fotocopiadoras y erps que “mandan avisos a admin@” son dispositivos. Cambia SMTP, usuario y, si el aparato solo sabe SMTP básico, usa un conector o una bandeja específica. Si no, el lunes la fotocopiadora no envía y el de administración jura que “el correo no funciona”. El correo funciona. El relé de 2016, no.

Tablets de almacén, iPad de sala, el Mac de diseño: misma lógica que el móvil. Si hay flota Apple, un MDM ayuda; si no, una lista y media hora por puesto. No asumas que “como es Apple ya está en iCloud y da igual”. El iCloud personal no es el buzón de la empresa. Mezclarlos es el siguiente incidente de RGPD, no una solución.

El Monday test (y la semana en la que aún no has terminado)

El Monday test no es “abrir el Outlook y ver si llega un correo de prueba”. Es una lista que se ejecuta el lunes por la mañana, en voz alta, con gerencia informada. Uno: envío interno entre dos usuarios migrados. Dos: envío a un Gmail y a un Hotmail/Outlook.com ajenos, y respuesta. Tres: recepción desde un proveedor real (pide a la gestoría o a un proveedor que escriba). Cuatro: un adjunto de 8–10 MB. Cinco: una reunión de calendario convocada y vista en un móvil. Seis: un buzón compartido (info@) leído por dos personas. Siete: una factura o un aviso automático del ERP o de la fotocopiadora. Ocho: SPF/DKIM/DMARC que no fallen en un visor de cabeceras.

Si algo de esa lista falla, no “ya lo vemos a lo largo de la semana”. Se queda el técnico. El deterioro de confianza de una migración ocurre el lunes entre las 9:00 y las 11:00. A las 16:00, aunque lo hayas arreglado, el relato interno ya es “la mudanza ha salido mal”. Por eso el corte se hace cuando hay alguien el lunes, no cuando todo el mundo se ha ido de puente.

La semana 1 es de reglas y de firmas, no de SharePoint. Recrea las reglas críticas (no las 40 reglas de “mover newsletters”). Recrea delegaciones. Revisa cuotas. Enseña la papelera y la recuperación de elementos. Enseña que el OneDrive no es el buzón. Quita el acceso al webmail antiguo para evitar que alguien siga trabajando allí “porque me acostumbré”.

La semana 2–4 es de limpieza. PST importados. Alias que faltaban. DMARC que pasa de vigilancia a cuarentena si los envíos están limpios. Baja del hosting antiguo, no antes. Revisión de licencias: buzones compartidos que no necesitan licencia completa, cuentas de sala, quien tiene E3 por error. Y una conversación de retención: qué se guarda y cuánto, porque el RGPD no desaparece al cambiar de logo en la esquina del Outlook. Esa conversación, si guardáis datos de clientes en el buzón (y casi todos lo hacéis), enlaza con RGPD y backups: el tenant no es un trastero eterno por el hecho de estar en Microsoft.

Cierra el proyecto con un documento de una página: MX, panel DNS, admins del tenant, dónde están las copias, quién se da de baja el hosting y la fecha en la que se borrará el origen. Incluye también el recuento de licencias (quién tiene qué plan y por qué); el detalle de compra y renovación está en licencias dentro de servicios. Entrégaselo a gerencia. El partner que se lleva esa información en la cabeza te está dejando un futuro incidente de “no sabemos las claves del dominio”.

Errores que vemos cada mes (para no repetirlos)

Cambiar MX un jueves por la tarde sin piloto. Borrar el hosting a los tres días. No buscar PST. Dejar a los móviles “que se actualicen solos”. Olvidar el SPF y pasar una semana en spam de clientes. Migrar solo a gerencia y dejar info@ en el servidor viejo. Usar la misma contraseña débil “para que sea fácil el día del cambio”. Hacer el corte en agosto con la mitad de la plantilla de vacaciones y el técnico también. Prometer Teams y la unidad Z el mismo fin de semana. Ninguno de estos errores es exótico. Todos son evitables con las fases de arriba.

El error más caro no es técnico: es no comunicar. Un correo del viernes a las 21:00 (“el lunes usad office.com”) no lo lee nadie. Una reunión de 20 minutos el jueves anterior, con la hoja de móviles en la mano, evita quince tickets. Si la empresa tiene turnos —hotel, clínica, comercio—, comunica por turnos. El de noche no estaba en la reunión de las 10:00. El correo del lunes a las 8:00, para él, ya es tarde.

Preguntas frecuentes

¿Se pueden perder correos en una migración bien hecha?

Se pueden quedar atrás si estaban solo en un PST, en un móvil o en una regla de reenvío que nadie documentó. El servidor, si se copia o se deja en solo lectura, no “se come” el historial por magia. El riesgo real es el recorte de origen demasiado pronto y el inventario incompleto. Por eso el Monday test incluye a un proveedor externo: para pillar el agujero el día 1, no el día 20.

¿Cuánto tiempo hay que convivir con los dos sistemas?

En un cutover limpio, horas: el DNS se propaga y apagas el hábito del webmail viejo. En staged, semanas o meses, y hay que pagar esa complejidad con normas (quién convoca calendarios, dónde está info@). Si alguien te propone seis meses de coexistencia para quince buzones, está alargando el proyecto. Si te propone un cutover de 200 buzones Exchange el sábado, está acortándolo de forma temeraria.

¿Hace falta cortar el correo un fin de semana entero?

No siempre. Hace falta una ventana en la que los envíos críticos se puedan pausar o vigilar, y un lunes con soporte. Un sábado por la mañana para MX y perfiles, y un domingo de comprobaciones, es un patrón clásico. Un hotel en pleno puente no es ese sábado. Ahí se elige otra fecha o un staged. La fecha la marca el negocio, no el ganas del técnico de “dejarlo hecho”.

¿Qué pasa con los móviles que no soportan MFA?

Se actualizan o se retiran del correo corporativo. Hacer una excepción de “autenticación básica” para un Android de 2016 es reabrir la puerta que Microsoft ha ido cerrando por algo. Un móvil de sustitución un mes, o el webmail, es más barato que un tenant comprometido. Si el aparato es de un directivo que no quiere cambiar, esa es una decisión de riesgo de gerencia, por escrito.

¿Puedo migrar solo el correo y dejar los archivos en el servidor?

Sí, y es el híbrido más habitual. 365 para buzón, calendario y Teams; servidor o NAS para el ERP y el archivo gordo. Es una buena decisión si se explica. Es una mala decisión si se vende como “ya somos 100 % nube”. Di la verdad a la plantilla: el Outlook cambia, la unidad Z de momento no. Evitarás la pregunta del lunes “¿dónde está la carpeta de obras?”.

¿El usuario puede seguir usando Gmail “por encima” de 365?

Puede, y es una mala idea: duplicados, retrasos, datos de clientes en una cuenta personal y un segundo sitio que no controlas cuando hay una baja. Si alguien necesita Gmail por un proyecto concreto, se habla y se acota. Como plan por defecto, no. El objetivo de la migración es un buzón canónico, no tres copias desfasadas.