En un caso de migración de correo empresarial conviene revisar, antes de mover el primer buzón, el alcance, las cuentas y dependencias, el dominio y DNS, la información que realmente puede trasladarse, la ventana de cambio, las pruebas y la atención a usuarios. La decisión importante no es sólo qué plataforma contratar, sino cómo cambiar sin perder control sobre la comunicación que sostiene ventas, administración, proveedores y trabajo interno.

Una migración ordenada empieza con inventario y termina con validación. Entre ambos puntos hay decisiones sobre mensajes históricos, buzones compartidos, alias, calendarios, teléfonos, aplicaciones que envían correo y responsables de autorizar cambios. Si esas dependencias se descubren durante el corte, el equipo termina resolviendo urgencias que podían haberse documentado desde el diagnóstico.

Qué debe quedar claro en el diagnóstico inicial

El diagnóstico convierte una intención general —“cambiar de correo”— en un proyecto con límites verificables. Debe identificar la plataforma de origen, la alternativa de destino, la forma en que cada área usa el servicio y las restricciones técnicas u operativas que pueden cambiar la estrategia.

  • Quién es titular del dominio, dónde se administra DNS y quién puede autorizar modificaciones.
  • Qué usuarios, áreas, ubicaciones y horarios dependen del correo para operar.
  • Cuáles son las cuentas personales, compartidas, técnicas, temporales o sin responsable vigente.
  • Qué información se desea conservar y qué condiciones impone la plataforma de origen.
  • Qué equipos, teléfonos, aplicaciones y servicios deberán actualizar su configuración.
  • Quién decide, quién ejecuta, quién valida y cómo se atenderán incidencias durante la transición.

También conviene definir desde el inicio qué queda fuera. Archivos guardados sólo en una computadora, respaldos antiguos, aplicaciones de terceros o configuraciones particulares pueden requerir una revisión separada. Incluirlos por suposición crea expectativas que la herramienta de migración quizá no pueda cumplir.

Delimita exactamente qué se va a migrar

“Migrar el correo” puede significar cosas distintas. Para una empresa puede bastar con trasladar mensajes y carpetas; para otra también son importantes contactos, calendarios, delegaciones, buzones compartidos, listas, reglas y firmas. El contenido disponible depende del origen, el destino, los permisos y el método que pueda utilizarse.

  • Mensajes, carpetas y elementos históricos dentro del periodo acordado.
  • Contactos y calendarios cuando exista una ruta compatible y se hayan incluido en el alcance.
  • Buzones compartidos, alias, grupos y permisos que deban recrearse o ajustarse.
  • Reglas, respuestas automáticas, reenvíos, firmas y configuraciones que requieran trabajo manual.
  • Archivos locales o buzones exportados que no estén disponibles directamente en el servidor de origen.
  • Aplicaciones conectadas que necesitarán credenciales, permisos o parámetros nuevos.

Si la plataforma destino será Microsoft 365, consulta también el ejemplo de migración a Microsoft 365 para pymes. Ese escenario permite revisar licencias, piloto, cuentas y soporte con un enfoque específico, mientras este artículo mantiene una ruta aplicable a distintos proveedores.

Haz inventario de cuentas y dependencias ocultas

El directorio visible de usuarios no siempre representa todo lo que usa el correo. Cuentas como ventas, facturación, soporte o administración pueden atenderse entre varias personas. Equipos multifuncionales, formularios, sistemas administrativos, sitios web y alertas de infraestructura también pueden enviar mensajes desde el dominio.

  • Usuarios activos y cuentas que ya deberían darse de baja o conservarse únicamente como archivo.
  • Buzones funcionales y compartidos, con responsables y permisos individuales definidos.
  • Alias, grupos, listas de distribución, reenvíos y respuestas automáticas.
  • Aplicaciones, formularios, impresoras y sistemas que envían notificaciones.
  • Dispositivos autorizados y clientes de correo usados en computadora, navegador, teléfono o tableta.
  • Cuentas administrativas, medios de recuperación y contactos de los proveedores involucrados.

Para ordenar cuentas personales, funcionales y compartidas antes del cambio, puede servir la guía de correo empresarial para empresas. El inventario debe mostrar no sólo que una dirección existe, sino para qué se usa y quién responde por ella.

Trata el dominio y DNS como un cambio operativo controlado

El correo depende del dominio y de registros DNS que indican dónde se reciben los mensajes y qué servicios están autorizados para enviarlos. El cambio debe realizarse desde una cuenta corporativa controlada, con valores anteriores documentados, una ventana acordada y una ruta clara para corregir una configuración si la validación falla.

Antes de modificar registros, confirma titularidad, accesos y proveedor con la guía de gestión de dominios para empresas. Dominio, DNS, hosting y correo pueden estar con proveedores distintos; asumir que todo se administra desde el mismo panel puede retrasar el corte.

  • Registrar los valores vigentes y las dependencias conocidas antes de cualquier cambio.
  • Confirmar quién autoriza la ventana y quién tiene acceso real al proveedor de DNS.
  • Preparar los registros requeridos por la plataforma destino sin eliminar dependencias ajenas al correo.
  • Validar recepción, envío y autenticación del dominio después del ajuste.
  • Mantener comunicación con usuarios y proveedores mientras el cambio termina de reflejarse.

No conviene prometer un instante exacto en el que todos los servicios externos verán la nueva configuración. La revisión debe considerar cachés, registros previos, sistemas relacionados y la respuesta de terceros. Por eso el corte necesita seguimiento, no sólo una confirmación visual en el panel de administración.

Decide qué información conservar y cómo comprobarla

La empresa debe definir qué historial necesita mantener disponible, por cuánto tiempo y quién podrá consultarlo. Migrar todo por costumbre puede aumentar complejidad; migrar demasiado poco puede dejar a un área sin conversaciones o evidencias necesarias. La decisión debe responder a la operación y a las políticas internas, no a una regla genérica.

  • Revisar tamaño, antigüedad y estado de los buzones antes de calcular el alcance.
  • Separar información disponible en servidor de archivos que sólo existen en equipos locales.
  • Definir el tratamiento de cuentas inactivas, exempleados y buzones sin propietario.
  • Acordar muestras o conteos que permitan comparar origen y destino.
  • Conservar exportaciones o respaldos adicionales cuando el riesgo y el alcance lo justifiquen.
  • Documentar elementos que no pueden trasladarse automáticamente y requieren recreación manual.

Una sincronización o una copia de buzones no sustituye por sí misma una estrategia de respaldo. El proyecto debe aclarar qué evidencia de origen se conservará, cómo se protegerá y cuándo podrá retirarse el acceso anterior. Cerrar el servicio de origen antes de confirmar la información limita las opciones de corrección.

Planea un piloto y una transición por fases

Un piloto con usuarios representativos permite descubrir diferencias antes de ampliar el cambio. Conviene incluir perfiles que usen calendario, buzones compartidos, dispositivos móviles, archivos históricos o aplicaciones relacionadas. El piloto no garantiza que todos los escenarios serán iguales, pero ayuda a validar el método y ajustar la comunicación.

  • Diagnóstico: inventariar cuentas, información, dominio, dispositivos, aplicaciones y responsables.
  • Diseño: definir plataforma destino, licencias, permisos, alcance, exclusiones y criterios de aceptación.
  • Piloto: probar con perfiles distintos y registrar incidencias que deban resolverse antes del corte.
  • Preparación: crear cuentas, ejecutar copias previas cuando aplique y comunicar instrucciones.
  • Corte: modificar los servicios autorizados dentro de la ventana y confirmar funciones críticas.
  • Estabilización: atender diferencias, completar elementos pendientes y documentar el cierre.

La convivencia temporal entre plataformas debe planearse de forma explícita. Si durante un periodo aún pueden llegar mensajes al origen o existen usuarios trabajando en ambos entornos, el equipo necesita saber dónde consultar, desde dónde responder y cuándo dejará de utilizarse el servicio anterior.

Prepara a los usuarios, sus dispositivos y el canal de soporte

Una migración técnicamente correcta puede percibirse como una falla si los usuarios no saben qué hacer. La comunicación debe explicar qué cambiará, cuándo ocurrirá, qué credenciales utilizar, cómo reconocer el nuevo acceso y dónde reportar una incidencia. No es necesario saturar con detalles técnicos; sí dar instrucciones concretas y verificables.

  • Enviar el calendario y las acciones esperadas antes de la ventana de cambio.
  • Indicar cómo se entregarán credenciales sin usar canales inseguros ni compartir contraseñas.
  • Preparar guías breves para navegador, cliente de correo y dispositivos móviles autorizados.
  • Definir un canal de soporte alterno por si el usuario aún no puede entrar al correo nuevo.
  • Priorizar áreas con atención a clientes, proveedores, pagos o procesos operativos sensibles.
  • Registrar cada incidencia y confirmar con el usuario cuando su función crítica quede validada.

También debe acordarse quién puede solicitar altas, bajas, restablecimientos y cambios de permisos. El periodo de transición no debe convertirse en una excepción general a los controles de acceso.

Valida seguridad y entregabilidad después del cambio

La primera prueba es enviar y recibir, pero no es suficiente. Conviene revisar que el dominio esté configurado conforme a la plataforma, que las cuentas críticas tengan los controles de acceso acordados y que no permanezcan sesiones, reenvíos o permisos innecesarios en el entorno anterior.

Para revisar suplantación, accesos y solicitudes sensibles, consulta la guía de seguridad del correo empresarial contra fraudes. Una migración es una oportunidad para corregir cuentas sin responsable y métodos de recuperación que ya no pertenecen a la empresa.

  • Probar envío y recepción con destinatarios internos y externos autorizados.
  • Confirmar alias, grupos, buzones compartidos, respuestas y aplicaciones relacionadas.
  • Revisar mensajes rechazados, clasificados como no deseados o pendientes de entrega.
  • Validar autenticación, recuperación de cuentas y controles adicionales según el alcance.
  • Retirar accesos anteriores sólo después de comprobar información, operación y autorizaciones.
  • Documentar administradores, propietarios, permisos y ruta de soporte del nuevo entorno.

Si la empresa detecta cuentas de exempleados, permisos acumulados o administradores sin vigencia, conviene auditar los accesos empresariales antes de replicarlos. Migrar permisos sin revisarlos puede trasladar al nuevo servicio los mismos riesgos del anterior.

Cierra con pruebas y evidencia, no sólo con cuentas creadas

El cierre debe demostrar que las funciones acordadas están disponibles para los perfiles relevantes. La evidencia puede incluir resultados de pruebas, incidencias resueltas, elementos pendientes, responsables y decisiones sobre la plataforma anterior. No se trata de producir documentación extensa, sino de dejar una base útil para soporte y futuras altas o bajas.

  • Acceso desde los medios autorizados y restablecimiento controlado de credenciales.
  • Envío, recepción, respuesta y búsqueda de mensajes dentro del alcance migrado.
  • Consulta de carpetas, contactos, calendarios y buzones compartidos incluidos.
  • Operación de alias, grupos, aplicaciones, formularios y notificaciones identificadas.
  • Registro de diferencias aceptadas, elementos pendientes y responsables de completarlos.
  • Confirmación formal antes de cancelar, reducir o cerrar la plataforma de origen.

Durante los primeros días pueden aparecer reglas antiguas, dispositivos secundarios o procesos poco frecuentes que no surgieron en el inventario. Mantener una etapa de estabilización permite atenderlos con orden y distinguir un ajuste normal de un problema que requiere cambiar la estrategia.

Qué puede atenderse a distancia y cuándo puede requerirse una visita

El diagnóstico de cuentas, la preparación de la plataforma, la revisión de DNS, muchas tareas de copia y la validación de envío o recepción suelen poder realizarse a distancia cuando existen conectividad y accesos autorizados. También es posible acompañar a usuarios mediante sesiones remotas y guías breves.

  • Puede requerir visita la configuración de equipos sin acceso remoto, inventario físico o problemas de conectividad local.
  • Puede requerir presencia una ventana crítica cuando la empresa necesita apoyo directo a varios usuarios en la misma ubicación.
  • Puede requerir otro proveedor una limitación del servicio de origen, del registrador, de la plataforma destino o de una aplicación externa.
  • Puede requerir decisión interna la conservación de información, la autorización de accesos o la cancelación del contrato anterior.

La modalidad no debe asumirse por el título del servicio. Se define con base en ubicación, equipos, conectividad, criticidad, número de perfiles, controles de acceso y condiciones contratadas.

Caso práctico común: correo disperso y dependencias no documentadas

Situación ilustrativa: una empresa utiliza cuentas personales, un buzón compartido para ventas y una dirección técnica que envía notificaciones desde un sistema. El dominio lo administra un proveedor distinto al del correo y varios usuarios consultan mensajes desde teléfonos. El ejemplo no representa a un cliente de SOATI ni promete un resultado específico.

Antes del cambio se inventarían las cuentas, propietarios, aplicaciones y dispositivos; se confirmaría el acceso al dominio; se definiría qué historial se trasladará; y se probaría el destino con perfiles representativos. Durante el corte se validarían recepción, envío, buzón compartido y notificaciones del sistema. Después se registrarían diferencias y se mantendría disponible el origen hasta aceptar el cierre.

El valor del caso no está en copiar una secuencia universal, sino en mostrar que el correo forma parte de varios procesos. El plan cambia si existen sucursales, personal remoto, grandes archivos locales, requisitos internos de conservación o aplicaciones que no soportan el mismo método de autenticación.

Señales de alerta antes de iniciar la migración

Si aparece alguna de estas condiciones, conviene detener el corte y resolver primero la falta de control. Continuar puede dejar a la empresa sin una ruta clara para validar o revertir.

  • Nadie puede confirmar quién controla el dominio o el panel DNS.
  • El inventario de cuentas no coincide con las personas y procesos que realmente usan el correo.
  • Se promete migrar todo sin revisar origen, permisos, tamaños, formatos o herramientas disponibles.
  • No existe un piloto, una ventana autorizada ni criterios para declarar el cambio aceptado.
  • Los usuarios no tienen un canal alterno de soporte o recibirán credenciales por medios inseguros.
  • Se planea cancelar el servicio anterior antes de comprobar información y dependencias.
  • No se han identificado aplicaciones, formularios, equipos o proveedores que envían desde el dominio.
  • El alcance no distingue trabajo remoto, visitas, licencias, almacenamiento, respaldos y soporte posterior.

Cómo ayuda SOATI en una migración de correo empresarial

SOATI puede apoyar con el diagnóstico del entorno actual, inventario de cuentas y dependencias, definición de alcance, preparación de la plataforma destino, coordinación de dominio y DNS, migración autorizada, pruebas y soporte de estabilización. Las actividades concretas dependen del proveedor de origen, la plataforma destino, los permisos disponibles, la información y las condiciones contratadas.

El servicio de migración de correo empresarial permite revisar buzones, dominio, usuarios, dispositivos y ventana de cambio para construir una ruta alineada con la operación. SOATI no sustituye las decisiones internas sobre información, autorizaciones, privacidad o conservación; ayuda a convertirlas en un plan técnico y operativo.

Cuando el proyecto requiere elegir plataforma, también puede revisarse el servicio de correo empresarial, las licencias, la forma de colaboración y la capacidad de soporte. La recomendación debe partir del uso real de la empresa, no de asumir que una opción es adecuada para todos.

Siguiente paso: prepara la información para una revisión útil

Antes de solicitar una propuesta, reúne lo que ya conozcas sin enviar contraseñas: proveedor actual, plataforma deseada, dominio, cuentas activas, buzones compartidos, volumen aproximado, dispositivos, aplicaciones relacionadas, ubicaciones y periodo preferido para el cambio. Si algo se desconoce, debe registrarse como parte del diagnóstico, no ocultarse con una estimación improvisada.

  • Define qué problema busca resolver la migración y qué operación no puede quedar sin atención.
  • Identifica a la persona que autorizará cambios y a los usuarios que validarán cada función.
  • Separa requisitos indispensables de mejoras que pueden realizarse después de estabilizar.
  • Solicita que la propuesta detalle alcance, exclusiones, responsabilidades, pruebas y soporte posterior.

Si todavía no se ha elegido destino, revisa correo empresarial Microsoft 365 o Google Workspace como punto de partida para comparar administración, colaboración y soporte. La elección y la migración son decisiones relacionadas, pero requieren preguntas distintas.