Rendimiento y procedimientos recomendados de migración de correo electrónico de Microsoft 365 y Office 365
Hay muchas rutas de acceso para migrar datos de correo electrónico de una organización hospedada localmente a Microsoft 365 u Office 365. Al planear una migración a Microsoft 365 u Office 365, una comprensión clara del proceso de migración de datos y la velocidad ayuda a los administradores a planear mejor.
Introducción a la migración de correo electrónico a Microsoft 365 u Office 365
Microsoft 365 u Office 365 admiten varios métodos para migrar correo electrónico, calendario y datos de contacto de su entorno de mensajería existente a Microsoft 365 u Office 365, como se describe en Formas de migrar varias cuentas de correo electrónico a Microsoft 365 u Office 365.
Para obtener preguntas relacionadas con las redes y el rendimiento en Microsoft 365 u Office 365, consulte Planeamiento de red y optimización del rendimiento para Microsoft 365 u Office 365.
Métodos de migración más usados
Método de migración | Description | Recursos |
---|---|---|
Migración de Protocolo de acceso a mensajes de Internet (IMAP) | Puede usar el Centro de administración de Exchange o PowerShell de Exchange Online para migrar el contenido de los buzones de los usuarios de un sistema de mensajería IMAP a sus buzones de Microsoft 365 u Office 365. Esto incluye la migración de los buzones de otros servicios de correo electrónico hospedado, como Gmail o Correo Yahoo. Tenga en cuenta que Exchange Online ahora ofrece un proceso altamente especializado en EAC moderno para migrar correos electrónicos de una implementación existente de Gmail/G Suite/Google WorkSpace (GWS) de una organización a Exchange Online. | Migración de los buzones IMAP a Microsoft 365 u Office 365 |
Migración total | Use la migración total para migrar todos los buzones locales a Microsoft 365 u Office 365 durante unos días. Use la migración total si planea mover toda la organización de correo electrónico a Microsoft 365 u Office 365 y administrar cuentas de usuario en Microsoft 365 u Office 365. Puede migrar un máximo de 2000 buzones de correo de la organización local de Exchange a Microsoft 365 u Office 365 mediante una migración total. Sin embargo, el número recomendado de buzones es 150. Es probable que el rendimiento se degrade con números mayores que eso. Los contactos de correo y los grupos de distribución de la organización local de Exchange también se migrarán. | Migración total a Microsoft 365 u Office 365 |
Migración preconfigurada | Use la migración por fases si planea migrar eventualmente todos los buzones de correo de la organización a Microsoft 365 u Office 365, con el tiempo. Con una migración preconfigurada, se migran lotes de buzones locales a Microsoft 365 u Office 365 en el transcurso de unas semanas o meses. | Lo que necesita saber sobre una migración de correo electrónico preconfigurada a Microsoft 365 u Office 365 |
Implementación híbrida | La implementación híbrida ofrece a las organizaciones la capacidad de ampliar la experiencia enriquecida en características y el control administrativo que tienen con su organización de Exchange local existente a la nube. Una implementación híbrida proporciona la apariencia perfecta de una sola organización de Exchange entre una organización de Exchange local y Exchange Online en Microsoft 365 u Office 365. Además, una implementación híbrida puede servir como paso intermedio para moverse completamente a una organización de Microsoft 365 u Office 365. |
Asesor de migración de Correo de Microsoft 365 y Office 365 Implementaciones híbridas de Exchange Server Asesor de migración de correo Asistente de implementación de Exchange para Exchange local 2013/2016/2019 Implementaciones híbridas de Exchange Server 2013 Configuración híbrida mínima |
Migración de terceros | Hay disponible un gran número de herramientas de terceros. Usan protocolos y enfoques distintivos para realizar migraciones de correo electrónico desde plataformas de correo electrónico como GWS, GoDaddy, Yahoo, IBM Lotus Notes y Novell GroupWise. | A continuación se indican algunas herramientas de migración de terceros y asociados que pueden ayudarle con las migraciones de Exchange desde plataformas de terceros: Árbol / binarioBúsqueda / QuadroTech: Binary Tree y QuadroTech ahora forman parte de Quest. Quest es un proveedor de software de migración y coexistencia de mensajería multiplataforma, con productos para el análisis, la coexistencia y la migración entre varias plataformas a Exchange Online. Las soluciones de Quest sincronizan buzones de correo, carpetas públicas e información de calendario mientras mantienen la coexistencia durante toda la migración. BitTitan: proporciona una solución automatizada para migraciones a Microsoft 365 u Office 365 desde una amplia gama de plataformas. CodeTwo: proveedor de soluciones de migración de Microsoft 365 y Office 365 para migraciones de datos seguras y automatizadas a Microsoft 365 (Office 365) desde Exchange local, servidores IMAP y entre inquilinos de Microsoft 365. Transvault: proveedor de soluciones de migración de Office en la nube a Microsoft 365 desde Exchange y Notas. Transvault admite docenas de orígenes para la migración y ofrece productos que ofrecen cualquier tamaño de proyecto, migraciones complejas de archivos de correo electrónico y administración de PST. Las soluciones de migración empresarial son seguras, compatibles, eficaces y centradas en el usuario, y se pueden ejecutar tanto en el entorno local como en la nube. SkyKick: proveedor de soluciones de migración automatizadas para pasar de varios tipos de origen a Microsoft 365 u Office 365. Las herramientas de migración de un extremo a otro ayudan a los partners a completar las fases del proyecto de migración, como ventas, planeamiento, migración, administración y configuración local. BCC: Ayuda a las empresas apoyando su estrategia de migración de colaboración. El mejor proveedor de herramientas de migración basadas en la plataforma Domino para migrar a Microsoft Exchange, Microsoft 365 y Office 365. |
Rendimiento de los métodos de migración
En las secciones siguientes se comparan las cargas de trabajo de migración de buzones de correo y los resultados de rendimiento observados para los distintos métodos de migración para migrar buzones de correo y datos de buzón a Microsoft 365 u Office 365. Estos resultados se basan en pruebas internas y migraciones reales de clientes a Microsoft 365 u Office 365.
Importante
Debido a las diferencias en cómo se realizan las migraciones y cuándo se realizan, la velocidad de migración real puede variar.
Cargas de trabajo de migración de clientes
En la tabla siguiente se describen las distintas cargas de trabajo implicadas en una migración típica y los desafíos y opciones de cada una.
Carga de trabajo | Notas |
---|---|
Incorporación (migración a Microsoft 365 u Office 365) | Microsoft ofrece funcionalidades y herramientas de migración de datos para que los clientes puedan usar para migrar sus datos desde Exchange Server local (a través de Cutover/Staged/Hybrid) o desde Gmail/S Suite/GWS también conocido como Google Work Space (a través de EAC, PowerShell) o desde otros orígenes IMAP (PowerShell, Gmail a través de IMAP) o migraciones entre inquilinos a Exchange Online en Microsoft 365 u Office 365. |
Multi-Geo | Las empresas multinacionales con oficinas de todo el mundo a menudo tienen la necesidad de almacenar los datos de sus empleados en reposo en regiones específicas, con el fin de satisfacer sus requisitos de residencia de datos. Multi-Geo permite que una sola organización de Microsoft 365 u Office 365 abarque varias zonas geográficas de centros de datos de Microsoft 365 u Office 365, lo que le ofrece la capacidad de almacenar datos de Exchange, en reposo, por usuario, en las zonas geográficas elegidas. Para obtener más información, consulte Obtención de controles de ubicación de datos globales de nivel empresarial con multigeográfica. |
Cifrado | Cifrado de servicio con clave de cliente es una característica que permite a un cliente aprovisionar y administrar las claves raíz que se usan para cifrar los datos en reposo en el nivel de aplicación en Microsoft 365 u Office 365. Para que un buzón se cifre la primera vez, se requiere un movimiento de buzón. Para obtener más información, consulte Cifrado de servicio con la clave de cliente de Microsoft Purview. |
GoLocal | Microsoft sigue abriendo nuevos centros de datos en nuevas regiones o geoáreas. Los clientes existentes, cuando son aptos, pueden solicitar que los datos de sus clientes de su centro de datos original se muevan a una nueva ubicación geográfica. El período en el que puede realizar esta solicitud suele ser de uno o dos años, en función de la demanda general del servicio. Tenga en cuenta que este período durante el cual puede solicitar que se muevan los datos del cliente será más corto una vez que se inicie un centro de datos (DC) para los nuevos lanzamientos geográficos (en ese momento tiene aproximadamente entre tres y seis meses para solicitar un traslado). Los detalles están disponibles en Traslado de datos principales a nuevas zonas geográficas del centro de datos de Microsoft 365. |
Cuando los buzones se migran dentro de los centros de datos de Microsoft 365, cada movimiento de buzón o movimiento de buzón masivo requiere tiempo para que se complete la operación. Hay una serie de factores, como la actividad del servicio de Microsoft 365, que pueden afectar exactamente a la cantidad de tiempo. El servicio está diseñado para limitar las cargas de trabajo discrecionales, como los movimientos de buzón de correo, para garantizar que el servicio se ejecuta de forma óptima para todos los usuarios. Sin embargo, puede esperar que se procesen los movimientos de buzón, en función de la disponibilidad de recursos discrecionales del servicio. Puede encontrar más detalles sobre la limitación de recursos en esta entrada de blog.
Estimaciones de duración para la migración de buzones en Exchange Online
Para ayudarle a planear la migración, en las tablas siguientes se presentan instrucciones sobre cuándo esperar que se completen migraciones masivas de buzones o migraciones individuales. Estas estimaciones se basan en un análisis de datos de migraciones de clientes anteriores. Dado que cada entorno es único, la velocidad de migración exacta puede variar.
Duración de la migración del buzón en función de los perfiles de tamaño de buzón:
GoLocal/Multigeográfica/Cifrado en Exchange Online
Carga de trabajo Tamaño del buzón (GB) P50 (duración del percentil 50) (días) P90 (duración del percentil 90) (días) GoLocal/Multi-Geo/Encryption 0 - 10 1 1 GoLocal/Multi-Geo/Encryption 10 - 50 2 6 GoLocal/Multi-Geo/Encryption 50 - 100 4 11 GoLocal/Multi-Geo/Encryption 100 - 200 6 14 GoLocal/Multi-Geo/Encryption > 200 No se admite No compatible Incorporación a Exchange Online desde servidores exchange locales (híbridopreconfigurado por/transición/)
Carga de trabajo Tamaño del buzón (GB) P50 (duración del percentil 50) (días) P90 (duración del percentil 90) (días) Incorporación desde el entorno local 0 - 10 1 3 Incorporación desde el entorno local 10 - 50 2 6 Incorporación desde el entorno local 50 - 100 4 13 Incorporación desde el entorno local 100 - 200 10 31 Incorporación desde el entorno local > 200 No compatible No compatible Migración entre inquilinos a Exchange Online (use la solución de microsoft de terceros o use soluciones de terceros).
Carga de trabajo Tamaño del buzón (GB) P50 (duración del percentil 50) (días) P90 (duración del percentil 90) (días) Entre inquilinos 0 - 10 1 1 Entre inquilinos 10 - 50 1 2 Entre inquilinos 50 - 100 2 5 Entre inquilinos 100 - 200 3 6 Entre inquilinos > 200 No compatible No se admite Incorporación especializada a Exchange Online desde Gmail/G Suite/GWS (EAC, PowerShell)
Carga de trabajo Tamaño del buzón (GB) P50 (duración del percentil 50) (días) P90 (duración del percentil 90) (días) Incorporación especializada de Gmail 0 - 10 1 2 Incorporación especializada de Gmail 10 - 50 1 8 Incorporación especializada de Gmail 50 - 100 3 12 Incorporación especializada de Gmail 100 - 200 5 19 Incorporación especializada de Gmail > 200 No compatible No se admite Incorporación a Exchange Online desde orígenes IMAP (otros orígenes IMAP, PowerShell, Gmail a través de IMAP)
Carga de trabajo Tamaño del buzón (GB) P50 (duración del percentil 50) (días) P90 (duración del percentil 90) (días) Incorporación genérica de IMAP 0 - 10 1 1 Incorporación genérica de IMAP 10 - 50 1 2 Incorporación genérica de IMAP 50 - 100 1 8 Incorporación genérica de IMAP 100 - 200 3 29 Incorporación genérica de IMAP > 200 No se admite No compatible Incorporación a Exchange Online a través de la importación de PST
Carga de trabajo Tamaño del buzón (GB) P50 (duración del percentil 50) (días) P90 (duración del percentil 90) (días) Importación de PST 0 - 10 1 1 Importación de PST 10 - 50 1 3 Importación de PST 50 - 100 2 5 Importación de PST 100 - 200 3 6 Importación de PST > 200 No se admite No se admite
Nota:
Algunos buzones atípicos tardarían más en completarse en función del perfil de buzón. Además, si un inquilino tiene buzones más grandes en promedio, esto también puede contribuir a la duración extendida de la migración.
Factores de rendimiento de la migración
La migración de buzón o correo electrónico tiene varios factores comunes que afectan al rendimiento de la migración.
Factores de rendimiento de migración comunes
La tabla siguiente contiene una lista de factores comunes que afectan al rendimiento de la migración. Encontrará más información en las secciones donde se describen los métodos de migración individuales.
Factor | Description | Ejemplo |
---|---|---|
Origen de datos | El dispositivo o servicio que hospeda los datos que se migrarán. Puede aplicarse un gran número de limitaciones en el origen de datos debido a las especificaciones del hardware, la carga de trabajo del usuario final y las tareas de mantenimiento back-end. | Gmail limita la cantidad de datos que se pueden extraer durante un período de tiempo específico. |
Tipo de datos y densidad | Debido a la naturaleza única del negocio de un cliente, el tipo y la combinación de elementos de correo en los buzones varía en gran medida. | Un buzón de 4 GB con 400 elementos, cada uno con 10 megabytes (MB) de datos adjuntos, se migrará más rápido que un buzón de 4 GB con 100 000 elementos de menor tamaño. |
Servidor de migración | Muchas soluciones de migración usan un tipo específico de servidor de migración o estación de trabajo para completar la migración. | Los clientes suelen usar una máquina virtual de bajo rendimiento para hospedar el servicio MRSProxy para implementaciones híbridas o para migraciones no híbridas de equipos cliente. |
Motor de migración | El motor de migración de datos responsable de extraer datos del servidor de origen convierte los datos, si es necesario. A continuación, el motor transmite los datos a través de la red e inserta los datos en el buzón de Microsoft 365 u Office 365. Buzón. | El servicio MRSProxy tiene sus propias funciones y limitaciones. |
Dispositivos de red locales | El rendimiento de red de un extremo a otro (del origen de datos a los servidores de acceso de cliente de Exchange Online) afecta al rendimiento de la migración. | La configuración del firewall y las especificaciones en la organización local. |
Servicio de Microsoft 365 u Office 365 | Microsoft 365 y Office 365 tienen compatibilidad integrada y características para administrar la carga de trabajo de migración. | La directiva de limitación de usuarios tiene una configuración predeterminada y limita el máximo de velocidad de transferencia de datos general. |
Factores de rendimiento de la red
En esta sección, se describen los procedimientos recomendados para mejorar el rendimiento de la red durante la migración. La discusión es general, ya que el mayor impacto en el rendimiento de la red durante la migración está relacionado con hardware de terceros y con proveedores de acceso a Internet (ISP).
Use Exchange Analyzer para comprender mejor la conectividad de red con Microsoft 365 u Office 365. Para ejecutar las pruebas de Exchange Analyzer en el Asistente para soporte técnico y recuperación de Microsoft, vaya a Diagnósticos > avanzados Exchange Online > Compruebe la conectividad > de red de Exchange Online Sí. Obtenga información sobre el Asistente para recuperación y soporte técnico de Microsoft para obtener más información sobre el Asistente para recuperación y soporte técnico de Microsoft.
Factor | Description | Procedimientos recomendados |
---|---|---|
Capacidad de la red | La cantidad de tiempo que se tarda en migrar buzones a Microsoft 365 u Office 365 viene determinada por la capacidad disponible y máxima de la red. | Identifique la capacidad de la red disponible y determine la capacidad máxima de carga. Póngase en contacto con su ISP para confirmar el ancho de banda asignado y para obtener información sobre las restricciones, como la cantidad total de datos que se pueden transferir en un período de tiempo específico. Use herramientas para evaluar su capacidad real de la red. Asegúrese de probar el flujo de datos de un extremo a otro desde el origen de datos local hasta los servidores de puerta de enlace del centro de datos de Microsoft. Identifique otras cargas en la red (como utilidades de copia de seguridad y tareas de mantenimiento programadas) que puedan afectar a la capacidad de la red. |
Estabilidad de la red | Una red rápida no siempre produce migraciones rápidas. Si la red no es estable, la transferencia de datos tarda más tiempo en completarse debido a la corrección de errores. Según el tipo de migración, la corrección de errores puede afectar significativamente al rendimiento de la migración. | Los problemas de controladores y hardware de la red suelen causar problemas de estabilidad en la red. Colabore con los proveedores de hardware para conocer en detalle sus dispositivos de red y aplicar las actualizaciones de software y los controladores recomendados más recientes del proveedor. |
Retrasos en la red | La función de detección de intrusión configurada en un firewall de red suele causar retrasos importantes en la red y afecta al rendimiento de la migración. La migración de datos a buzones de Microsoft 365 u Office 365 se basa en la conexión a Internet. Los retrasos en la conexión a Internet afectan al rendimiento general de la migración. Además, puede que los usuarios de la misma compañía tengan buzones en la nube que residan en centros de datos de diferentes ubicaciones geográficas. Según el ISP del cliente, el rendimiento de la migración puede variar. |
Evalúe los retrasos de red en todos los centros de datos de Microsoft potenciales para ayudar a garantizar que el resultado sea coherente. (Esto también ayuda a garantizar una experiencia coherente para los usuarios finales). Trabaje con su ISP para solucionar problemas relacionados con Internet. Agregue direcciones IP para los servidores del centro de datos de Microsoft a la lista de permitidos o omita todo el tráfico relacionado con la migración desde el firewall de red. Para obtener más información sobre los intervalos IP de Microsoft 365 u Office 365, vea Direcciones URL y intervalos de direcciones IP de Microsoft 365 y Office 365. |
Para obtener un análisis más profundo de las migraciones dentro de su entorno, consulte nuestro análisis de rendimiento de migración de buzones. En la entrada se incluye un script para ayudarle a analizar las solicitudes de movimiento.
Limitación de Microsoft 365 y Office 365
Microsoft 365 y Office 365 usan varios mecanismos de limitación para ayudar a garantizar la seguridad y la disponibilidad del servicio. Estos tres tipos de limitación pueden afectar al rendimiento de la migración:
- Limitación de peticiones de usuarios
- Limitación del servicio de migración
- Limitación basada en el mantenimiento de recursos
Nota:
Los tres tipos de limitación de Microsoft 365 y Office 365 no afectan a todos los métodos de migración.
Limitación de usuarios de Microsoft 365 y Office 365
La limitación de usuarios afecta a la mayoría de las herramientas de migración de terceros y al método de migración de subida con cliente. Estos métodos de migración usan protocolos de acceso de cliente, como la llamada a procedimiento remoto (RPC) a través del protocolo HTTP, para migrar datos de buzón a buzones de Microsoft 365 u Office 365. Estas herramientas se usan para migrar datos desde plataformas como IBM Lotus Domino y Novell GroupWise.
La limitación de usuarios es el método de limitación más restrictivo en Microsoft 365 y Office 365. Como la limitación de usuarios se configura para que funcione con un usuario final individual, cualquier uso de nivel de aplicación superará fácilmente la directiva de limitación y causará una migración de datos más lenta.
Limitación del servicio de migración de Microsoft 365 y Office 365
La limitación del servicio de migración afecta a todas las herramientas de migración de Microsoft 365 u Office 365. La limitación del servicio de migración administra la simultaneidad de la migración y la asignación de recursos de servicio para las soluciones de migración de Microsoft 365 u Office 365.
La limitación del servicio de migración afecta a las migraciones realizadas con los siguientes métodos de migración:
- Migración de IMAP
- Migración total de Exchange
- Migración preconfigurada de Exchange
- Migraciones híbridas (transferencias basadas en el servicio MRSProxy en un entorno híbrido)
Importante
Los métodos de migración mencionados anteriormente no se ven afectados por la limitación de usuarios.
Un ejemplo de limitación del servicio de migración es controlar el número de buzones que se pueden migrar de forma simultánea durante migraciones de Exchange sencillas y migraciones de IMAP. El valor predeterminado es 20. Esto significa que se migran un máximo de 20 buzones de todos los lotes de migración en cualquier momento. Puede aumentar el número de migraciones simultáneas de buzones de correo para un lote de migración en el Centro de administración de Exchange o Windows PowerShell. Para obtener más información sobre cómo optimizar esta configuración, consulte Administración de lotes de migración en Microsoft 365 u Office 365.
Limitación basada en el estado de los recursos de Microsoft 365 u Office 365
Todos los métodos de migración están sujetos al gobierno de la limitación de disponibilidad. Sin embargo, la limitación de servicios de Microsoft 365 u Office 365 no afecta a las migraciones de Microsoft 365 u Office 365 tanto como a los otros tipos de limitación descritos anteriormente.
La limitación basada en el mantenimiento de recursos es el método de limitación menos agresivo. Se produce para evitar que haya un problema de disponibilidad del servicio que pueda afectar a los usuarios finales y a las operaciones críticas del servicio.
Antes de que el rendimiento del servicio se degrade hasta el punto en que también se degrade el rendimiento de los usuarios finales, las migraciones híbridas se pondrán en cola hasta que se recupere el rendimiento y el servicio vuelva a un nivel por debajo del umbral de limitación.
A continuación se muestra lo que verán los clientes con respecto a las duraciones de los bloqueos mediante el Get-MoveRequestStatistics - <> -IncludeReport
cmdlet :
$R.REPORT.TARGETTHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 00:02:07.6222549
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:38:41.7018480
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:26:34.6588104
DISKLATENCYTHROTTLE : 1.15:45:37.7873632
$R.REPORT.SOURCETHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 3.03:21:07.7192848
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:00:00
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:00:00
DISKLATENCYTHROTTLE : 00:20:47.1101552
MDBMAINTENANCETHROTTLE : 00:00:00
Solución y práctica:
Si experimenta una situación comparable, espere a que los recursos de Microsoft 365 u Office 365 estén disponibles.
Factores de rendimiento y procedimientos recomendados para migraciones de implementaciones no híbridas
En esta sección se describen los factores que afectan a las migraciones con los métodos de migración total, preconfigurada o IMAP. También identifica procedimientos recomendados para mejorar el rendimiento de la migración.
Factor 1: Origen de datos para migraciones de implementación no híbridas
En la siguiente tabla, se describe el impacto que tienen en la migración los servidores de origen de una organización de correo electrónico y los procedimientos recomendados para mitigar el impacto en la migración.
Lista de comprobación | Description | Procedimientos recomendados |
---|---|---|
Rendimiento del sistema | La extracción de datos es una tarea intensiva. El sistema de origen necesita tener recursos suficientes (como tiempo de CPU y memoria) para ofrecer un rendimiento de la migración óptimo. Durante la migración, el sistema de origen suele estar próximo a alcanzar su capacidad completa en términos de la carga de trabajo normal del usuario final. Si los recursos del sistema son inadecuados, la carga de trabajo adicional derivada de la migración puede afectar a los usuarios finales. | Supervise el rendimiento del sistema durante una prueba piloto de migración. Si el sistema está ocupado, le recomendamos que evite una programación de migración agresiva para el sistema específico debido a los posibles problemas de lentitud de la migración y de disponibilidad del servicio. Si es posible, agregue recursos de hardware para mejorar el rendimiento del sistema de origen y mueva las tareas y los usuarios a otros servidores que no estén relacionados con la migración para reducir la carga del sistema. Para obtener más información, vea: Estado del servidor y rendimiento de Exchange Server (2007, 2010, 2013, 2016, 2019) Nota: Los servidores de Exchange 2007 y 2010 ya no se admiten activamente. El fin del soporte técnico de Exchange 2013 Server está programado para abril de 2023. Exchange Server 2016 y 2019 están en soporte extendido hasta octubre de 2025. Consulte la matriz de compatibilidad de Exchange Server para obtener más detalles. Al realizar una migración desde una organización local de Exchange con varios servidores de buzones, le recomendamos que cree la lista de usuarios que se migrarán y que la distribuya de manera uniforme en varios servidores de buzones. Basándose en el rendimiento de cada servidor, la lista puede optimizarse aún más para maximizar la capacidad de proceso. Por ejemplo, si el servidor A tiene un 50% más de disponibilidad de recursos que el servidor B, es comprensible que haya un 50% más de usuarios del servidor A en el mismo lote de migración. Se pueden aplicar procedimientos similares en otros sistemas de origen. Ejecute las migraciones cuando los servidores tengan el máximo de disponibilidad de recursos (por ejemplo, fuera del horario laboral o en fines de semana y días festivos). |
Tareas de back-end | Otras tareas de back-end que se ejecutan durante el proceso de migración. Dado que es un procedimiento recomendado realizar la migración después del horario laboral, es habitual que las migraciones entren en conflicto con las tareas de mantenimiento (como la copia de seguridad de datos) que se ejecutan en los servidores locales. | Revise las otras tareas del sistema que pueden estar ejecutándose durante la migración. Recomendamos que las migraciones se lleven a cabo cuando no se estén ejecutando otras tareas de uso intensivo de recursos. Nota: Para los clientes que usan Exchange local, las tareas de back-end comunes son las soluciones de copia de seguridad y el mantenimiento del almacén de Exchange (2013, 2016, 2019). |
Directiva de limitación | Es una práctica común proteger los sistemas de correo electrónico con una directiva de limitación que establece un límite específico sobre la rapidez y la cantidad de datos que se pueden extraer del sistema durante un determinado período de tiempo. | Compruebe la directiva de limitación implementada para el sistema de correo electrónico. Por ejemplo, Google Mail limita la cantidad de datos que se pueden extraer en un período determinado. Según la versión, Exchange tiene directivas que restringen el acceso de IMAP al servidor de correo local (usado por las migraciones de IMAP) y el acceso al protocolo RPC sobre HTTP (usado por las migraciones totales de Exchange y las migraciones preconfiguradas de Exchange). Para comprobar la configuración de limitación, ejecute el cmdlet Get-ThrottlingPolicy . Para obtener más información sobre la limitación, vea: (2007, 2010, 2013, 2016, 2019). Para obtener más información sobre la limitación de IMAP, consulte Migración de los buzones IMAP a Microsoft 365 u Office 365. |
Factor 2: Servidor de migración para migraciones de implementación no híbridas
Las migraciones totales, preconfiguradas y de IMAP son métodos de migración de extracción de datos iniciados en la nube, por lo que no es necesario usar un servidor de migración dedicado. Los hosts de protocolo accesibles desde Internet (IMAP o RPC a través del protocolo HTTP), sin embargo, funcionan como el servidor de migración para migrar buzones de correo y datos de buzón a Microsoft 365 u Office 365. Por lo tanto, los factores de rendimiento y los procedimientos recomendados de migración, descritos en la sección anterior sobre el servidor de origen de datos de la organización de correo electrónico actual, también se aplican a los servidores perimetrales de Internet. Para organizaciones de Exchange 2007, Exchange 2010 y Exchange 2013, el servidor de acceso de cliente funciona como un servidor de migración.
Para más información, vea:
Exchange Server 2007: Supervisión de servidores de acceso de cliente
Exchange Server 2010: contadores de servidor de acceso de cliente
Exchange Server 2013: administración de cargas de trabajo de Exchange
Exchange Server 2016: administración de cargas de trabajo de usuario en Exchange Server
Exchange Server 2019: Administración de cargas de trabajo de usuario en Exchange Server
Factor 3: Motor de migración para migraciones de implementación no híbridas
Las migraciones de Exchange IMAP, cutover y staged se realizan mediante el panel Migración en el Centro de administración de Exchange. Esto está sujeto a la limitación del servicio de migración de Microsoft 365 u Office 365.
Solución y práctica:
Ahora, los clientes pueden especificar la simultaneidad de migraciones (por ejemplo, el número de buzones que se migraron de forma simultánea) con Windows PowerShell. El valor predeterminado es de 20 buzones. Después de crear un lote de migración, puede usar el siguiente cmdlet de Windows PowerShell para aumentar este valor a un máximo de 100.
Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>
Para obtener más información, vea Administrar lotes de migración en Microsoft 365 u Office 365.
Nota:
Si el origen de datos no tiene recursos suficientes para administrar todas las conexiones, se recomienda evitar la simultaneidad alta. Empiece con un valor de simultaneidad reducido, como 10. Aumente este número a medida que vaya supervisando el rendimiento del origen de datos para evitarles problemas de acceso a los usuarios finales.
Factor 4: Red para migraciones de implementación no híbridas
Pruebas de comprobación:
Según el método de migración que use, puede intentar las siguientes pruebas de comprobación:
Migraciones IMAP: rellena previamente un buzón de origen con datos de ejemplo. A continuación, desde Internet (fuera de la red local), conéctese al buzón de origen mediante un cliente de correo electrónico IMAP estándar como Microsoft Outlook y, a continuación, mida el rendimiento de la red determinando cuánto tiempo se tarda en descargar todos los datos del buzón de origen. El rendimiento debe ser similar a lo que los clientes pueden obtener mediante la herramienta de migración IMAP en Microsoft 365 u Office 365, dado que no hay otras restricciones.
Migración de Exchange recortada y almacenada provisionalmente: rellena previamente un buzón de origen con datos de ejemplo. A continuación, desde Internet (fuera de la red local), conéctese al buzón de origen con Outlook mediante RPC a través del protocolo HTTP. Asegúrese de que se conecta mediante el modo almacenado en caché. Compruebe el tiempo necesario para sincronizar todos los datos desde el buzón de origen para medir el rendimiento de la red. El rendimiento debe ser similar a lo que los clientes pueden obtener mediante las sencillas herramientas de migración de Exchange en Microsoft 365 u Office 365, dado que no hay otras restricciones.
Se produce una cierta sobrecarga durante una migración de IMAP total, preconfigurada o de Exchange. Pero el rendimiento real será similar a los resultados de estas pruebas de comprobación.
Factor 5: Servicio de Microsoft 365 y Office 365 para migraciones de implementación no híbridas
La limitación basada en el estado de los recursos de Microsoft 365 u Office 365 afecta a las migraciones mediante las herramientas de migración nativas de Microsoft 365 u Office 365. Consulte la sección Limitación basada en el estado de los recursos de Microsoft 365 u Office 365 .
Mover solicitudes en Microsoft 365 u Office 365
Para obtener información general sobre cómo obtener información de estado para las solicitudes de movimiento, vea Ver propiedades de solicitud de movimiento:
[Get-MoveRequestStatistics]] (/powershell/module/exchange/get-moverequeststatistics)
En el servicio Microsoft 365 u Office 365, la cola de migración y los recursos de servicio asignados para las migraciones se comparten entre los inquilinos y afectan a cómo se administran las solicitudes de movimiento en cada fase del proceso de traslado.
Hay dos tipos de solicitudes de movimiento en Microsoft 365 y Office 365:
Incorporación de solicitudes de "traslado": las nuevas migraciones de clientes se consideran solicitudes de traslado de incorporación. Estas solicitudes tienen una prioridad normal.
Solicitudes de "traslado" internas del centro de datos: son solicitudes de movimiento de buzón iniciadas por los equipos de operaciones del centro de datos. Estas solicitudes tienen una prioridad inferior, ya que la experiencia del usuario final no se ve afectada si se retrasa la solicitud de movimiento.
Posible impacto y retrasos en las solicitudes de movimiento con los estados “en cola” y “en curso”
Solicitudes de movimiento en cola: este estado especifica que el movimiento se ha puesto en cola y está esperando a que el servicio de replicación de buzones de Exchange lo recoga. Para solicitudes de movimiento de Exchange 2003, los usuarios seguirán teniendo acceso a sus buzones en esta fase.
Hay dos factores que afectan a las solicitudes que ejecutará el servicio de replicación de buzones:
Prioridad: las solicitudes de movimiento en cola con una prioridad más alta se seleccionan antes de las solicitudes de movimiento de prioridad inferior. Esto permite garantizar que las solicitudes de movimiento de migración de cliente siempre se procesen antes que las solicitudes de movimiento internas del centro de datos.
Posición en la cola: si las solicitudes de movimiento tienen la misma prioridad, el servicio de replicación de buzones la recogerá cuanto antes la solicitud entre en la cola. Como puede haber varios clientes que realicen migraciones de buzones de forma simultánea, es normal que las nuevas solicitudes de movimiento permanezcan en la cola antes de su procesamiento.
Con frecuencia, el tiempo que las solicitudes de buzones esperan en la cola antes de su procesamiento no se tiene en cuenta durante la planeación de la migración. Como resultado, los clientes no asignan tiempo suficiente para completar todas las migraciones planeadas.
- Solicitudes de movimiento en curso: este estado especifica que el movimiento sigue en curso. Si es un movimiento de buzón en línea, el usuario seguirá teniendo acceso al buzón.
Cuando la solicitud de movimiento de buzón tenga el estado "En curso", la prioridad ya no será importante y no se procesará una nueva solicitud de movimiento hasta que se complete la solicitud de movimiento "En curso" existente, incluso si la nueva solicitud de movimiento tiene una mayor prioridad.
Procedimientos recomendados
Planeamiento: como se mencionó anteriormente, dado que los usuarios de Exchange 2003 pierden acceso durante una migración híbrida, los clientes de Exchange 2003 suelen estar más preocupados por cuándo programar migraciones y cuánto tiempo tardarán.
Al planear el número de buzones que se migrarán durante un período de tiempo específico, tenga en cuenta lo siguiente:
Incluya la cantidad de tiempo que la solicitud de movimiento esperará en la cola. Use lo siguiente para calcularla:
(número total de buzones que se van a migrar) = ((tiempo total) - (tiempo medio de cola)) * (rendimiento de la migración)
donde el rendimiento de la migración es igual al número total de buzones que se pueden migrar por hora.
Por ejemplo, imagine que tiene un período de seis horas para migrar buzones. Si el promedio de tiempo de cola es de una hora y tiene un rendimiento de migración de 100 buzones por hora, puede migrar 500 buzones en el período de tiempo de seis horas: 500 = (6 - 1) * 100.
- Inicie la migración antes del momento planeado inicialmente para reducir el tiempo en la cola. Cuando los buzones estén en cola, los usuarios de Exchange 2003 seguirán teniendo acceso a sus buzones.
Determinar el tiempo de cola: el tiempo de cola siempre cambia porque Microsoft no administra las programaciones de migración de los clientes.
Para determinar el posible tiempo en cola, un cliente puede programar un movimiento de prueba varias horas antes de que se inicie la migración real. Después, según la cantidad de tiempo en que la petición esté en la cola, el cliente podrá calcular mejor cuándo iniciar la migración y cuántos buzones se pueden mover en un período de tiempo específico.
Por ejemplo, imagine que una migración de prueba se completó cuatro horas antes del inicio de una migración planeada. El cliente determina que el tiempo en cola de la migración de prueba era de aproximadamente una hora. Por lo tanto, el cliente tendría que iniciar la migración una hora antes del momento planeado originalmente para asegurarse de tener tiempo suficiente para completar todas las migraciones.
Herramientas de terceros para migraciones de Microsoft 365 u Office 365
Las herramientas de terceros se usan principalmente en escenarios de migración que no implican Exchange, como las de Gmail/G Suite/GWS (Google Workspace), IBM Lotus, Domino y Novell GroupWise. Esta sección se centra en los protocolos de migración usados por las herramientas de migración de terceros, en lugar de los productos y herramientas de migración en sí. En la tabla siguiente se proporciona una lista de factores que se aplican a herramientas de terceros para escenarios de migración de Microsoft 365 u Office 365.
Importante
Si tiene problemas con la coherencia o integridad de los datos después de realizar una migración mediante herramientas de terceros, póngase en contacto con el proveedor que proporcionó la herramienta para obtener soporte técnico.
Factor 1: Origen de datos para migraciones de herramientas de terceros
Lista de comprobación | Description | Procedimientos recomendados |
---|---|---|
Rendimiento del sistema | La extracción de datos es una tarea intensiva. El sistema de origen necesita tener recursos suficientes (como tiempo de CPU y memoria) para ofrecer un rendimiento de la migración óptimo. Durante la migración, el sistema de origen suele estar próximo a alcanzar su capacidad completa en términos de la carga de trabajo normal del usuario final. Si los recursos del sistema son inadecuados, la carga de trabajo adicional derivada de la migración puede afectar a los usuarios finales. | Supervise el rendimiento del sistema durante una prueba piloto de migración. Si el sistema está ocupado, le recomendamos que evite una programación de migración agresiva para el sistema específico debido a los posibles problemas de lentitud de la migración y de disponibilidad del servicio. Si es posible, agregue recursos de hardware para mejorar el rendimiento del sistema de origen y mueva las tareas y los usuarios a otros servidores que no estén relacionados con la migración para reducir la carga del sistema. Para obtener más información, vea: Estado del servidor y rendimiento de Exchange Server (2007, 2010, 2013, 2016, 2019). Nota: Los servidores de Exchange 2007 y 2010 ya no se admiten activamente. El fin del soporte técnico de Exchange 2013 Server está programado para abril de 2023. Exchange Server 2016 y 2019 están en soporte extendido hasta octubre de 2025. Consulte la matriz de compatibilidad de Exchange Server para obtener más detalles. Al realizar una migración desde una organización local de Exchange con varios servidores de buzones, le recomendamos que cree la lista de usuarios que se migrarán y que la distribuya de manera uniforme en varios servidores de buzones. Basándose en el rendimiento de cada servidor, la lista puede optimizarse aún más para maximizar la capacidad de proceso. Por ejemplo, si el servidor A tiene un 50 % más de disponibilidad de recursos que el servidor B, parece razonable tener un 50 % más de usuarios del servidor A en el mismo lote de migración. Se puede aplicar un procedimiento similar en otros sistemas de origen. Ejecute las migraciones cuando los servidores tengan el máximo de disponibilidad de recursos (por ejemplo, fuera del horario laboral o en fines de semana y días festivos). |
Tareas de back-end | Otras tareas de back-end que suelen ejecutarse durante la migración. Debido a que realizar las migraciones después del horario laboral es un procedimiento recomendado, también es típico que las migraciones entren en conflicto con otras tareas de mantenimiento que se están ejecutando en los servidores locales, como las copias de seguridad de datos. | Revise las otras tareas del sistema que pueden estar ejecutándose durante la migración. Recomendamos que las migraciones se lleven a cabo cuando no se estén ejecutando otras tareas de uso intensivo de recursos. Nota: Para los clientes que usan Exchange local, las tareas de back-end comunes son las soluciones de copia de seguridad y el mantenimiento del almacén de Exchange (2013, 2016, 2019). |
Directiva de limitación | Con frecuencia, se protegen los sistemas de correo electrónico con una directiva de limitación, que establece un límite específico en la velocidad y la cantidad de datos que se pueden extraer del sistema en un período de tiempo específico y con un método de migración concreto. | Compruebe la directiva de limitación implementada para el sistema de correo electrónico. Por ejemplo, Google Mail limita la cantidad de datos que se pueden extraer en un período determinado. Según la versión, Exchange tiene directivas que restringen el acceso de IMAP al servidor de correo local (usado por las migraciones de IMAP) y el acceso al protocolo RPC sobre HTTP (usado por las migraciones totales de Exchange y las migraciones preconfiguradas de Exchange). Para comprobar la configuración de limitación, ejecute el cmdlet Get-ThrottlingPolicy . Para obtener más información sobre la limitación, vea: (2007, 2010, 2013, 2016, 2019). Para obtener más información sobre la limitación de IMAP, consulte Migración de los buzones IMAP a Microsoft 365 u Office 365. |
Factor 2: Servidor de migración para migraciones de herramientas de terceros
La mayoría de las herramientas de terceros para migraciones de Microsoft 365 u Office 365 son datos iniciados por el cliente e insertados en Microsoft 365 u Office 365. Para usar estas herramientas suele necesitarse un servidor de migración. Factores como el rendimiento del sistema, las tareas de back-end y las directivas de limitación para los servidores de origen también se aplican en estos servidores de migración.
Nota:
Algunas soluciones de migración de terceros se hospedan en Internet como servicios basados en la nube y no requieren un servidor de migración local.
Solución y práctica:
Para mejorar el rendimiento de la migración al usar un servidor de migración, aplique los mismos procedimientos recomendados que los descritos en la sección Factor 1: Origen de datos para migraciones de herramientas de terceros .
Factor 3: Motor de migración para migraciones de herramientas de terceros
Para herramientas de migración de terceros, los protocolos más usados son los servicios Web Exchange y el protocolo RPC sobre HTTP.
Servicios web de Exchange:
Servicios web de Exchange es el protocolo recomendado que se debe usar para migrar a Microsoft 365 u Office 365, ya que admite lotes de datos grandes y tiene una mejor limitación orientada a servicios. En Microsoft 365 u Office 365, cuando se usan en modo de suplantación, las migraciones que usan servicios web de Exchange no consumen la cantidad presupuestada del usuario de los recursos de Microsoft 365 u Office 365 Exchange Web Services, consumiendo en su lugar una copia de los recursos presupuestados:
Todas las tareas de suplantación de los servicios Web Exchange realizadas por la misma cuenta de administrador se calculan por separado del presupuesto aplicado para esta cuenta de administrador.
Para cada sesión de suplantación, se crea una instantánea del presupuesto real del usuario. Todas las migraciones para esta sesión específica usarán esta instantánea.
La limitación con la suplantación se aísla para cada sesión de migración de usuario.
La directiva de limitación de Exchange Web Services se puede cambiar temporalmente en el inquilino (durante 30, 60 o 90 días) para permitir que se complete la migración. Esto se puede solicitar en la sección Ayuda del Centro de administración de Microsoft 365.
Procedimientos recomendados:
El rendimiento de la migración para los clientes que usen herramientas de migración de terceros y la suplantación EWA compite con las migraciones basadas en los servicios Web Exchange y el uso de recursos de servicios por otros espacios empresariales. Por lo tanto, el rendimiento de la migración puede variar.
Siempre que sea posible, recomendamos a los clientes que usen herramientas de migración de terceros que usen la suplantación de los servicios Web Exchange, que suele ser más rápida y eficiente que los protocolos de cliente, como el protocolo RPC sobre HTTP.
RPC a través del protocolo HTTP:
Las soluciones de migración tradicionales usan rpc a través del protocolo HTTP. Este método se basa completamente en un modelo de acceso de cliente, como el de Outlook, y la escalabilidad y el rendimiento son limitados porque el servicio Microsoft 365 u Office 365 limita el acceso en la suposición de que el uso lo hace un usuario en lugar de una aplicación.
Procedimientos recomendados:
Para las herramientas de migración que usan RPC a través del protocolo HTTP, es una práctica común aumentar el rendimiento de la migración mediante la adición de más servidores de migración y el uso de varias cuentas de usuario administrativo de Microsoft 365 u Office 365. Esta práctica puede ganar paralelismo de inyección de datos y lograr un mayor rendimiento de los datos porque cada usuario administrativo está sujeto a la limitación de usuarios de Microsoft 365 y Office 365. Recibimos informes de diferentes clientes empresariales que tuvieron que configurar más de 40 servidores de migración para obtener un rendimiento de migración de 20-30 GB/hora.
En una fase de desarrollo de herramienta de migración, es crítico tener en cuenta el número de operaciones RPC necesarias para migrar un mensaje. Para ilustrar esto, hemos recopilado los registros capturados por los servicios de Microsoft 365 u Office 365 para dos soluciones de migración de terceros (desarrolladas por empresas de terceros) que usan los clientes para migrar buzones a Microsoft 365 u Office 365. Comparamos las dos soluciones de migración desarrolladas por compañías de terceros. Comparamos la migración de dos buzones por cada solución de migración y también los comparamos al subir un archivo .pst en Outlook. Estos son los resultados.
Método | Tamaño del buzón de correo | Número de elementos | Tiempo de la migración | Total de transacciones RPC | Latencia de cliente media (ms) | AvgCasRPCProcessingTime (ms) |
---|---|---|---|---|---|---|
Solución A (buzón 1) | 376,9 MB | 4,115 | 4:24:33 | 132 040 | 48.4395 | 18.0807 |
Solución A (buzón 2) | 249,3 MB | 12 779 | 10:50:50 | 423 188 | 44.1678 | 4.8444 |
Solución B (buzón 1) | 618,1 MB | 4,322 | 1:54:58 | 12 196 | 37.2931 | 8.3441 |
Solución B (buzón 2) | 56,7 MB | 2,748 | 0:47:08 | 5,806 | 42.1930 | 7.4439 |
Outlook | 201,9 MB | 3,297 | 0:29:47 | 15 775 | 36.9987 | 5.6447 |
Nota:
Los tiempos de proceso de cliente y servicio son similares, pero la solución A requiere muchas más operaciones RPC para migrar datos. Dado que cada operación consume tiempo de latencia de cliente y tiempo de proceso del servidor, la solución A es mucho más lenta para migrar la misma cantidad de datos en comparación con la solución B y Outlook.
Factor 4: Red para migraciones de herramientas de terceros
Procedimiento recomendado:
Para soluciones de migración de terceros que usen el protocolo RPC sobre HTTP, esta es una forma adecuada de medir el posible rendimiento de la migración:
Desde el servidor de migración, conéctese al buzón de Microsoft 365 u Office 365 con Outlook mediante RPC a través del protocolo HTTP. Asegúrese de que no se conecta mediante el modo almacenado en caché.
Importe un archivo .pst grande con datos de ejemplo al buzón de Microsoft 365 u Office 365.
Para medir el rendimiento de la migración, calcule el tiempo necesario para subir el archivo .pst. El rendimiento de la migración será similar al que obtienen los clientes de una herramienta de migración de terceros que use el protocolo RPC sobre HTTP, siempre que no haya otras restricciones. Si hay una sobrecarga durante una migración real, el rendimiento podría ser ligeramente distinto.
Factor 5: Servicio de Microsoft 365 y Office 365
La limitación basada en el estado de los recursos de Microsoft 365 y Office 365 afecta a las migraciones mediante herramientas de migración de terceros. Consulte Limitación basada en el estado de los recursos de Microsoft 365 y Office 365 para obtener más detalles.