Guía de compra técnica · Migraciones Microsoft 365
Elegir una empresa para una migración Microsoft 365 no debería reducirse a comparar precio por usuario o comprobar si aparece un logotipo de Microsoft en su web. Una migración puede afectar a Exchange Online, OneDrive, SharePoint, Teams, Microsoft Entra ID, dominios, aplicaciones, dispositivos, Power BI, Power Platform y seguridad. El proveedor debe saber cómo se relacionan esas piezas y qué ocurre cuando alguna de ellas no puede trasladarse de forma directa.
Una propuesta técnicamente sólida debería explicar qué se va a migrar, qué no, qué herramientas se utilizarán, cómo se protegerán los accesos administrativos, cómo se probará el proceso, qué ocurrirá durante el cutover y cómo se demostrará que la información está correctamente disponible en destino.
Esta guía reúne 15 criterios técnicos para elegir una empresa de migración Microsoft 365 y una matriz de 100 puntos que puedes utilizar para comparar consultoras antes de adjudicar el proyecto.
¿Estás comparando empresas para una migración Microsoft 365?
Antes de comparar únicamente precios, asegúrate de que todas las propuestas incluyen el mismo alcance. En MSAdvance revisamos usuarios, buzones, OneDrive, SharePoint, Teams, identidades, dominios, aplicaciones, dispositivos y requisitos de seguridad antes de cerrar la estrategia definitiva.
¿Cómo elegir una empresa para una migración Microsoft 365?
Una buena empresa de migración Microsoft 365 debería cumplir al menos 15 criterios: realizar assessment previo; dominar los workloads incluidos; declarar claramente exclusiones y limitaciones; diseñar identidad y arquitectura destino; seleccionar la herramienta según el escenario; ejecutar un piloto; planificar coexistencia y secuenciación; documentar cutover y rollback; utilizar acceso administrativo de mínimo privilegio; cubrir RGPD y tratamiento de datos; definir criterios de validación; estimar tiempos considerando volumen y throttling; preparar la experiencia del usuario y los dispositivos; disponer de gobierno, reporting y hypercare; y poder demostrar competencias y proyectos comparables.
Una certificación Microsoft o una herramienta conocida son señales positivas, pero ninguna sustituye estos controles. La mejor consultora es la que puede explicar con precisión qué ocurrirá antes, durante y después del movimiento y cómo verificará que el entorno destino funciona.
Matriz rápida: 100 puntos para comparar empresas de migración Microsoft 365
Esta matriz permite comparar propuestas con criterios técnicos homogéneos. La ponderación es orientativa, pero obliga a mirar más allá del precio.
| # | Criterio | Peso | Qué debería demostrar el proveedor |
|---|---|---|---|
| 1 | Assessment y discovery | 10 | Inventario real antes de cerrar alcance y diseño. |
| 2 | Dominio de workloads y exclusiones | 10 | Sabe qué se puede migrar, qué es parcial y qué debe recrearse. |
| 3 | Arquitectura destino y dependencias | 8 | No limita el proyecto a copiar datos. |
| 4 | Identidad, dominio y DNS | 8 | Plan claro de Entra ID, UPN, grupos, dominio y mail flow. |
| 5 | Estrategia de herramientas | 7 | Elige Microsoft nativo, terceros, Graph o PowerShell según necesidad. |
| 6 | Piloto real | 7 | Prueba usuarios y workloads representativos antes de producción. |
| 7 | Coexistencia y secuenciación | 8 | Entiende dependencias entre Exchange, Teams, OneDrive y SharePoint. |
| 8 | Cutover, contingencia y rollback | 8 | Runbook detallado, responsables y criterios de decisión. |
| 9 | Seguridad de accesos administrativos | 8 | Mínimo privilegio, acceso limitado y auditable. |
| 10 | Protección de datos y compliance | 6 | DPA, subencargados, herramientas y tratamiento de datos claros. |
| 11 | Validación y aceptación | 8 | Define cómo demostrará que la migración es correcta. |
| 12 | Estimación técnica de tiempos | 5 | Considera volumen, elementos, throttling y capacidad real. |
| 13 | Usuario final y endpoints | 5 | Contempla Outlook, OneDrive, Teams, MFA e Intune. |
| 14 | Gobierno, reporting y soporte | 4 | Roles, seguimiento, escalado, hypercare y documentación. |
| 15 | Competencias y referencias verificables | 3 | Partner, certificaciones y proyectos realmente comparables. |
85–100 puntos
Proveedor técnicamente sólido. Las posibles diferencias deberían centrarse ya en propuesta, equipo y condiciones concretas.
70–84 puntos
Puede ser una buena opción, pero conviene cerrar expresamente los huecos antes de firmar.
55–69 puntos
Riesgo relevante. Probablemente hay aspectos del proyecto que todavía no están suficientemente definidos.
Menos de 55
No recomendaríamos adjudicar una migración compleja sin rehacer alcance, metodología y responsabilidades.
¿Basta con contratar una empresa que sea Microsoft Partner?
No. Ser partner o disponer de una designación Microsoft es una señal positiva, pero no demuestra por sí sola experiencia específica en la migración que necesita tu empresa.
La designación Solutions Partner for Modern Work sí aporta información relevante. Microsoft exige actualmente alcanzar un mínimo de 70 puntos sobre 100 y evalúa tres áreas:
- rendimiento del partner;
- capacitación y certificaciones;
- éxito con clientes.
Entre los workloads relacionados con Modern Work se encuentran Exchange Online, Microsoft Intune, SharePoint Online, Teams y Microsoft Entra ID.
Es, por tanto, un buen indicador de capacidad general.
Pero una organización que va a realizar un carve-out de 3.000 usuarios con Teams, Power BI, aplicaciones y varios dominios necesita comprobar además si el equipo asignado ha trabajado realmente con ese tipo de dependencias.
Fuente oficial: Microsoft — Solutions Partner for Modern Work.
1 ¿Hace un assessment antes de cerrar la migración?
Una empresa de migración Microsoft 365 debería inventariar el entorno antes de definir definitivamente alcance, herramientas, precio y calendario.
Como mínimo debería pedir datos sobre:
- usuarios;
- buzones de usuario;
- shared mailboxes;
- archives;
- OneDrive;
- SharePoint Sites;
- Microsoft Teams;
- Teams Chats si entran en alcance;
- grupos;
- dominios;
- Intune;
- aplicaciones;
- Power BI y Power Platform cuando existan;
- Holds y retention;
- identidad híbrida;
- fecha objetivo.
Microsoft incluye identidad, dependencias entre workloads, coexistencia, licenciamiento y timeline entre las principales consideraciones de una migración tenant-to-tenant.
2 ¿Domina realmente los workloads incluidos y explica lo que NO se puede migrar?
Un proveedor competente debería poder explicar por separado Exchange, OneDrive, SharePoint, Teams, Planner, Power BI, Intune, Power Platform, Entra ID y seguridad.
La respuesta “sí, migramos Microsoft 365 completo” es demasiado imprecisa.
Microsoft dispone de distintas capacidades para distintos workloads y existen objetos que deben recrearse o adaptarse.
Preguntas útiles:
- ¿qué contenido de Exchange entra realmente?
- ¿qué ocurre con shared mailboxes y delegaciones?
- ¿qué pasa con permisos y sharing de OneDrive?
- ¿cómo se tratan Teams y Channels?
- ¿qué ocurre con Planner?
- ¿Power BI se migra o se reconstruye?
- ¿los dispositivos Intune cambian automáticamente de tenant?
- ¿qué pasa con Conditional Access?
- ¿qué ocurre con Enterprise Applications?
Desconfía de cualquier proveedor que prometa “100 % de Microsoft 365 idéntico en destino” sin matices. Hay servicios que no disponen de una migración 1:1.
Puedes ampliar este punto en la guía de migración Microsoft 365 entre tenants de MSAdvance.
3 ¿Diseña el tenant destino o se limita a copiar datos?
Una migración no debería empezar copiando información hasta saber cómo debe quedar el entorno destino.
Esto incluye decisiones sobre:
- modelo de identidad;
- UPN y dominios;
- estructura SharePoint;
- Teams y Groups;
- naming;
- licenciamiento;
- Conditional Access;
- guest access;
- external sharing;
- retention;
- aplicaciones;
- Intune;
- roles administrativos.
En una consolidación, copiar exactamente todos los grupos, sitios y excepciones del tenant anterior puede trasladar años de deuda técnica al nuevo entorno.
4 ¿Tiene una estrategia clara de identidad, dominio y DNS?
Identidad y dominio son dos de las piezas más sensibles de una migración Microsoft 365.
El proveedor debería poder explicar:
- cómo se crearán los usuarios destino;
- cómo se hará identity mapping;
- qué pasará con UPN y Primary SMTP;
- cómo se tratarán usuarios sincronizados desde AD;
- qué pasará con Microsoft 365 Groups;
- cuándo se moverá el dominio;
- qué referencias deben eliminarse antes;
- cómo se cambiarán MX, SPF, DKIM y DMARC;
- qué aplicaciones utilizan el dominio;
- qué sucederá con el mail flow durante la coexistencia.
En tenant-to-tenant, Microsoft exige definir cómo se relacionan las identidades de origen y destino y cómo se gestionará la transferencia del dominio.
Preguntar “¿quién cambia el MX?” no es suficiente. La cuestión importante es quién ha validado antes que usuarios, aliases, grupos, aplicaciones SMTP y routing están preparados para que ese cambio no rompa el correo.
5 ¿Elige la herramienta después de entender el proyecto?
Una consultora debería seleccionar la herramienta en función del workload y los requisitos, y no forzar todo el proyecto para que encaje en una única plataforma.
Microsoft contempla actualmente tres aproximaciones:
- migración multi-workload coordinada;
- herramientas cross-tenant individuales;
- partner o third-party tools para escenarios complejos.
Un proveedor sólido debería conocer:
- Migration Orchestrator;
- Cross-Tenant Mailbox Migration;
- Cross-Tenant OneDrive Migration;
- Cross-Tenant SharePoint Migration;
- Microsoft Graph;
- PowerShell;
- herramientas especializadas cuando aportan valor.
No existe nada extraño en combinar métodos. En muchos proyectos es lo correcto.
Consulta también nuestra guía de herramientas y scripts para migrar tenants Microsoft 365.
6 ¿Incluye un piloto real antes del cutover?
Una migración relevante debería probarse con usuarios y datos representativos antes de ampliar el proceso al resto de la organización.
Un buen piloto debería cubrir diferentes casos:
- usuario estándar;
- buzón grande;
- shared mailbox o delegaciones;
- OneDrive con permisos;
- usuario perteneciente a Teams;
- usuario con aplicaciones;
- dispositivo administrado si Intune entra en alcance;
- casos especiales conocidos.
El piloto permite conocer:
- throughput real;
- errores;
- tiempos de cola;
- comportamiento de permisos;
- experiencia del usuario;
- problemas de Outlook, OneDrive y Teams;
- necesidades de soporte.
“La herramienta está probada” no sustituye al piloto. Lo que necesita probarse no es solamente el software: es la combinación concreta entre tu origen, tu destino, tus datos y tu configuración.
7 ¿Entiende coexistencia y dependencias entre workloads?
En proyectos por fases, origen y destino pueden tener que convivir durante semanas o meses.
Microsoft destaca expresamente la necesidad de planificar:
- mail routing entre tenants;
- free/busy;
- Teams federation;
- secuenciación de workloads.
Además existen dependencias:
- Teams depende de Exchange en determinados escenarios;
- OneDrive y SharePoint comparten modelos de permisos;
- Teams utiliza SharePoint para los archivos;
- Planner puede depender del Microsoft 365 Group;
- Power BI y Power Platform pueden depender de usuarios o grupos que cambian.
Una propuesta debería explicar el orden de las cargas y no simplemente presentar una lista de jobs.
Fuente oficial: Microsoft — Workload dependencies and coexistence.
8 ¿Existe un runbook de cutover y un plan de contingencia?
El día del cambio no debería depender de que el técnico recuerde los pasos. Debe existir un runbook con tareas, orden, responsables, validaciones y decisiones.
Un runbook debería contemplar:
- hora de inicio;
- freeze si existe;
- deltas finales;
- dominio;
- DNS;
- mail routing;
- licencias;
- renombrado de usuarios;
- validaciones;
- comunicación;
- soporte;
- criterios de go/no-go;
- contingencia.
¿Rollback significa simplemente volver atrás?
No siempre. Hay cargas cuya operación de migración puede no ser fácilmente reversible una vez completada.
Por eso un buen plan de contingencia debe indicar qué puede revertirse, qué puede posponerse y cómo se mantiene el servicio si una parte del cutover no termina.
9 ¿Cómo protege los accesos administrativos?
Una empresa externa no debería pedir Global Administrator permanente si las tareas pueden ejecutarse con roles más limitados o temporales.
Microsoft recomienda el principio de mínimo privilegio.
Para partners, GDAP permite:
- acceso granular;
- roles específicos;
- duración limitada;
- autorización explícita del cliente.
Microsoft Entra Privileged Identity Management permite además trabajar con:
- acceso Just-In-Time;
- duración limitada;
- aprobación;
- MFA para activación;
- auditoría de activaciones.
Esto no significa que una migración nunca necesite permisos elevados. Determinadas operaciones los requieren. La diferencia está en cómo, durante cuánto tiempo y quién los utiliza.
Pregunta imprescindible: “¿Qué roles administrativos necesitáis, quién tendrá acceso, durante cuánto tiempo y cuándo se retirarán?”
Fuentes oficiales: Microsoft — GDAP · Microsoft Entra PIM.
10 ¿Dónde pasan los datos y qué ocurre con RGPD y subencargados?
Si una consultora o una herramienta de migración procesa información de empleados, clientes o terceros, la protección de datos debe formar parte del proyecto y del contrato.
Para organizaciones sujetas al RGPD conviene aclarar:
- quién actúa como encargado del tratamiento;
- qué datos procesa;
- para qué finalidad;
- qué herramientas de terceros intervienen;
- qué subencargados existen;
- dónde puede tratarse la información;
- qué ocurre con los datos temporales;
- cuándo se eliminan;
- qué medidas de seguridad se aplican;
- cómo se gestionaría una incidencia.
La Comisión Europea recuerda que el tratamiento realizado por un encargado debe estar regulado por un contrato y que un subencargado necesita la autorización correspondiente del responsable.
“La herramienta está en la nube” no responde a una pregunta de compliance. Debes saber qué datos almacena, dónde, durante cuánto tiempo y en qué condiciones.
Fuente oficial: European Commission — GDPR controller and processor responsibilities.
11 ¿Cómo demostrará que la migración ha terminado correctamente?
“Job completed successfully” no debería ser el único criterio de aceptación.
La validación debe contemplar diferentes niveles.
Validación cuantitativa
- usuarios procesados;
- buzones;
- elementos;
- volumen;
- archivos;
- errores;
- elementos omitidos.
Validación funcional
- Outlook;
- mail flow;
- calendario;
- OneDrive;
- permisos;
- SharePoint;
- Teams;
- aplicaciones críticas;
- dispositivos si entran en alcance.
Validación del negocio
Algunos elementos deben ser aceptados por usuarios o propietarios del servicio.
Una migración puede tener un 100 % de jobs finalizados y seguir dejando una aplicación rota. Por eso los criterios de aceptación deben definirse antes del cutover.
12 ¿Las estimaciones de tiempo tienen fundamento técnico?
Desconfía tanto de quien dice que todo tardará meses sin medir nada como de quien promete migrar miles de usuarios en un fin de semana únicamente por el número de cuentas.
Microsoft indica que el timeline depende de:
- número de usuarios;
- tamaño de mailboxes;
- volumen OneDrive;
- volumen SharePoint;
- tipo de workload;
- batch size;
- Holds;
- red;
- capacidad de los servicios.
SharePoint y OneDrive aplican throttling y Exchange dispone igualmente de mecanismos de regulación del servicio.
Por tanto, el proveedor debería explicar:
- cómo ha calculado el plazo;
- qué throughput espera;
- qué medirá en el piloto;
- qué margen reserva;
- qué cargas se ejecutarán en paralelo;
- qué pasará si Microsoft aplica throttling.
13 ¿La propuesta contempla al usuario final y los dispositivos?
Una migración no termina cuando los datos llegan al destino. Termina cuando las personas pueden trabajar.
La propuesta debería aclarar qué ocurre con:
- Outlook;
- OneDrive Sync;
- Teams;
- MFA;
- favoritos y URLs;
- Office;
- móviles;
- Windows;
- Microsoft Intune;
- Entra Join;
- Autopilot;
- soporte en el primer inicio.
Si Intune está dentro del alcance, el proveedor debe saber que el cambio de tenant puede requerir reenrollment de dispositivos y que el procedimiento varía según plataforma y método de inscripción.
Pregunta útil: “El lunes después del cutover, ¿qué tiene que hacer exactamente cada usuario y quién le ayuda si algo falla?”
14 ¿Existe gobierno de proyecto, reporting y hypercare?
Una migración empresarial necesita gobierno además de técnicos.
La propuesta debería dejar claros:
- Project Manager;
- responsable técnico;
- contacto del cliente;
- RACI o responsabilidades;
- frecuencia de seguimiento;
- registro de riesgos;
- registro de decisiones;
- estado de cada lote;
- escalado de incidencias;
- ventana de soporte;
- hypercare;
- documentación final;
- retirada de permisos administrativos;
- cierre o decommission del origen cuando proceda.
¿Qué debería aparecer en el Statement of Work?
Al menos:
- alcance;
- exclusiones;
- responsabilidades del proveedor;
- responsabilidades del cliente;
- herramientas;
- licencias incluidas o no incluidas;
- criterios de aceptación;
- supuestos;
- ventanas de trabajo;
- soporte post-migración.
Una propuesta corta no es necesariamente mala. Lo preocupante es una propuesta ambigua en la que nadie puede determinar después si Planner, chats, permisos externos o dispositivos estaban incluidos.
15 ¿Puede demostrar competencias y proyectos comparables?
Certificaciones, designaciones de partner y referencias deberían utilizarse como evidencia complementaria, no como sustituto de una metodología sólida.
Comprueba:
- relación real con Microsoft;
- designaciones actuales;
- certificaciones del equipo asignado;
- experiencia con Exchange;
- experiencia con SharePoint y Teams;
- experiencia con Entra ID;
- experiencia con Intune si entra en alcance;
- herramientas que domina;
- proyectos de volumen similar;
- proyectos del mismo tipo: M&A, carve-out, consolidación, Google → M365, Exchange → M365, etc.
Pregunta mejor que “¿cuántas migraciones habéis hecho?”
Pregunta:
“¿Habéis realizado recientemente una migración con un alcance parecido al nuestro y cuáles fueron las principales dificultades?”
La respuesta suele ser mucho más útil que una cifra global.
Un buen proveedor debería poder hablar de problemas reales: throttling, identity matching, permisos, calendarios, dominios, Teams, archivos conflictivos, usuarios VIP, aplicaciones o cutovers complicados. Una migración sin excepciones existe principalmente en las presentaciones comerciales.
MSAdvance publica, por ejemplo, un caso práctico de migración tenant-to-tenant en el que explica metodología, coexistencia, oleadas y validaciones.
10 señales de alarma al elegir una empresa de migración Microsoft 365
Si aparecen varias de estas señales en una propuesta, conviene revisar el proyecto antes de adjudicarlo.
- Presupuesta únicamente por usuarios sin preguntar por workloads ni volumen.
- Promete migrar “todo Microsoft 365” sin detallar limitaciones.
- No incluye assessment ni piloto.
- Pide Global Administrator permanente sin justificarlo.
- No explica dónde procesa los datos la herramienta utilizada.
- No diferencia SharePoint de Teams.
- No tiene una respuesta clara sobre identity mapping y dominio.
- No define cómo validará el resultado.
- Promete “cero riesgo”, “cero pérdida” o velocidades garantizadas sin condiciones.
- El proyecto termina exactamente en el momento del cutover sin hypercare ni cierre.
20 preguntas que deberías hacer a una empresa de migración Microsoft 365
Estas preguntas funcionan especialmente bien en una RFP o reunión técnica:
- ¿Qué necesitáis inventariar antes de cerrar el alcance?
- ¿Qué workloads consideráis incluidos?
- ¿Qué elementos no tienen una migración 1:1?
- ¿Qué herramienta proponéis para cada workload y por qué?
- ¿Qué capacidades nativas de Microsoft utilizaréis?
- ¿Cómo prepararéis identity mapping?
- ¿Cómo se realizará el cambio de dominio?
- ¿Cómo funcionará el correo durante la coexistencia?
- ¿Cómo se tratarán Teams y SharePoint?
- ¿Cómo se migrarán o recrearán Planner, Power BI o Power Platform si existen?
- ¿Qué usuarios formarán parte del piloto?
- ¿Cómo mediréis throughput?
- ¿Qué accesos administrativos necesitáis?
- ¿Utilizáis PIM o GDAP cuando aplica?
- ¿Qué información almacena la herramienta de migración?
- ¿Qué ocurre con colaboradores externos y permisos?
- ¿Cuál es el criterio de go/no-go?
- ¿Cómo se validará cada workload?
- ¿Qué soporte habrá después del cutover?
- ¿Podéis mostrar un proyecto comparable?
¿Cómo comparar presupuestos de migración Microsoft 365?
No compares el total hasta comprobar que las propuestas incluyen exactamente las mismas cargas y responsabilidades.
Dos presupuestos pueden decir “migración de 500 usuarios” y estar ofreciendo proyectos completamente distintos.
| Elemento | Proveedor A | Proveedor B |
|---|---|---|
| Exchange User Mailboxes | ¿Incluido? | ¿Incluido? |
| Shared Mailboxes | ¿Incluido? | ¿Incluido? |
| Online Archives | ¿Incluido? | ¿Incluido? |
| OneDrive | ¿Incluido? | ¿Incluido? |
| SharePoint | ¿Por sitio / volumen? | ¿Por sitio / volumen? |
| Teams | ¿Qué componentes? | ¿Qué componentes? |
| Chats | ¿Incluidos? | ¿Incluidos? |
| Planner | ¿Incluido? | ¿Incluido? |
| Power BI | ¿Incluido? | ¿Incluido? |
| Intune | ¿Políticas? ¿Dispositivos? | ¿Políticas? ¿Dispositivos? |
| Identidad y Groups | ¿Incluido? | ¿Incluido? |
| Dominio y DNS | ¿Incluido? | ¿Incluido? |
| Piloto | ¿Incluido? | ¿Incluido? |
| Herramientas | ¿Licencia incluida? | ¿Licencia incluida? |
| Hypercare | ¿Cuánto? | ¿Cuánto? |
El presupuesto aparentemente más caro puede terminar siendo más económico si incluye workloads, licencias, pilotaje, validación y soporte que otra propuesta ha dejado fuera.
¿Cómo plantea MSAdvance una migración Microsoft 365?
En MSAdvance intentamos que la herramienta sea una consecuencia del assessment y no el punto de partida.
La metodología se divide en:
- Assessment: inventario de usuarios, datos, workloads y dependencias.
- Diseño: tenant destino, identidad, colaboración, seguridad y coexistencia.
- Selección tecnológica: capacidades nativas de Microsoft, herramientas especializadas, Graph o PowerShell según el alcance.
- Piloto: comprobación del proceso con usuarios representativos.
- Preparación: identidades, licencias, grupos, DNS y destinos.
- Migración: pre-stage y deltas cuando la tecnología lo permite.
- Cutover: ejecución del runbook y cambios finales.
- Validación: revisión técnica y funcional.
- Hypercare: soporte posterior y resolución de excepciones.
- Cierre: documentación y retirada controlada de accesos y origen cuando corresponda.
Para proyectos tenant-to-tenant puedes consultar nuestro servicio de migración entre tenants Microsoft 365 y nuestra guía técnica tenant-to-tenant.
¿Estás comparando proveedores?
Si nos envías el alcance o una propuesta que estés evaluando, podemos preparar nuestra alternativa con los workloads, metodología, herramientas, supuestos y responsabilidades claramente definidos para que puedas comparar en igualdad de condiciones.
Preguntas frecuentes sobre cómo elegir una empresa de migración Microsoft 365
¿Cómo elegir una empresa para una migración Microsoft 365?
Compara assessment, experiencia por workload, arquitectura, identidad, herramientas, piloto, coexistencia, cutover, seguridad administrativa, RGPD, validación, estimación de tiempos, soporte a usuarios, gobierno y referencias. El precio y la condición de Microsoft Partner deberían utilizarse como criterios adicionales, no como los únicos factores.
¿Es importante que la empresa sea Microsoft Partner?
Sí, es una señal positiva. Microsoft utiliza designaciones como Solutions Partner for Modern Work para reconocer capacidades en rendimiento, capacitación y éxito con clientes. Sin embargo, conviene comprobar también que el equipo asignado tenga experiencia específica en el tipo y tamaño de migración que necesitas.
¿Qué certificaciones debería tener una empresa de migración Microsoft 365?
Depende del alcance. Son especialmente relevantes competencias en Microsoft 365, Exchange Online, Microsoft Entra ID, SharePoint, Teams, seguridad e Intune cuando estas cargas forman parte del proyecto. Más importante que el número total de certificaciones es que las posean los técnicos que realmente participarán en la migración.
¿Una empresa de migración debería realizar un assessment?
Sí. Debe inventariar usuarios, buzones, OneDrive, SharePoint, Teams, grupos, dominios, dispositivos y otras dependencias antes de cerrar la estrategia. El número de usuarios por sí solo no describe correctamente la complejidad de una migración.
¿Es obligatorio hacer un piloto de migración?
No existe una obligación universal, pero para una migración relevante es una práctica muy recomendable. Permite comprobar rendimiento, mapping, permisos, experiencia de usuario y errores reales antes de ampliar el procedimiento a toda la organización.
¿Qué herramientas debería utilizar una empresa de migración?
No existe una herramienta correcta para todos los proyectos. Microsoft ofrece capacidades nativas para Exchange, OneDrive, SharePoint y otros escenarios; herramientas especializadas pueden aportar coexistencia, precargas, reporting o cobertura adicional; y Microsoft Graph y PowerShell permiten automatizar configuraciones específicas. La herramienta debe elegirse según el alcance.
¿Es mejor utilizar herramientas nativas de Microsoft?
Son una excelente opción cuando su alcance encaja con los requisitos. En otros proyectos puede ser más eficiente combinarlas con herramientas especializadas. Microsoft contempla expresamente el uso de partners y herramientas de terceros para migraciones complejas o cuando los recursos internos son limitados.
¿La consultora necesita Global Administrator?
Determinadas tareas pueden necesitar permisos elevados, pero no debería mantenerse un Global Administrator permanente sin necesidad. Microsoft recomienda el principio de mínimo privilegio y existen mecanismos como GDAP y PIM para utilizar accesos más granulares o temporales cuando el escenario lo permite.
¿Qué es GDAP y por qué importa al contratar un partner?
GDAP son los Granular Delegated Admin Privileges de Microsoft. Permiten que un partner reciba roles administrativos concretos y limitados en el tiempo en lugar de tener acceso global permanente. Es una forma de reducir el riesgo administrativo y aplicar mínimo privilegio.
¿Qué debe incluir un presupuesto de migración Microsoft 365?
Debería identificar workloads incluidos, cantidades, herramientas, licencias, tareas de identidad y DNS, piloto, migración, cutover, validación, soporte posterior, exclusiones, responsabilidades del cliente y supuestos utilizados para calcular el precio.
¿Cómo comparar dos presupuestos de migración Microsoft 365?
Primero normaliza el alcance. Comprueba que ambos incluyen los mismos buzones, shared mailboxes, OneDrive, sitios SharePoint, Teams, chats, grupos, Planner, Power BI, Intune, identidad, dominio, herramientas y soporte. Solo después tiene sentido comparar el importe total.
¿La empresa más barata suele ser peor?
No necesariamente. Una consultora puede ser más eficiente o tener una estructura de costes diferente. El problema aparece cuando el menor precio procede de haber excluido workloads, herramientas, validación o soporte que serán necesarios posteriormente.
¿Qué debería preguntar sobre el cutover?
Pregunta qué ocurre durante la ventana final, qué datos estarán ya migrados, quién cambia el dominio y DNS, cómo se valida mail flow, cuál es el criterio de go/no-go, qué acciones son reversibles y qué procedimiento existe si una parte no termina a tiempo.
¿Una migración Microsoft 365 puede realizarse sin downtime?
El objetivo debería ser minimizar la interrupción, no prometer cero downtime de forma absoluta sin conocer el entorno. Precargas, coexistencia, deltas, pilotos y cutovers fuera de horario permiten reducir mucho el impacto, pero existen operaciones sensibles que dependen del escenario.
¿Cómo se comprueba que no faltan datos después de una migración?
Mediante validaciones cuantitativas y funcionales. Deben revisarse elementos, volumen, errores y objetos omitidos y, además, probar correo, calendario, permisos, OneDrive, SharePoint, Teams y aplicaciones relevantes. El criterio de aceptación debería estar acordado antes del cutover.
¿Qué soporte debería ofrecer la empresa después de migrar?
Debería existir un periodo de hypercare con responsables, horarios y mecanismo de escalado claros. También conviene incluir documentación final, remediación de excepciones, retirada de accesos administrativos y criterios para cerrar o retirar el entorno origen.
¿Qué ocurre con RGPD durante una migración Microsoft 365?
Si el proveedor o las herramientas utilizadas procesan datos personales por cuenta de la organización, deben revisarse las obligaciones aplicables como encargado del tratamiento, subencargados, medidas de seguridad, instrucciones de tratamiento y eliminación de datos después de finalizar el servicio.
¿Cómo saber si una empresa tiene experiencia real?
Pide ejemplos de proyectos comparables en origen, tamaño y workloads, y pregunta qué problemas encontraron y cómo los resolvieron. También puedes revisar certificaciones, designaciones de partner, casos publicados y experiencia de los técnicos que estarán asignados realmente al proyecto.
¿Cuántas empresas conviene comparar?
Para un proyecto relevante suele ser suficiente comparar varias propuestas realmente cualificadas utilizando el mismo alcance y las mismas preguntas técnicas. Comparar muchas ofertas mal normalizadas aporta menos información que comparar tres propuestas con un Statement of Work equivalente.
¿Puede MSAdvance realizar una migración Microsoft 365 completa?
MSAdvance trabaja proyectos de migración Microsoft 365 desde assessment y diseño hasta ejecución, cutover, validación e hypercare, combinando capacidades nativas de Microsoft, herramientas especializadas, Microsoft Graph y PowerShell según el escenario y los workloads incluidos.
Fuentes oficiales para evaluar una empresa de migración Microsoft 365
- Microsoft — Plan a Microsoft 365 tenant-to-tenant migration — identidad, dependencias, coexistencia, herramientas y planificación.
- Microsoft 365 Migration documentation — documentación general de las capacidades de migración.
- Solutions Partner for Modern Work — criterios actuales de la designación.
- Microsoft GDAP — acceso administrativo granular y temporal para partners.
- Microsoft Entra Privileged Identity Management — mínimo privilegio y acceso Just-In-Time.
- Microsoft FastTrack Data Migration — alcance, responsabilidades y consideraciones de migración.
- European Commission — GDPR controller and processor responsibilities.
Guías relacionadas de MSAdvance
Conclusión: qué empresa elegir para una migración Microsoft 365
La mejor empresa para una migración Microsoft 365 no es necesariamente la que presenta el precio por usuario más bajo, utiliza la herramienta más conocida o acumula más logotipos en su página web.
Es la que puede responder de forma concreta a estas preguntas:
- ¿qué hay realmente en mi entorno?
- ¿qué se puede migrar y qué no?
- ¿cómo quedará el destino?
- ¿qué herramientas se utilizarán y por qué?
- ¿cómo se protegerán los accesos administrativos?
- ¿cómo convivirán origen y destino?
- ¿qué ocurrirá durante el cutover?
- ¿cómo se validará el resultado?
- ¿qué verá el usuario el lunes siguiente?
- ¿qué soporte habrá si aparece una excepción?
Certificaciones y designaciones Microsoft ayudan a filtrar. Las referencias ayudan a ganar confianza. Pero el assessment, la metodología, el control de accesos, la claridad del alcance y los criterios de validación son los que reducen realmente el riesgo del proyecto.
Por eso la comparación debería hacerse sobre un alcance normalizado y utilizando criterios técnicos como los 15 de esta guía.
¿Quieres comparar nuestra propuesta con otras consultoras?
Cuéntanos tu escenario y el número de usuarios, buzones, OneDrive, SharePoint, Teams, dominios y dispositivos. Prepararemos el alcance indicando qué se incluye, qué método proponemos y qué dependencias deben revisarse antes del cutover.
