Guía de planificación · Migraciones Microsoft 365
¿Cuánto tarda una migración Microsoft 365? Una migración de 100 usuarios puede completarse como proyecto en unas pocas semanas, mientras que una organización de 5.000 usuarios suele necesitar varios meses. Pero el número de cuentas es solo una parte de la ecuación: 500 usuarios con Exchange y OneDrive sencillos pueden migrarse antes que 100 usuarios con varios terabytes de SharePoint, cientos de Teams, Intune, Power BI y aplicaciones dependientes.
Además, hay que distinguir entre el tiempo que tardan los datos en copiarse, la ventana de cutover y la duración total del proyecto. Una empresa puede realizar el corte de 500 usuarios durante un fin de semana después de haber trabajado varias semanas en assessment, preparación, precargas, pilotos y validaciones.
En esta guía damos rangos orientativos para 100, 500, 1.000 y 5.000 usuarios, explicamos qué factores cambian realmente el calendario y utilizamos datos de rendimiento publicados por Microsoft para separar una estimación seria de una cifra comercial sin contexto.
¿Quieres saber cuánto tardaría tu migración Microsoft 365?
Para estimar un proyecto correctamente no necesitamos únicamente saber cuántos usuarios existen. Revisamos buzones, OneDrive, SharePoint, Teams, dominios, dispositivos, aplicaciones, volumen de datos, requisitos de coexistencia y fecha objetivo.
Con ese inventario podemos definir un calendario por fases, un piloto y oleadas realistas en lugar de prometer una fecha únicamente a partir del número de licencias.
¿Cuánto tarda una migración Microsoft 365?
Como referencia de planificación, una migración Microsoft 365 estándar suele requerir unas 2–4 semanas para 100 usuarios, 4–8 semanas para 500 usuarios, 6–10 semanas para 1.000 usuarios y aproximadamente 12–20 semanas para 5.000 usuarios. Estos rangos se refieren al proyecto completo —assessment, preparación, piloto, migración, cutover y estabilización— y no únicamente al tiempo de copia de los datos.
El plazo real depende mucho más del volumen y tipo de información que del número de cuentas. Exchange puede mover muchos buzones en paralelo; SharePoint y OneDrive están condicionados por cantidad de archivos, metadatos y throttling; Teams añade dependencias con SharePoint y conversaciones; e Intune puede exigir reenrollment de dispositivos. Una migración sencilla puede ser bastante más rápida, mientras que un entorno con múltiples dominios, Power BI, Power Platform, Purview o requisitos de coexistencia puede necesitar varios meses adicionales.
Resumen rápido: cuánto tarda migrar 100, 500, 1.000 y 5.000 usuarios
Proyecto estándar con Exchange, OneDrive y colaboración Microsoft 365 sin dependencias extraordinarias.
Normalmente incluye piloto, precargas o preparación de contenido y varias oleadas de usuarios.
Conviene trabajar por fases y reservar margen para incidencias, coexistencia y validación.
Proyecto empresarial por oleadas. Entornos complejos pueden superar ampliamente este rango.
Importante: estos son rangos de planificación para un escenario Microsoft 365 estándar. No son un SLA de Microsoft ni sustituyen un assessment del entorno.
| Usuarios | Migración sencilla | Migración estándar | Migración compleja | Modelo de cambio habitual |
|---|---|---|---|---|
| 100 | 1–2 semanas | 2–4 semanas | 4–8 semanas | Un cutover o pocas oleadas |
| 500 | 2–4 semanas | 4–8 semanas | 8–12 semanas | Varias oleadas |
| 1.000 | 3–6 semanas | 6–10 semanas | 10–16 semanas | Migración por fases |
| 5.000 | 6–10 semanas | 12–20 semanas | 20–32+ semanas | Programa por oleadas |
Qué entendemos por “estándar”: Exchange Online, OneDrive, SharePoint/Teams dentro de un alcance razonable, identidad preparada, uno o pocos dominios, piloto previo y sin una reconstrucción masiva de Intune, Power BI, Power Platform o aplicaciones.
¿Qué significa exactamente “cuánto tarda una migración Microsoft 365”?
Hay tres tiempos diferentes: la duración total del proyecto, el tiempo de transferencia de datos y la ventana de cutover. Confundirlos es una de las razones por las que se encuentran estimaciones tan diferentes para la misma cantidad de usuarios.
1. Duración del proyecto
Desde el discovery inicial hasta que el nuevo entorno está validado: assessment, diseño, preparación, piloto, migraciones, cutover y hypercare.
2. Tiempo de copia
Horas o días durante los que Exchange, OneDrive, SharePoint u otra herramienta están moviendo información.
3. Ventana de cutover
Periodo en el que se ejecutan los cambios finales: dominio, identidad, correo, accesos o reconexión de usuarios.
Una migración puede durar seis semanas como proyecto y tener un cutover de solo unas horas.
Esto ocurre porque gran parte del trabajo se realiza antes: datos precargados cuando la tecnología lo permite, usuarios provisionados, permisos mapeados, pruebas ejecutadas y comunicaciones preparadas.
¿Por qué el número de usuarios no permite calcular por sí solo la duración?
Porque Microsoft 365 migra datos y objetos, no únicamente personas. Dos organizaciones con 500 usuarios pueden tener diez veces más diferencia de volumen, archivos, sitios, Teams o dispositivos que de número de empleados.
Los principales factores son:
- Volumen de Exchange: tamaño medio y máximo de los buzones.
- OneDrive: GB por usuario y número de archivos.
- SharePoint: sitios, bibliotecas, listas, versiones y metadatos.
- Teams: equipos, canales, conversaciones y aplicaciones.
- Intune: número real de endpoints y método de enrollment.
- Identidad: usuarios cloud-only, híbridos, grupos y aplicaciones.
- Dominios: uno o varios dominios y dependencias.
- Compliance: Holds, retention, Purview y Customer Key.
- Coexistencia: necesidad de que origen y destino trabajen juntos durante semanas o meses.
- Disponibilidad de negocio: empresas 24×7 tienen menos ventanas de intervención.
Ejemplo: 100 usuarios con 100 GB de OneDrive cada uno suman 10 TB. Otros 500 usuarios con solo 5 GB cada uno suman 2,5 TB. La empresa con menos personas tiene cuatro veces más datos personales que mover.
Y todavía falta considerar el número de archivos. Un terabyte formado por vídeos grandes suele procesarse mucho más rápido que un terabyte formado por millones de archivos pequeños.
¿Cuánto tarda una migración Microsoft 365 de 100 usuarios?
Una migración estándar de 100 usuarios suele poder planificarse en aproximadamente 2–4 semanas. Un alcance sencillo de correo y archivos puede reducirse a 1–2 semanas, mientras que un entorno con Teams complejo, Intune, aplicaciones o compliance puede necesitar 4–8 semanas.
Calendario orientativo
| Fase | Duración orientativa |
|---|---|
| Assessment e inventario | 2–4 días laborables |
| Preparación de destino e identidad | 2–5 días |
| Piloto | 2–4 días |
| Precarga / migración inicial | Varios días, normalmente en paralelo con otras tareas |
| Cutover | Una ventana o pocas oleadas |
| Validación / hypercare | 2–5 días |
¿Se pueden mover los 100 usuarios juntos?
En muchos escenarios, sí. Microsoft describe el modelo Single-Event Migration como adecuado para organizaciones pequeñas o medianas y cambios relativamente sencillos.
No obstante, incluso con 100 usuarios recomendamos realizar antes un piloto con varias personas representativas.
No deberían estar todos los primeros usuarios reales del proyecto dentro del mismo lote.
100 usuarios no implica automáticamente una migración “pequeña”. Si existe un SharePoint de varios terabytes, aplicaciones empresariales, Intune o decenas de shared mailboxes, la complejidad puede superar a la de una empresa mucho mayor.
¿Cuánto tarda una migración Microsoft 365 de 500 usuarios?
Para 500 usuarios, un rango razonable de planificación es de 4–8 semanas en una migración Microsoft 365 estándar. El proyecto puede completarse antes cuando el alcance es sencillo y puede extenderse a 8–12 semanas si incluye mucha colaboración, aplicaciones, dispositivos o requisitos de coexistencia.
¿Por qué ya suele ser recomendable trabajar por oleadas?
A partir de varios cientos de usuarios, el riesgo operativo empieza a importar tanto como la velocidad de transferencia.
Dividir el proyecto permite:
- validar cada lote antes de continuar;
- evitar concentrar todas las incidencias el mismo lunes;
- separar departamentos o ubicaciones;
- controlar mejor permisos y dependencias;
- adaptar el ritmo en función de lo aprendido en cada oleada.
¿Puede hacerse el cutover de 500 usuarios en un fin de semana?
Sí, técnicamente puede ser viable en un entorno bien preparado. Microsoft utiliza incluso un ejemplo de planificación en el que un throughput observado de 100 mailboxes/hora, descontando una hora de cola, permitiría procesar 500 buzones durante una ventana de seis horas.
Pero ese ejemplo sirve para explicar la fórmula de capacidad de Exchange; no significa que cualquier empresa de 500 personas pueda mover todo Microsoft 365 en seis horas.
SharePoint, OneDrive, Teams, dominio, dispositivos y soporte al usuario siguen siendo cargas independientes.
Para 500 usuarios distinguimos siempre “datos preparados antes” de “acciones que deben ocurrir durante el cutover”. Cuantas menos operaciones críticas dependan de la ventana final, menor es el riesgo.
¿Cuánto tarda una migración Microsoft 365 de 1.000 usuarios?
Una migración Microsoft 365 de 1.000 usuarios suele necesitar aproximadamente 6–10 semanas en un escenario estándar. Un proyecto sencillo puede situarse alrededor de 3–6 semanas, mientras que una migración empresarial con múltiples workloads puede necesitar entre 10 y 16 semanas.
Con 1.000 usuarios normalmente ya hablamos de un proyecto que debe gobernarse como un programa de oleadas, aunque técnicamente determinados datos puedan moverse con mucha más rapidez.
Qué suele ocupar realmente esas semanas
- assessment completo;
- mapping de identidades;
- inventario de grupos y shared mailboxes;
- pilotaje de usuarios representativos;
- precargas cuando el método elegido las soporta;
- SharePoint y Teams;
- varias oleadas de cutover;
- gestión de excepciones;
- validación y soporte posterior.
¿Por qué no mover los 1.000 usuarios de golpe?
Puede ser técnicamente posible en un entorno muy simple, pero normalmente no aporta una ventaja proporcional al riesgo.
Microsoft presenta las migraciones por fases como el modelo indicado para organizaciones grandes o entornos complejos.
Con 1.000 usuarios, el cuello de botella suele dejar de ser únicamente la transferencia. Comunicación, disponibilidad del service desk, coordinación con negocio y resolución de excepciones pueden determinar el tamaño máximo razonable de cada oleada.
¿Cuánto tarda una migración Microsoft 365 de 5.000 usuarios?
Para 5.000 usuarios, una planificación estándar suele situarse aproximadamente entre 12 y 20 semanas. Un alcance relativamente sencillo puede ejecutarse en unas 6–10 semanas, mientras que una consolidación empresarial compleja puede necesitar 20–32 semanas o más.
A esta escala ya no conviene pensar en “el día de la migración”. Se trata de un programa de transición con múltiples oleadas que pueden coexistir durante varios meses.
¿Por qué 5.000 usuarios no son simplemente cinco veces más que 1.000?
Porque muchos procesos pueden paralelizarse.
Mientras un lote está migrándose:
- otro puede estar validándose;
- el siguiente puede estar en precarga;
- pueden migrarse varios sitios SharePoint en paralelo;
- pueden prepararse usuarios futuros;
- pueden ejecutarse tareas de seguridad y aplicaciones simultáneamente.
Por eso una organización de 5.000 personas no tiene por qué tardar exactamente cinco veces más que una de 1.000.
Pero Microsoft también impone límites operativos
La migración nativa cross-tenant de OneDrive permite programar hasta 4.000 cuentas de OneDrive de antemano en un momento dado. SharePoint utiliza igualmente un límite de hasta 4.000 migraciones pendientes programadas.
Esto no significa que 4.000 cuentas se estén procesando simultáneamente; es un límite de cola. Pero ilustra por qué un entorno de 5.000 usuarios debe planificarse como un proyecto a escala.
Qué suele alargar una migración de 5.000 usuarios
- varios países o zonas horarias;
- operaciones 24×7;
- multi-geo;
- múltiples dominios;
- miles de Teams;
- decenas o cientos de terabytes;
- Intune y dispositivos;
- Power BI;
- Power Platform;
- aplicaciones SSO;
- compliance y retenciones;
- requisitos de coexistencia prolongada.
En 5.000 usuarios, intentar ganar dos semanas eliminando piloto, validación o margen de oleadas suele incrementar el riesgo mucho más de lo que reduce el plazo.
Fuente oficial relacionada: Microsoft Learn — Cross-tenant OneDrive migration.
¿Cuánto tarda en migrarse Exchange Online?
Exchange suele poder migrar muchos buzones en paralelo, por lo que no debe calcularse el plazo multiplicando “días por buzón × número de usuarios”. Microsoft publica percentiles observados de duración por tamaño de mailbox que permiten hacerse una idea mucho más realista.
Tiempos publicados por Microsoft para buzones cross-tenant
| Tamaño del buzón | P50 | P90 | Cómo interpretarlo |
|---|---|---|---|
| 0–10 GB | 1 día | 1 día | La mayoría de movimientos observados entra en este rango. |
| 10–50 GB | 1 día | 2 días | El 90 % de la muestra analizada estaba completada alrededor de 2 días. |
| 50–100 GB | 2 días | 5 días | Los buzones grandes necesitan más margen. |
| 100–200 GB | 3 días | 6 días | El tamaño individual empieza a afectar de forma notable. |
P50 y P90 no son garantías. Son percentiles derivados de migraciones observadas por Microsoft.
Un P90 de dos días tampoco significa que 500 buzones de 30 GB necesiten 1.000 días. Los buzones se procesan de forma concurrente dentro de los límites del servicio y de la infraestructura de origen.
El número de elementos también importa
Microsoft utiliza un ejemplo muy ilustrativo: un buzón de 4 GB formado por 400 elementos con grandes attachments se migra más rápido que otro buzón de 4 GB que contiene 100.000 elementos pequeños.
La razón es que cada objeto requiere procesamiento adicional.
La cola también consume tiempo
Una solicitud puede estar correctamente creada y permanecer temporalmente en estado Queued esperando recursos del Mailbox Replication Service.
Microsoft recomienda incluir ese tiempo de cola en la planificación y realizar pruebas antes de la ventana definitiva.
No planifiques Exchange únicamente por GB. Hay que medir tamaño, número de elementos, concurrency real, origen, cola y comportamiento observado en el piloto.
Fuente oficial: Microsoft Learn — Microsoft 365 migration performance and best practices.
¿Cuánto añade Microsoft Teams a la duración de una migración?
Teams puede añadir desde poco tiempo hasta varias semanas, porque “migrar Teams” no es una única operación. Hay que separar chats, reuniones, estructura de Teams, Channels, SharePoint, archivos, Planner, tabs y aplicaciones.
Microsoft 365 Migration Orchestrator coordina actualmente:
- Exchange Online;
- OneDrive;
- Teams Chats;
- Teams Meetings.
Pero Microsoft deja fuera de ese mismo alcance los datos compartidos como:
- Teams;
- Channels;
- SharePoint Sites.
Por tanto, una empresa que pide “migrar 1.000 usuarios con Teams” puede estar describiendo dos proyectos radicalmente distintos:
Escenario sencillo
Pocos Teams, poco historial, archivos controlados y sin aplicaciones especiales.
Escenario complejo
Cientos de Teams, canales privados y compartidos, conversaciones históricas, Planner, Lists, OneNote, tabs, apps e invitados.
En una estimación de tiempos no utilizamos únicamente “número de usuarios de Teams”. El inventario útil es número de Teams, Channels, sitios SharePoint asociados, volumen, conversaciones y dependencias.
Fuente oficial: Microsoft Learn — Migration Orchestrator overview.
¿Cómo afecta Intune al tiempo de una migración Microsoft 365?
Intune puede añadir varias semanas al calendario porque el número importante no es el de usuarios, sino el de dispositivos. Las políticas pueden reconstruirse o automatizarse parcialmente, pero los endpoints pueden necesitar reenrollment en el nuevo tenant.
Una organización con 1.000 usuarios puede tener:
- 800 portátiles;
- 1.000 portátiles;
- 1.600 portátiles y móviles;
- más de 2.000 dispositivos administrados.
Son proyectos muy diferentes aunque el número de empleados sea el mismo.
Qué debe planificarse
- Configuration Profiles;
- Compliance Policies;
- Endpoint Security;
- aplicaciones;
- Autopilot;
- Entra Join;
- BitLocker;
- certificados;
- Wi-Fi y VPN;
- Company Portal;
- reenrollment;
- soporte al usuario.
Si Intune está en alcance, no utilizaríamos la tabla de 100/500/1.000/5.000 usuarios sin añadir también el número de dispositivos.
¿Power BI, Power Platform, Planner y seguridad pueden alargar la migración?
Sí, y pueden hacerlo de forma totalmente independiente del número de usuarios. Una empresa de 300 personas con un entorno Power BI crítico puede necesitar más trabajo que otra de 2.000 usuarios que apenas utiliza esas cargas.
Power BI
Workspaces, gateways, semantic models, dataflows, conexiones, credenciales y Power BI Apps requieren análisis y, en diferentes casos, reconstrucción.
Power Platform
Power Apps, Power Automate y Dataverse tienen sus propios procedimientos y tareas post-migración.
Planner
Los planes pueden requerir recreación o automatización. La cantidad relevante es número y complejidad de planes, no usuarios licenciados.
Conditional Access, Purview y Defender
Estas configuraciones no viajan automáticamente con Exchange o OneDrive. Deben recrearse o adaptarse en el entorno destino.
Enterprise Applications
SSO, service principals, certificados, secretos, consentimientos y aplicaciones pueden requerir una línea de trabajo independiente.
¿La duración cambia según el origen de la migración?
Sí. Una migración tenant-to-tenant, una migración desde Exchange on-premises, Google Workspace o un servidor IMAP utilizan mecanismos diferentes y pueden tener velocidades muy distintas.
Microsoft publica percentiles observados de duración para mailboxes de distintos orígenes.
Ejemplo para un buzón de 10–50 GB
| Origen | P50 | P90 |
|---|---|---|
| Microsoft 365 tenant-to-tenant | 1 día | 2 días |
| Exchange on-premises | 2 días | 6 días |
| Google Workspace especializado | 1 día | 8 días |
| IMAP genérico | 1 día | 2 días |
Estas cifras muestran por qué decir simplemente “500 usuarios tardan cinco semanas” sin conocer el origen es demasiado simplista.
Y vuelven a ser duraciones por mailbox observadas, no la duración completa de la organización.
Fuente oficial: Microsoft Learn — Exchange migration duration estimates.
¿Qué es el throttling y por qué puede retrasar una migración Microsoft 365?
El throttling es el mecanismo con el que Microsoft limita temporalmente determinadas cargas para proteger la disponibilidad y rendimiento de Microsoft 365. Es normal durante migraciones y no significa necesariamente que exista un fallo.
Exchange documenta diferentes formas de limitación:
- user throttling;
- migration-service throttling;
- resource-health throttling.
SharePoint y OneDrive también regulan las cargas de migración para proteger el servicio.
¿Más concurrencia siempre significa más velocidad?
No. Lanzar demasiados trabajos simultáneos puede conseguir el efecto contrario.
Microsoft recomienda, por ejemplo, no acumular más de 5.000 solicitudes de migración en la cola de SharePoint Migration API.
El objetivo es alcanzar el punto de paralelismo óptimo, no lanzar todos los jobs posibles.
¿Por qué el piloto es importante para medir tiempos?
Porque revela el throughput real del entorno:
- tiempo de cola;
- velocidad de Exchange;
- comportamiento de OneDrive;
- errores;
- throttling;
- velocidad de origen;
- efectos sobre usuarios.
Después del piloto se puede reemplazar una estimación teórica por una proyección basada en datos reales del cliente.
Fuentes oficiales: Exchange migration performance · SharePoint and OneDrive migration performance.
¿Cuántos usuarios conviene migrar en cada oleada?
No existe un tamaño universal de oleada. Debe calcularse según complejidad, capacidad de soporte, tiempo disponible para el cutover y comportamiento medido en el piloto.
Como criterio de proyecto, el tamaño debe permitir:
- completar las acciones críticas dentro de la ventana disponible;
- validar a los usuarios antes de iniciar la siguiente fase;
- absorber incidencias sin saturar soporte;
- mantener departamentos y dependencias juntos cuando sea necesario;
- dejar margen para usuarios excepcionales.
Ejemplo práctico
En una organización de 1.000 usuarios podría ser razonable comenzar con:
- un piloto reducido;
- una primera oleada controlada;
- varias oleadas mayores una vez validado el comportamiento;
- una oleada específica para casos especiales.
Eso suele ser más fiable que definir desde el primer día cuatro lotes exactos de 250 personas sin conocer el throughput real.
¿Se puede hacer una migración Microsoft 365 en un fin de semana?
El cutover sí puede realizarse en un fin de semana; el proyecto completo, normalmente no. La clave consiste en trasladar todo el trabajo posible fuera de esa ventana.
Antes del viernes deberían estar preparados:
- tenant destino;
- usuarios y grupos;
- licencias;
- identity mapping;
- herramientas;
- precargas permitidas;
- piloto;
- dominio y DNS;
- comunicaciones;
- runbook;
- criterios de rollback;
- equipo de soporte.
100 usuarios
Un único fin de semana de cutover es habitual si el alcance es razonable.
500 usuarios
También puede ser viable en una sola ventana cuando la migración está bien pre-staged y la organización acepta ese nivel de concentración.
1.000 usuarios
Técnicamente puede conseguirse en escenarios concretos, pero normalmente preferimos evaluar si varias oleadas reducen el riesgo.
5.000 usuarios
Una única ventana para toda la organización suele ser mucho menos atractiva que una transición por fases, especialmente si hay varios workloads y zonas horarias.
¿Cuáles son las fases de una migración Microsoft 365 y cuánto tarda cada una?
La duración total se reparte entre assessment, preparación, piloto, movimiento de datos, cutover y estabilización. Muchas de estas fases pueden solaparse.
| Fase | Objetivo | Duración habitual |
|---|---|---|
| 1. Discovery / Assessment | Inventariar datos, usuarios, workloads y riesgos. | Días a varias semanas según escala. |
| 2. Diseño | Arquitectura destino, coexistencia, dominio, seguridad y oleadas. | Varios días a semanas. |
| 3. Preparación | Usuarios, grupos, licencias, permisos, aplicaciones y herramientas. | Varios días a semanas. |
| 4. Piloto | Medir throughput y validar la experiencia real. | Normalmente varios días. |
| 5. Bulk / Pre-stage | Mover todo el contenido posible antes del cambio. | Puede ejecutarse durante días o semanas en paralelo. |
| 6. Oleadas / Cutover | Mover usuarios a producción. | Una o múltiples ventanas. |
| 7. Hypercare | Resolver incidencias y validar aceptación. | Varios días por fase o al final. |
En una organización de 5.000 usuarios, por ejemplo, el assessment del último departamento puede estar cerrándose mientras los primeros usuarios ya están migrando.
No todas las fases tienen que esperar a que la anterior finalice al 100 %.
¿Cómo se puede acelerar una migración Microsoft 365 sin aumentar el riesgo?
La forma más eficaz de acelerar una migración no es aumentar ciegamente la concurrencia, sino eliminar trabajo innecesario y preparar mejor el origen y el destino.
- Inventariar antes de migrar. No trasladar datos y objetos sin uso.
- Eliminar contenido obsoleto. Menos datos significan menos transferencia y menos errores.
- Detectar archivos problemáticos con antelación.
- Preparar identidades correctamente. Evita permisos rotos y remediaciones posteriores.
- Realizar un piloto. Permite conocer el throughput real.
- Usar paralelismo controlado. Microsoft recomienda paralelizar distintas colecciones de sitios cuando sea posible.
- Aprovechar horas de baja actividad. Especialmente en SharePoint y OneDrive.
- Precargar cuando la tecnología lo permita.
- Separar casos excepcionales. Un mailbox problemático no debería bloquear a 500 usuarios.
- Automatizar validaciones. Counts, errores, permisos y logs pueden revisarse programáticamente.
Una de las mejores formas de reducir una migración de 16 a 12 semanas puede ser retirar contenido que no debe migrarse, no intentar forzar un 30 % más de jobs contra Microsoft 365.
¿Qué factores suelen retrasar una migración Microsoft 365?
Los retrasos suelen aparecer por excepciones no descubiertas durante el assessment, no porque Microsoft 365 “copie lentamente” de forma constante.
- buzones enormes;
- millones de elementos pequeños;
- sitios SharePoint con demasiados elementos;
- rutas de archivo incompatibles;
- Holds;
- Customer Key;
- usuarios sin mapping;
- permisos complejos;
- Teams con muchas dependencias;
- Power BI no inventariado;
- aplicaciones que dependen del tenant antiguo;
- domain cutover no preparado;
- equipos Intune no inventariados;
- throttling;
- problemas de red u origen;
- falta de ventanas de negocio;
- decisiones pendientes del cliente;
- falta de recursos de soporte durante las oleadas.
Cuanto antes aparezcan estos elementos, menos afectan a la fecha final.
¿Qué información hace falta para calcular cuánto tardará una migración Microsoft 365?
Para calcular un calendario fiable necesitamos un inventario por workload y volúmenes reales. El dato “tenemos 1.000 usuarios” solo permite dar una primera horquilla.
Exchange e identidad
- Usuarios totales
- User mailboxes
- Shared mailboxes
- Archive mailboxes
- Tamaño medio y máximo
- Holds
- Groups
- Dominios
- AD on-premises
OneDrive y SharePoint
- Cuentas OneDrive
- TB totales
- Número de archivos
- Sitios SharePoint
- TB de SharePoint
- Elementos por sitio
- Versiones
- Permisos
Teams y aplicaciones
- Número de Teams
- Channels
- Chats
- Planner
- Power BI
- Power Platform
- Enterprise Applications
- App Registrations
Usuarios y operación
- Dispositivos Intune
- Países y zonas horarias
- Operación 24×7
- Coexistencia necesaria
- Ventana de cutover
- Capacidad de soporte
- Fecha objetivo
Después de obtener esos datos se realiza un piloto y se sustituye la horquilla inicial por un calendario mucho más preciso.
¿Tienes ya las cantidades de tu entorno?
Envíanos usuarios, buzones, OneDrive, SharePoint, Teams, grupos, dispositivos y fecha objetivo. Podemos revisar el alcance y plantear un calendario realista por fases.
¿Cuáles son los errores más habituales al calcular cuánto tardará una migración?
El error principal es transformar el número de usuarios en días sin conocer los datos y workloads. A partir de ahí aparecen muchas estimaciones poco fiables.
- Calcular únicamente por usuarios.
- No diferenciar proyecto, copia y cutover.
- Multiplicar el tiempo de un mailbox por todos los usuarios.
- Ignorar el paralelismo.
- Suponer que el ancho de banda de Internet determina toda la velocidad.
- No contar archivos y elementos.
- No considerar throttling.
- Calcular Teams solo por usuarios.
- Olvidar Intune.
- No contar Power BI o Power Platform.
- No realizar un piloto.
- No dejar margen para excepciones.
- Planificar el mismo tamaño para todas las oleadas.
- Confundir velocidad técnica con capacidad del service desk.
- Prometer una fecha cerrada antes de inventariar.
Microsoft nativo o herramientas especializadas: ¿qué opción es más rápida?
No existe una respuesta universal. La vía más rápida depende de qué workload se mueve, de las capacidades nativas disponibles y de si el proyecto necesita precargas, deltas, coexistencia o reporting avanzado.
Microsoft dispone actualmente de capacidades muy potentes para:
- Cross-Tenant Mailbox Migration;
- Microsoft 365 Migration Orchestrator;
- Cross-Tenant OneDrive Migration;
- Cross-Tenant SharePoint Migration;
- Cross-Tenant Identity Mapping.
Plataformas especializadas pueden aportar:
- precargas;
- delta passes en workloads compatibles;
- coexistencia;
- matching;
- reporting;
- automatización;
- tratamiento conjunto de varios workloads.
La herramienta más rápida no es necesariamente la que obtiene el mayor throughput bruto. Es la que permite completar el proyecto con menos retrabajo y menor riesgo dentro de las necesidades de la organización.
Si quieres comparar enfoques puedes consultar nuestra guía de herramientas y scripts para migrar tenants Microsoft 365.
¿Cómo planifica MSAdvance el calendario de una migración Microsoft 365?
Primero damos una horquilla y después la convertimos en un calendario real mediante assessment y piloto. No fijamos el plazo definitivo únicamente a partir del número de usuarios.
El proceso se basa en:
- inventariar usuarios y workloads;
- medir volúmenes y elementos;
- identificar excepciones;
- definir arquitectura destino;
- seleccionar herramientas;
- crear un lote piloto;
- medir throughput real;
- calcular el tamaño de las oleadas;
- coordinar el calendario con negocio;
- reservar margen para incidencias y hypercare.
Esto permite responder no solo a “cuántas semanas tardará”, sino también a preguntas más útiles:
- ¿cuándo se moverá cada departamento?
- ¿cuánto tiempo convivirán ambos tenants?
- ¿qué ocurrirá durante el fin de semana?
- ¿qué tiene que hacer el usuario?
- ¿qué ocurre si un lote no termina?
- ¿cuándo puede retirarse el tenant origen?
Preguntas frecuentes sobre cuánto tarda una migración Microsoft 365
Respuestas directas a las preguntas más habituales al preparar el calendario de una migración.
¿Cuánto tarda una migración Microsoft 365?
Depende de usuarios, volumen y workloads. Como referencia de proyecto, una migración estándar puede requerir unas 2–4 semanas para 100 usuarios, 4–8 para 500, 6–10 para 1.000 y 12–20 semanas para 5.000. Un alcance muy sencillo puede ser más rápido y uno con Teams, Intune, Power BI, Power Platform, varias ubicaciones o compliance puede necesitar bastante más tiempo.
¿Cuánto tarda migrar 100 usuarios a Microsoft 365?
Un proyecto estándar de 100 usuarios suele poder planificarse en aproximadamente 2–4 semanas. Una migración sencilla de correo y archivos puede completarse antes, mientras que Teams complejo, SharePoint, Intune, aplicaciones y requisitos de cumplimiento pueden ampliar el plazo.
¿Cuánto tarda migrar 500 usuarios a Microsoft 365?
Como referencia, una migración estándar de 500 usuarios suele situarse en unas 4–8 semanas. La copia de datos puede ejecutarse durante parte de ese periodo en segundo plano y el cutover final puede concentrarse en una o varias ventanas. La duración depende especialmente de OneDrive, SharePoint, Teams, tamaño de mailboxes y requisitos de coexistencia.
¿Cuánto tarda migrar 1.000 usuarios a Microsoft 365?
Un rango razonable para una migración estándar de 1.000 usuarios es aproximadamente 6–10 semanas. En esta escala suele ser recomendable trabajar por fases con piloto, varias oleadas, validación y soporte. Un entorno sencillo puede tardar menos y una consolidación con muchos workloads puede alcanzar 10–16 semanas o más.
¿Cuánto tarda migrar 5.000 usuarios a Microsoft 365?
Una migración estándar de 5.000 usuarios suele planificarse en torno a 12–20 semanas. Entornos relativamente sencillos pueden ser más rápidos, mientras que organizaciones multinacionales, 24×7 o con Teams, Intune, Power BI, aplicaciones y varias decenas de terabytes pueden necesitar 20–32 semanas o más.
¿Puede una migración Microsoft 365 hacerse en un fin de semana?
El cutover puede realizarse durante un fin de semana si el entorno está preparado y gran parte del contenido ya se ha migrado o preprocesado. El proyecto completo normalmente empieza semanas antes con assessment, identidad, piloto, precargas, DNS, comunicaciones y pruebas. “Migrar en un fin de semana” suele referirse a la ventana final de cambio, no a todo el proyecto.
¿Se pueden migrar 500 usuarios en un fin de semana?
Sí, puede ser técnicamente viable en un alcance bien preparado. Exchange permite procesar múltiples mailboxes en paralelo y Microsoft incluso utiliza ejemplos de cientos de buzones dentro de una ventana de varias horas. Sin embargo, SharePoint, OneDrive, Teams, dominio y soporte al usuario deben estar preparados previamente. En otros entornos puede ser más seguro utilizar varias oleadas.
¿Se pueden migrar 1.000 usuarios de golpe?
Es técnicamente posible en determinados escenarios, pero no siempre recomendable. Microsoft identifica la migración por fases como un modelo adecuado para grandes organizaciones y entornos complejos. Dividir la población permite reducir el impacto de incidencias y controlar mejor soporte, dependencias y validación.
¿Qué tarda más: Exchange o OneDrive?
No puede responderse únicamente por workload. Un mailbox pequeño puede migrarse rápidamente, mientras que un OneDrive con cientos de gigabytes y muchos archivos puede tardar bastante más. Pero también puede ocurrir lo contrario. Exchange está muy condicionado por tamaño y elementos; OneDrive por volumen, número de archivos, permisos y throttling.
¿Cuánto tarda en migrarse un buzón de Exchange Online?
Microsoft publica para migraciones cross-tenant un P50 de aproximadamente un día para buzones de hasta 50 GB y un P90 de dos días para buzones de entre 10 y 50 GB. Entre 50 y 100 GB, Microsoft publica aproximadamente 2 días de P50 y 5 días de P90. Son datos observados, no garantías.
¿Cuánto tarda migrar 1 TB a SharePoint?
Depende enormemente del tipo de contenido. Microsoft publica para la SharePoint Migration API referencias máximas que van desde unos 250 GB/día para contenido intensivo en pequeños elementos y metadatos hasta 1 TB/día para contenido medio y 10 TB/día para archivos grandes. Son valores máximos orientativos, no un SLA.
¿Por qué un terabyte puede tardar mucho más que otro?
Porque cada archivo u objeto requiere procesamiento. Un terabyte formado por archivos grandes puede transferirse con mucha eficiencia, mientras que el mismo volumen repartido entre millones de archivos pequeños, listas, versiones y metadatos genera muchas más operaciones y puede migrar notablemente más despacio.
¿Microsoft limita la velocidad de las migraciones?
Sí. Microsoft 365 utiliza throttling para proteger el servicio y garantizar disponibilidad para todos los clientes. Exchange y SharePoint aplican diferentes mecanismos de limitación. El throttling es normal y no implica necesariamente que exista un problema con la herramienta.
¿Puede Microsoft quitar el throttling para acelerar una migración?
En SharePoint, Microsoft indica expresamente que las reglas de throttling no pueden deshabilitarse o suspenderse simplemente abriendo una incidencia. La estrategia correcta es diseñar adecuadamente el paralelismo, utilizar ventanas de menor actividad y evitar sobrecargar las colas.
¿Las migraciones son más rápidas por la noche?
En SharePoint y OneDrive, Microsoft documenta que las aplicaciones en segundo plano pueden recibir una limitación mayor durante el horario laboral de los días de semana y que existe mayor capacidad disponible durante noches y fines de semana de la región. Por ello las grandes migraciones suelen aprovechar esas ventanas.
¿Teams aumenta mucho el tiempo de migración?
Puede aumentarlo mucho si el entorno utiliza numerosos Teams, Channels, conversaciones, Planner, SharePoint y aplicaciones. Teams no es una única carga de datos. Microsoft Migration Orchestrator cubre actualmente chats y reuniones dentro de su ámbito, pero Teams, Channels y SharePoint compartido requieren un tratamiento adicional.
¿Intune aumenta la duración de una migración?
Sí, especialmente cuando hay muchos dispositivos. Las políticas pueden reconstruirse parcialmente, pero los endpoints pueden requerir reenrollment en el tenant destino. Por eso una estimación seria debe preguntar por número de dispositivos además del número de usuarios.
¿Qué es una precarga de migración?
Es el movimiento anticipado de una gran parte de los datos antes de la ventana final. El usuario continúa trabajando en origen y posteriormente se ejecutan sincronizaciones adicionales cuando la tecnología lo permite. Esto reduce el volumen pendiente durante el cutover. No todos los mecanismos nativos admiten deltas; OneDrive cross-tenant nativo, por ejemplo, es one-and-done.
¿Qué es una oleada de migración?
Una oleada es un grupo de usuarios que cambia al nuevo entorno dentro de una misma ventana. Las oleadas permiten dividir una organización grande en bloques manejables, validar resultados y evitar concentrar todas las incidencias al mismo tiempo.
¿Cuánto tiempo deben convivir dos tenants Microsoft 365?
Depende de la estrategia. Una organización pequeña puede necesitar coexistencia durante pocos días, mientras que una migración de miles de usuarios puede mantener ambos entornos operativos durante semanas o meses. Deben prepararse mail routing, free/busy, colaboración e identidad para ese periodo.
¿Cómo puedo saber cuánto tardará exactamente mi migración?
Primero hay que inventariar usuarios, mailboxes, tamaño de Exchange, OneDrive, SharePoint, Teams, grupos, dispositivos, aplicaciones, dominios y requisitos de coexistencia. Después se realiza un piloto para medir throughput y errores reales. Con esos datos puede construirse un calendario mucho más preciso que con el número de usuarios por sí solo.
¿Qué herramienta migra Microsoft 365 más rápido?
No existe una herramienta universalmente más rápida. Las capacidades nativas de Microsoft pueden ser excelentes para determinados workloads y las herramientas especializadas pueden aportar precargas, deltas, coexistencia o automatización. La mejor opción depende del origen, alcance y requisitos del proyecto.
¿Puede MSAdvance calcular el plazo antes de empezar?
Sí. A partir del inventario podemos establecer una primera horquilla y diseñar un plan de fases. Después del piloto se ajusta el calendario utilizando throughput, tiempos de cola, errores y comportamiento reales del entorno. De esta forma la fecha objetivo se basa en datos del proyecto y no únicamente en una estimación genérica por usuario.
Fuentes oficiales sobre rendimiento y planificación de migraciones Microsoft 365
Microsoft recomienda probar el entorno y medir el rendimiento real antes de cerrar el calendario. Estas son algunas de las fuentes utilizadas para elaborar esta guía.
- Plan a Microsoft 365 tenant-to-tenant migration — planificación, dependencias, coexistencia y factores que afectan al timeline.
- Microsoft 365 email migration performance and best practices — percentiles de duración de buzones, throttling y factores de rendimiento.
- SharePoint and OneDrive migration performance — rendimiento por tipo de contenido y recomendaciones sobre throttling.
- SharePoint Migration API — arquitectura, colas y funcionamiento best-effort sin SLA de rendimiento.
- Microsoft 365 Migration Orchestrator — modelos single-event y phased, workloads soportados y dependencias.
- Cross-Tenant OneDrive Migration — límites de cola, características y restricciones.
- Cross-Tenant SharePoint Migration — programación, límites y recomendaciones para grandes lotes.
Guías relacionadas de MSAdvance
Conclusión: cuánto tarda realmente una migración Microsoft 365
Como referencia inicial, una migración Microsoft 365 estándar puede requerir aproximadamente 2–4 semanas para 100 usuarios, 4–8 semanas para 500, 6–10 semanas para 1.000 y 12–20 semanas para 5.000 usuarios.
Pero esas cifras solo son útiles si se entiende qué representan: la duración del proyecto completo, no el tiempo que tarda cada buzón en copiarse ni las horas de la ventana final.
Microsoft 365 permite ejecutar muchos movimientos en paralelo. Al mismo tiempo, Exchange, OneDrive, SharePoint y Teams aplican sus propios mecanismos, colas y límites. El volumen, el número de elementos, la complejidad de colaboración, Intune, aplicaciones y las restricciones de negocio pueden modificar completamente el calendario.
Por eso el dato más útil no es “tenemos 1.000 usuarios”. Es:
“Tenemos 1.000 usuarios, 850 mailboxes de 28 GB de media, 700 OneDrive con 12 TB, 160 sitios SharePoint, 220 Teams, 1.400 dispositivos Intune, dos dominios y queremos terminar antes de una fecha concreta.”
Con esa información puede construirse un calendario realista.
MSAdvance analiza el entorno, realiza un piloto y diseña las oleadas para que la duración se base en la capacidad real del proyecto y no en una regla genérica por usuario.
¿Quieres saber cuánto tardaría tu migración Microsoft 365?
Envíanos el número de usuarios, buzones, OneDrive, SharePoint, Teams, dispositivos y fecha objetivo. Revisaremos el alcance y plantearemos un calendario por fases para tu entorno.
