Una migración sin interrupción significa que cada mensaje enviado a su dominio llega a un buzón y que cada empleado puede escribir a sus corresponsales el día del cambio. No significa que el historial, los móviles y los hábitos cambien sin ninguna intervención.
Dos plataformas funcionan en paralelo.
El hueco clásico se debe a un MX cambiado mientras una copia está incompleta, o a una fotocopiadora, un sitio web o un CRM que sigue enviando con el identificador antiguo.
El MX es un registro DNS: indica a los servidores remitentes dónde entregar el correo de su dominio. Cambiar de correo electrónico es, ante todo, cambiar esta dirección de entrega. El resto (cuentas, historial, dispositivos) se prepara en torno a ello.
El protocolo SMTP tolera bien las incidencias breves. Un servidor remitente que recibe un error temporal mantiene el mensaje en cola y vuelve a intentarlo más tarde. Un servidor momentáneamente inaccesible no provoca, por tanto, la pérdida de correo. En cambio, un error definitivo (buzón desconocido, mensaje rechazado) devuelve el mensaje a su remitente, y ese mensaje nunca llegará por sí solo. El principal riesgo de un cambio no es la avería, sino que la nueva plataforma rechace a un destinatario porque no se ha vuelto a crear un alias o una lista.
El TTL (tiempo de vida) fija cuánto tiempo puede un resolvedor DNS conservar una respuesta en memoria. Durante ese plazo, una parte de los remitentes sigue entregando a la antigua plataforma. Es normal, y por eso la antigua debe seguir siendo capaz de recibir durante la transición.
Dos semanas antes. Inventario de los buzones, alias, listas, buzones compartidos y de todas las aplicaciones que envían correo. Reducción del TTL DNS del MX a un valor corto (a menudo 300 segundos), para que el día D se propague rápidamente. Creación de las cuentas de destino. Primera copia del historial.
El TTL se reduce pronto porque un resolvedor que ha leído el valor antiguo lo conserva hasta su expiración: el TTL corto solo surte efecto una vez agotada la antigua caché. La primera copia, por su parte, es la más larga; lanzarla pronto deja tiempo para descubrir los buzones que plantean problemas.
Unos días antes. Control de una muestra: número de mensajes, carpetas o etiquetas, citas, contactos. Corrección del método si la muestra falla. Preparación de las guías para móviles y Outlook. Prueba de envío desde el destino hacia Gmail y Outlook.com, con SPF, DKIM y DMARC ya válidos en la nueva plataforma. Estos registros pueden publicarse antes del MX.
En concreto: un único registro SPF que autorice ambas plataformas durante la transición (dos registros SPF distintos hacen fallar la verificación), una clave DKIM de la nueva plataforma publicada bajo su propio selector, junto a la antigua, y una política DMARC revisada. DMARC exige que el mensaje esté autenticado por SPF o por DKIM en nombre del dominio del remitente; si su política es estricta y el destino aún no está autorizado, sus corresponsales rechazan sus mensajes.
La víspera. Segunda pasada: copiar solo lo que ha llegado desde la primera copia. Congelar los cambios de alias y de listas.
El día D. Cambio del MX. Verificación externa inmediata: un correo enviado desde un buzón personal externo debe llegar a la nueva plataforma dentro del plazo del TTL. Supervisión de la cola. Reconfiguración de las aplicaciones de envío. Servicio de asistencia interno identificado, con la facultad de revertir el MX si falla un flujo crítico.
Cambie al mismo tiempo el registro autodiscover, si existe: es el que Outlook consulta para encontrar su servidor. Retire también los MX secundarios que aún designen a la antigua plataforma: un remitente que no consigue contactar con el MX principal prueba los siguientes.
Los días siguientes. La antigua plataforma, en modo lectura. Notificación de las diferencias (una carpeta que falta, un buzón compartido). Tercera pasada específica si es necesario. Después, cierre del envío en la antigua, para que ningún empleado siga respondiendo desde dos lugares.
Este último punto tiene una razón técnica. La antigua plataforma se sigue considerando responsable de su dominio: un mensaje enviado desde ella a un compañero se entrega allí localmente, sin consultar el MX. El compañero nunca lo verá en su nuevo buzón.
| Riesgo | Lo que ocurre | Solución |
|---|---|---|
| MX cambiado demasiado pronto | El correo nuevo llega, falta el historial | Cambiar tras el control de la muestra y la segunda pasada |
| Alias o lista olvidados | El destino rechaza definitivamente esos mensajes | Inventario, congelación de los alias la víspera, prueba de las direcciones colectivas |
| SPF, DKIM o DMARC incompletos | Sus mensajes son rechazados o clasificados como no deseados por los corresponsales | Publicar antes del día D, verificar con un mensaje real |
| Aplicación que envía con la cuenta antigua | Las facturas, alertas o digitalizaciones dejan de salir | Lista de aplicaciones, nuevo servidor SMTP configurado el día D |
| Envío que sigue abierto en la antigua plataforma | Algunos mensajes internos se quedan en el sistema antiguo | Cerrar el envío en cuanto se valide la muestra |
| Marcha atrás no preparada | El MX vuelve atrás, pero los mensajes recibidos entretanto se quedan en el destino | Plan escrito, con la recuperación de esos mensajes |
Tomemos, a modo de ilustración, un despacho de 40 personas. Decide hacer el cambio un jueves al final de la jornada en lugar de un viernes: al día siguiente, el equipo está presente para tratar las diferencias, y el servicio de asistencia interno tiene por delante una jornada laborable. La fotocopiadora de la recepción, que escanea al correo, se reconfigura esa misma tarde. Si dos buzones compartidos notifican una carpeta que falta, una pasada específica los completa. En este escenario no se pierde ningún mensaje, pero varios empleados deben volver a configurar su cuenta en el teléfono: esa es la parte visible que hay que anunciar.
Cambian de servidor en Outlook o en el móvil. La primera carga de un buzón grande lleva tiempo. Los mensajes ya almacenados en la caché del teléfono pueden duplicarse si el perfil no se rehace correctamente. Prevea el procedimiento « eliminar la cuenta y volver a crearla » en lugar de un apaño en la configuración del servidor.
La razón es la misma para Outlook: el perfil conserva una caché local vinculada al antiguo servidor. Un perfil nuevo parte de un estado limpio; un perfil antiguo modificado mezcla los dos mundos. En el móvil, el protocolo utilizado (Exchange ActiveSync o IMAP según el destino) cambia a veces con la plataforma, lo que es una razón más para volver a crear la cuenta.
Las reglas del lado del servidor, las firmas centralizadas y los permisos de delegación se vuelven a configurar. Anúncielo. No es una interrupción del correo. Es trabajo de administración.
Este reenvío requiere una configuración explícita: la antigua plataforma, que cree seguir alojando los buzones, debe configurarse para retransmitir a la nueva en lugar de entregar localmente. En su defecto, una pasada de recuperación específica hace el mismo trabajo.
Las particularidades de cada punto de partida se describen en migrar desde Microsoft 365 y migrar desde Google Workspace.
El tiempo necesario para verificar que ningún flujo utiliza todavía la antigua y que las diferencias notificadas se han tratado. Depende del número de buzones, de las aplicaciones que envían y del ritmo de reconfiguración de los equipos. Cerrar demasiado pronto impide corregir; cerrar demasiado tarde deja a empleados trabajando en dos sistemas.
No, si está preparado. Durante el plazo del TTL, una parte de los remitentes sigue entregando a la antigua plataforma y la otra, a la nueva. Ambas reciben, y la pasada siguiente reúne las dos. El correo solo se pierde si es rechazado, de ahí la importancia de los alias y de las listas.
Por lo general, no: las direcciones no cambian. En cambio, avise a los socios que filtran estrictamente sus mensajes o que le han asignado una regla particular, y a quienes intercambian con usted correo cifrado, si las claves cambian.
Sí, restableciendo el MX antiguo, siempre que la antigua plataforma siga activa. Los mensajes recibidos entretanto por la nueva deben entonces volver a copiarse o seguir siendo consultables. El plan de marcha atrás indica quién decide, en cuánto tiempo y cómo se recuperan esos mensajes.
Pregunte al operador qué garantiza: la llegada de los mensajes, la recuperación del historial o ambas cosas. Son compromisos diferentes. Pida también el plan de marcha atrás, por escrito, con la persona que tiene la facultad de activarlo.
Una garantía sobre la llegada de los mensajes se refiere al día D y a los días siguientes. Una garantía sobre el historial se refiere a la copia y a su control. Un proveedor puede cumplir una sin la otra; el presupuesto debe indicar cuál asume y cómo se verifica.
En Klytic, el asesoramiento y las sugerencias para preparar la migración del correo electrónico son gratuitos, y no se pierde ningún correo. La migración realizada por Klytic se presupuesta. Las suscripciones figuran en la página Tarifas y se facturan aparte. El detalle de las partidas de coste figura en cuánto cuesta una migración de Microsoft 365, y la lista de control, en la checklist. Para comparar los destinos, véase elegir un correo electrónico europeo.
Esta página describe un método. El desarrollo real depende de sus flujos, de sus volúmenes y de la plataforma que abandona.
Consultadas en octubre de 2026.
Asesoramiento gratuito, ningún correo perdido. La migración realizada por Klytic se presupuesta tras un inventario.
Oferta de bienvenida
Oferta de prueba sin compromiso. Un asesor le llamará para conocer sus necesidades y preparar su espacio Klytic.
