Migración a Microsoft 365 y Azure: cómo planificar una transición cloud de principio a fin

Una migración a Microsoft 365 y Azure puede transformar de forma profunda la infraestructura y la forma de trabajar de una empresa, pero conviene empezar aclarando algo importante: no estamos hablando de una única migración.

Mover buzones a Exchange Online, trasladar archivos a SharePoint, consolidar dos tenants de Microsoft 365, administrar dispositivos con Intune o llevar servidores y aplicaciones a Azure son proyectos diferentes. Pueden formar parte de una misma estrategia cloud, pero cada uno tiene sus propias herramientas, dependencias, riesgos y criterios de éxito.

Por eso una empresa que quiere “migrar a Microsoft” debería evitar comenzar preguntando:

“¿Qué herramienta utilizamos para moverlo?”

La primera pregunta debería ser:

“¿Qué tenemos actualmente, qué queremos conservar, qué debemos cambiar y cómo queremos que funcione el entorno después de la migración?”

Esta diferencia es importante.

Una migración bien planteada no copia automáticamente todos los problemas del entorno actual al cloud. Puede aprovecharse para ordenar identidades, retirar aplicaciones obsoletas, reorganizar información, reducir permisos innecesarios, mejorar seguridad, simplificar el puesto de trabajo y establecer un modelo de gobierno más sólido.

En Azure ocurre exactamente lo mismo. Llevar una máquina virtual antigua a una VM de Azure puede resolver el problema de un datacenter que debe cerrarse, pero no necesariamente moderniza la aplicación. En otros casos puede ser mejor pasar una base de datos a un servicio gestionado, sustituir una aplicación por SaaS, refactorizar código o incluso retirar completamente un sistema que ya no aporta valor.

En esta guía explicamos cómo abordar una migración empresarial a Microsoft 365 y Azure en 2026, desde el discovery inicial hasta la estabilización posterior. Veremos correo, OneDrive, SharePoint, Teams, identidad, tenant-to-tenant, Azure Migrate, las ocho estrategias de migración de Microsoft, Landing Zones, seguridad, FinOps, Copilot, adopción de usuarios y las decisiones que conviene cerrar antes de mover el primer dato.

Índice

1. Qué significa realmente migrar a Microsoft 365 y Azure
2. Microsoft 365 y Azure: qué resuelve cada plataforma
3. Por qué migran las empresas
4. El discovery antes de migrar
5. Qué podemos migrar a Microsoft 365
6. Migración de correo
7. SharePoint, OneDrive y archivos
8. Microsoft Teams
9. Identidad, Entra ID y dispositivos
10. Migraciones tenant-to-tenant
11. Herramientas nativas cross-tenant en 2026
12. Coexistencia durante la migración
13. Qué significa migrar a Azure
14. Las ocho estrategias de migración de Azure
15. Azure Migrate
16. Dependencias de aplicaciones
17. Cloud Adoption Framework
18. Azure Landing Zone
19. Seguridad desde el diseño
20. FinOps y control de costes
21. Prepararse para Microsoft 365 Copilot
22. Adopción y cambio organizativo
23. Qué herramienta utilizar
24. Fases de una migración
25. Cómo validar una migración
26. Rollback y planes de contingencia
27. Operación después de la migración
28. Métricas de éxito
29. Errores frecuentes
30. Checklist completo
31. Preguntas frecuentes
32. Documentación oficial

Qué significa realmente migrar a Microsoft 365 y Azure

El término migración cloud agrupa proyectos muy distintos.

Podemos estar hablando de una empresa que actualmente tiene diez cuentas de correo IMAP y quiere utilizar Exchange Online, pero también de un grupo empresarial con varios tenants, cientos de servidores, aplicaciones internas, directorios híbridos y varios terabytes de información.

En ambos casos se habla de “migración”, aunque técnicamente tienen poco en común.

Una estrategia cloud puede contener varios proyectos

Por ejemplo:

Una organización podría:

1. migrar correo a Exchange Online;
2. trasladar carpetas departamentales a SharePoint;
3. introducir Teams;
4. incorporar equipos a Intune;
5. mantener temporalmente Active Directory local;
6. migrar varios servidores a Azure;
7. modernizar solo determinadas aplicaciones;
8. retirar el datacenter seis meses después.

Todo forma parte de una misma transformación, pero no debe ejecutarse como un único bloque técnico.

Microsoft 365 y Azure: qué resuelve cada plataforma

Aunque pertenecen al ecosistema Microsoft Cloud, Microsoft 365 y Azure tienen objetivos diferentes.

La identidad conecta ambos mundos

Microsoft Entra ID se convierte en una pieza transversal.

Puede controlar acceso tanto a:

Exchange + Teams + SharePoint + OneDrive

como a:

Azure Portal + aplicaciones empresariales + recursos cloud.

Por eso el diseño de identidad debería realizarse antes de tratar Microsoft 365 y Azure como dos proyectos totalmente independientes.

Por qué las empresas migran a Microsoft 365 y Azure

No existe una única razón.

En muchos proyectos encontramos varias al mismo tiempo.

No convertir “cloud” en el objetivo

La nube es una arquitectura y un modelo operativo.

El objetivo debería expresarse en términos empresariales.

Por ejemplo:

cerrar el datacenter antes del 31 de diciembre, reducir incidencias del puesto de trabajo, conseguir un RTO de cuatro horas, consolidar tres empresas después de una adquisición o eliminar una plataforma sin soporte.

Esos objetivos permiten decidir después qué arquitectura tiene sentido.

El discovery: la fase que determina gran parte del éxito

Los problemas de migración rara vez aparecen porque el técnico desconocía cómo pulsar el botón de migrar.

Aparecen porque descubrimos demasiado tarde algo que no estaba inventariado.

En Microsoft 365

Debemos conocer, entre otros:

En Azure o infraestructura

No basta con inventariar servidores.

Necesitamos identificar:

• CPU y memoria;
• almacenamiento e IOPS;
• sistemas operativos;
• bases de datos;
• aplicaciones;
• puertos;
• dependencias;
• conectividad;
• RTO/RPO;
• licenciamiento;
• integraciones;
• ventanas de mantenimiento;
• propietario técnico;
• propietario de negocio.

Una CMDB incompleta no debería considerarse inventario definitivo

Conviene contrastar información documental con descubrimiento técnico.

Un servidor que no aparece en una hoja Excel puede seguir recibiendo conexiones todos los días.

Qué podemos migrar a Microsoft 365

El destino no debería elegirse solo por similitud técnica

Por ejemplo, no toda carpeta de un servidor debe convertirse automáticamente en una biblioteca SharePoint con exactamente la misma estructura.

Primero debemos identificar la naturaleza del contenido.

Migración de correo a Microsoft 365

Exchange Online es uno de los puntos de entrada más habituales a Microsoft 365.

El método de migración depende fundamentalmente del origen.

Antes de mover buzones

Revisar:

SMTP primario + aliases + shared mailboxes + grupos + delegaciones + permisos + calendarios + reglas + aplicaciones SMTP + tamaño + archivado + retención.

El DNS forma parte del proyecto

Los cambios de correo pueden afectar:

• MX;
• SPF;
• DKIM;
• DMARC;
• Autodiscover;
• aplicaciones que envían correo.

No confundir migrar el buzón con configurar todos los dispositivos

El hecho de que el contenido esté correctamente en Exchange Online no significa necesariamente que cada dispositivo personal, aplicación o cliente de correo quede automáticamente reconfigurado.

El soporte de endpoint debe definirse expresamente dentro del alcance del proyecto.

Referencia oficial: Microsoft – Ways to migrate mailboxes to Microsoft 365.

Migrar archivos a SharePoint y OneDrive

En una migración documental, la velocidad de copia suele ser solo una parte del problema.

Antes debemos revisar la información.

Qué analizar

SharePoint no es un file server con navegador

Podemos mantener cierta estructura, pero conviene aprovechar funcionalidades como:

sitios, bibliotecas, metadata, permisos mediante grupos, versionado, coautoría y búsqueda.

Aplicaciones que utilizan rutas UNC

Si un programa espera encontrar:

\\SERVIDOR\Departamento\archivo.xml

mover ese archivo a SharePoint no convierte automáticamente la aplicación en compatible con una URL cloud.

Las dependencias de aplicaciones deben identificarse antes de retirar el file server.

Microsoft Teams: migrar colaboración es más complejo que copiar archivos

Microsoft Teams combina diferentes servicios.

Un Team puede depender de:

Microsoft 365 Groups + SharePoint + Exchange + Teams + OneDrive + aplicaciones.

Por eso debemos definir el alcance

No prometer una migración 1:1 sin validar la herramienta

Especialmente en:

chats + apps + bots + Loop + tabs + canales especiales + reuniones.

Identidad y dispositivos: la migración que el usuario sí nota

Podemos copiar todos los datos correctamente y aun así tener una mala experiencia si la identidad no está bien diseñada.

Debemos decidir

• UPN objetivo;
• dominio;
• identidades cloud-only o híbridas;
• Microsoft Entra Connect/Cloud Sync si aplica;
• MFA;
• Conditional Access;
• roles administrativos;
• cuentas break-glass;
• SSO de aplicaciones.

Dispositivos

Una migración de tenant puede afectar a:

Entra Join + Intune enrollment + Company Portal + certificados + Wi-Fi + VPN + aplicaciones + perfiles.

Cloud migration y endpoint migration pueden ser alcances distintos

En proyectos con muchos usuarios conviene especificar expresamente si se incluye:

reconfiguración del equipo + Outlook + OneDrive Sync + Teams + inscripción Intune + móviles.

De lo contrario, pueden existir expectativas diferentes entre cliente y equipo técnico.

Migraciones tenant-to-tenant de Microsoft 365

Las migraciones entre tenants aparecen principalmente en:

• fusiones;
• adquisiciones;
• carve-outs;
• divestitures;
• consolidaciones;
• reorganizaciones internas.

Por qué son especialmente sensibles

En una migración desde otro sistema hacia Microsoft 365, el destino normalmente no comparte las mismas restricciones de identidad.

En tenant-to-tenant sí.

Tenemos dos entornos Microsoft 365 independientes que pueden contener:

usuarios + Exchange + SharePoint + Teams + dominios + seguridad + aplicaciones.

El dominio corporativo es uno de los principales puntos de corte

Un dominio personalizado no puede verificarse simultáneamente en dos tenants.

Eso obliga a preparar cuidadosamente:

UPN + SMTP + aliases + grupos + MailUsers + DNS + cutover.

También necesitamos coexistencia

Si migramos por lotes, usuarios de ambos tenants tienen que seguir colaborando durante un tiempo.

Referencia oficial: Microsoft – Plan a Microsoft 365 tenant-to-tenant migration.

Herramientas nativas cross-tenant de Microsoft en 2026

Microsoft ha ampliado considerablemente su propuesta nativa.

Cross-tenant mailbox migration

Permite mover buzones Exchange Online entre tenants.

El usuario objetivo debe prepararse correctamente y existe un modelo específico de identity mapping.

Cross-tenant OneDrive migration

Permite mover un OneDrive de un tenant a otro.

Hay una particularidad fundamental:

es un movimiento one-and-done.

No permite el patrón tradicional de:

premigración + delta + delta final.

Después del movimiento se deja un redirect en origen para los enlaces compatibles.

Cross-tenant SharePoint migration

Microsoft también dispone actualmente de una capacidad para trasladar sitios SharePoint entre tenants mediante SharePoint Online PowerShell.

Entre sus requisitos actuales se encuentra:

• identity mapping;
• precreación de usuarios/grupos;
• destino compatible;
• no crear previamente el sitio objetivo;
• respetar límites de volumen e items;
• revisar workflows, apps y Power Platform asociados.

El movimiento SharePoint tampoco permite deltas

Al igual que OneDrive, Microsoft lo define como un movimiento único.

Teams conectado a SharePoint

Podemos mover el sitio SharePoint de un Team.

Eso no significa migrar el Team completo.

La estructura, canales y contenido específico de Teams deben tratarse mediante el mecanismo correspondiente.

Migration Orchestrator

Microsoft dispone además de un flujo orquestado para coordinar determinadas cargas de trabajo de usuario.

El Orchestrator mueve contenido, no identidades

La preparación de los usuarios del tenant destino continúa siendo responsabilidad del proyecto.

Referencias oficiales:

• Microsoft – Migration Orchestrator
• Microsoft – Cross-tenant mailbox migration
• Microsoft – Cross-tenant OneDrive migration
• Microsoft – Cross-tenant SharePoint migration

Coexistencia durante una migración por fases

En proyectos pequeños podemos realizar un único cutover.

En proyectos grandes suele ser necesario convivir durante días, semanas o meses.

Qué puede necesitar coexistir

La coexistencia debe tener fecha de caducidad

Si el estado objetivo es un único tenant, mantener durante años:

routing + invitados + identidades duplicadas + permisos cruzados + licencias duplicadas

añade coste y complejidad innecesarios.

Qué significa migrar a Azure

Migrar a Azure no significa necesariamente convertir todos nuestros servidores en Azure Virtual Machines.

Ese es solo uno de los posibles destinos.

Ejemplos

No decidir el destino únicamente por compatibilidad

También debemos considerar:

operación + disponibilidad + seguridad + coste + escalabilidad + skills + lifecycle.

Las ocho estrategias de migración a Azure

Microsoft utiliza actualmente un modelo más completo de racionalización denominado habitualmente las 8 Rs.

Retire es una estrategia, no un fracaso

Una migración es una oportunidad excelente para descubrir servidores que llevan años consumiendo:

licencias + backup + antivirus + almacenamiento + administración

sin aportar valor real.

Retain también puede ser correcto

No todo debe migrarse inmediatamente.

Una aplicación industrial crítica que funciona correctamente y no tiene un driver de negocio para cambiar puede permanecer temporalmente on-premises mientras otros workloads se modernizan.

Rehost no arregla una mala aplicación

Si un servidor ya tiene problemas de rendimiento, disponibilidad o arquitectura, moverlo exactamente igual a Azure puede trasladar el problema y añadir una factura cloud.

Replatform suele ser un buen punto intermedio

Permite reducir carga operativa sin acometer necesariamente una reescritura completa.

Referencia oficial: Microsoft – Select your cloud migration strategy.

Azure Migrate: descubrir y evaluar antes de mover

Azure Migrate es el conjunto de herramientas de Microsoft orientado al descubrimiento, evaluación y migración hacia Azure.

Una assessment moderna no responde solo “qué VM necesito”

Microsoft evalúa aspectos como:

Rightsizing es especialmente importante

No deberíamos asumir que:

VM on-premises 8 vCPU / 32 GB → Azure VM 8 vCPU / 32 GB

es necesariamente correcto.

Un servidor sobredimensionado on-premises seguirá sobredimensionado si copiamos exactamente la misma configuración.

Utilizar rendimiento real

Recoger métricas durante un periodo representativo ayuda a conocer:

CPU + memoria + almacenamiento + IOPS + red.

Dependency analysis

Antes de mover workloads es fundamental conocer qué sistemas se comunican entre sí.

Esto ayuda a crear grupos de migración coherentes.

Referencia oficial: Microsoft – Azure Migrate.

Las dependencias son más importantes que el número de servidores

Imaginemos que tenemos:

APP01 → SQL01 → FILE01 → LDAP01 → API externa.

Si migramos APP01 a Azure pero dejamos SQL01 on-premises con una conectividad insuficiente, la aplicación puede funcionar mucho peor aunque el servidor se haya migrado correctamente.

Por eso agrupamos por workload

Un workload puede incluir:

• front-end;
• API;
• database;
• file storage;
• identity;
• integraciones;
• monitoring;
• backup;
• networking.

La unidad de migración no siempre debería ser “un servidor”

Puede ser:

una aplicación de negocio completa.

Cloud Adoption Framework: ordenar la adopción de Azure

Microsoft ha actualizado el Cloud Adoption Framework para separar claramente varias áreas del proceso de adopción.

1. Foundation

2. Operational standards

3. Workload onboarding

Gobierno y seguridad no deberían empezar después de la migración

Deberían existir antes de incorporar el primer workload productivo.

Referencia oficial: Microsoft – Cloud Adoption Framework.

Azure Landing Zone: construir la base antes de llenar Azure de recursos

Una Azure Landing Zone proporciona una arquitectura repetible para desplegar y gobernar Azure a escala.

Microsoft diferencia dos componentes

Una Landing Zone puede abordar

• management groups;
• subscriptions;
• Azure Policy;
• RBAC;
• networking;
• connectivity;
• security;
• logging;
• monitoring;
• cost management;
• naming/tagging;
• shared services.

Error habitual

Crear la primera VM en una suscripción y pensar:

“ya ordenaremos Azure más adelante”.

Cuando aparecen cincuenta subscriptions y cientos de recursos, corregir la estructura cuesta mucho más.

Referencia oficial: Microsoft – Azure Landing Zones.

Seguridad desde el diseño

La migración ofrece la oportunidad de mejorar la seguridad, pero también puede ampliar la superficie de ataque si habilitamos cloud sin definir controles.

Microsoft 365

Azure

No desplegar todas las restricciones el día del cutover

Seguridad desde el diseño no significa activar veinte políticas nuevas cinco minutos después de mover a los usuarios.

Necesitamos:

design → pilot → report/monitor → remediate → enforce.

FinOps: controlar el valor del cloud, no solo la factura

Azure utiliza un modelo económico muy diferente al hardware tradicional.

Podemos crear recursos en minutos, pero eso también significa que podemos crear costes en minutos.

FinOps no significa simplemente “reducir gasto”

Su objetivo es maximizar el valor empresarial que obtenemos del cloud.

Un workload barato pero lento, inseguro o poco fiable no es necesariamente una buena optimización.

Microsoft estructura FinOps alrededor de colaboración

Deben participar:

tecnología + finanzas + negocio.

Tres etapas operativas

Primer nivel de gobierno económico

Como mínimo:

• naming coherente;
• tags;
• cost allocation;
• budgets;
• alerts;
• owners;
• anomaly review;
• rightsizing;
• apagado de recursos temporales;
• Azure Advisor.

No comprar reservas antes de optimizar

Este orden es importante.

Microsoft recomienda:

right-size primero → eliminar desperdicio → analizar consumo estable → después valorar commitments.

Reservations vs Savings Plans

Azure Hybrid Benefit

Si la organización dispone de determinados derechos de licencia Windows Server o SQL Server, debe comprobarse si puede aprovechar Azure Hybrid Benefit.

La optimización es continua

Un dimensionamiento correcto el día 1 puede dejar de ser correcto seis meses después.

Referencias oficiales:

• Microsoft – What is FinOps?
• Microsoft – FinOps Framework
• Microsoft – Cost Management

La migración como preparación para Microsoft 365 Copilot

Migrar información a Microsoft 365 puede crear una base excelente para Microsoft 365 Copilot.

Pero también puede hacer visibles problemas históricos de gobierno.

Copilot respeta los permisos existentes

Esto significa que no concede automáticamente acceso a documentos que el usuario no podía consultar.

Sin embargo, si el usuario ya tiene acceso a información que realmente no debería tener, Copilot puede facilitar que esa información aparezca dentro de su contexto de trabajo.

El problema real es oversharing

Por eso antes de desplegar Copilot conviene revisar:

Content Management Assessment

Microsoft está incorporando capacidades específicas dentro de SharePoint Advanced Management para ayudar a evaluar:

oversharing + sitios inactivos + sitios sin propietario + readiness para Copilot y agentes.

Migrar todo “por si acaso” tiene consecuencias

Si copiamos veinte años de contenido sin clasificar y con permisos históricos, estamos creando más superficie de información que después habrá que gobernar.

Referencia oficial: Microsoft – Prepare SharePoint for Microsoft 365 Copilot and agents.

Migrar datos no significa que los usuarios hayan adoptado Microsoft 365

Una migración puede ser técnicamente perfecta y aun así obtener un resultado pobre.

Por ejemplo, podemos migrar una carpeta departamental a SharePoint y que los usuarios continúen:

descargando documentos → enviándolos por email → creando duplicados.

En ese caso hemos cambiado la plataforma, no la forma de trabajar.

Formación práctica

No hace falta convertir a cada usuario en administrador de Microsoft 365.

Hay que enseñarle lo que necesita para su función.

Comunicación por fases

Un usuario debería conocer:

qué cambia + cuándo + qué debe hacer + dónde pedir ayuda.

Qué herramienta utilizar para cada migración

No existe una herramienta que sea la mejor para cualquier proyecto.

Native vs third-party

Las herramientas nativas pueden ser una buena opción cuando:

el workload está soportado + el modelo de cutover encaja + no necesitamos capacidades adicionales.

Una herramienta especializada puede tener sentido cuando necesitamos:

más reporting + coexistencia avanzada + deltas + remapping + automatización + soporte de contenido que no cubre la herramienta nativa.

Elegir herramienta después del assessment

No al revés.

Fases recomendadas de una migración cloud

Fase 1: objetivos

Definir:

qué problema estamos resolviendo + fecha objetivo + restricciones + criterios de éxito.

Fase 2: discovery

Inventariar identidad, datos, aplicaciones, servidores, dependencias y seguridad.

Fase 3: assessment

Clasificar:

migrate + modernize + retain + retire + replace.

Fase 4: arquitectura objetivo

Diseñar:

• Microsoft 365;
• Entra;
• SharePoint;
• Teams;
• Intune;
• Azure Landing Zone;
• red;
• seguridad;
• monitorización;
• FinOps.

Fase 5: preparación

Crear:

identidades + licencias + networking + subscriptions + policies + herramientas + permisos.

Fase 6: piloto

Seleccionar usuarios y workloads representativos.

No elegir exclusivamente los más fáciles.

Fase 7: premigración

Cuando la herramienta lo permita, trasladar una parte importante de los datos antes del cutover.

Fase 8: oleadas

Agrupar usuarios o aplicaciones según:

departamento + país + dependencia + criticidad + calendario.

Fase 9: cutover

Realizar cambios definitivos.

Por ejemplo:

• DNS;
• dominio;
• mail routing;
• identidad;
• aplicaciones;
• network route;
• failover.

Fase 10: validación

Validar contenido, funcionalidad, permisos y experiencia.

Fase 11: estabilización

Resolver incidencias y observar el entorno durante el periodo acordado.

Fase 12: decommission

Retirar:

servidores + licencias + conectores + cuentas + reglas temporales + tenants o sistemas de origen

cuando sea seguro hacerlo.

Cómo validar correctamente una migración

“El job aparece como Completed” no debería ser el único criterio de éxito.

Validación cuantitativa

Validación técnica

Comprobar:

• errores;
• objetos omitidos;
• permissions;
• version history;
• links;
• authentication;
• networking;
• backup;
• monitoring.

Validación funcional

Es la más importante.

El usuario debe poder realizar su trabajo.

Ejemplo

Una aplicación puede responder al ping y aun así no funcionar porque:

la API no conecta + la impresora no está disponible + el SQL tiene latencia + el certificado ha cambiado.

Rollback: saber cuándo parar

No todas las migraciones permiten un rollback completo.

Por eso necesitamos definir antes del cambio:

qué puede revertirse, hasta qué momento y con qué impacto.

Ejemplos

Definir criterios go/no-go

Por ejemplo:

si el 5 % de los usuarios piloto presenta un problema crítico → no iniciar la siguiente oleada.

Después de migrar empieza otra fase: operar

Un entorno cloud necesita un modelo operativo.

Microsoft 365

Definir ownership sobre:

• usuarios;
• grupos;
• Teams;
• SharePoint;
• guests;
• Conditional Access;
• Intune;
• Defender;
• Purview.

Azure

Definir ownership sobre:

• subscriptions;
• networking;
• security;
• backup;
• monitoring;
• patching;
• costs;
• incidents;
• DR;
• platform services.

Infrastructure as Code

Para entornos Azure repetibles y gobernados merece la pena utilizar IaC siempre que el modelo operativo lo permita.

Documentación

Una migración debería terminar con:

arquitectura + inventario + procedimientos + permisos + owners + runbooks + excepciones conocidas.

Qué métricas utilizar para saber si la migración fue un éxito

Errores frecuentes al migrar a Microsoft 365 y Azure

Checklist completo antes de migrar

Preguntas frecuentes sobre migraciones a Microsoft 365 y Azure

Conclusión: migrar al cloud no es trasladar servidores y buzones, sino decidir cómo queremos operar después

Una migración a Microsoft 365 y Azure puede empezar por una necesidad técnica muy concreta: sustituir Exchange, cerrar un datacenter, migrar un tenant adquirido o eliminar un servidor antiguo.

Pero la calidad del proyecto depende de mirar más allá del movimiento de datos.

En Microsoft 365 necesitamos decidir dónde debe terminar cada tipo de información. Los documentos personales tienen un propósito distinto a los documentos departamentales; Exchange tiene dependencias diferentes a Teams; y una migración tenant-to-tenant obliga a tratar identidad, dominios y coexistencia con especial cuidado.

Microsoft ha ampliado considerablemente sus capacidades nativas cross-tenant, con herramientas específicas para Exchange, OneDrive y SharePoint, además del Migration Orchestrator para determinadas cargas de usuario. Aun así, cada workload mantiene sus propias condiciones y no existe una única operación capaz de convertir automáticamente un tenant completo en otro idéntico.

En Azure ocurre algo parecido.

No debemos preguntar únicamente dónde alojar cada servidor, sino qué estrategia tiene sentido para el workload.

Las ocho estrategias actuales de Microsoft —Retire, Retain, Rehost, Replatform, Refactor, Rearchitect, Rebuild y Replace— permiten tomar una decisión diferente para cada aplicación.

Azure Migrate puede ayudarnos a descubrir el entorno y valorar readiness, rendimiento, dimensionamiento y coste, pero una assessment técnica debe complementarse con contexto empresarial.

Antes de incorporar workloads también necesitamos una base.

Cloud Adoption Framework y Azure Landing Zones proporcionan un modelo para estructurar identidad, suscripciones, gobierno, red, seguridad, monitorización y operación antes de que el entorno crezca sin control.

Lo mismo ocurre con el coste.

FinOps no debería introducirse cuando llega una factura inesperada seis meses después. La asignación de costes, tagging, budgets, rightsizing y accountability deberían formar parte de la arquitectura desde el principio.

Y la inteligencia artificial añade una razón adicional para ordenar los datos.

Microsoft 365 Copilot utiliza los permisos existentes. Si SharePoint y OneDrive están correctamente gobernados, eso juega a nuestro favor. Si hemos trasladado años de contenido sobrecompartido, sin propietario y sin clasificación, tendremos que resolver ese problema antes o durante la adopción de Copilot.

Una migración bien diseñada debería terminar, por tanto, con algo más que los datos en el nuevo destino.

Deberíamos terminar con:

menos sistemas innecesarios, una arquitectura conocida, identidades ordenadas, datos mejor ubicados, seguridad definida, costes gobernados, propietarios claros y una forma de operar el entorno después del proyecto.

Ese es el verdadero objetivo.

Documentación oficial recomendada

Microsoft 365 Migration

• Microsoft – Microsoft 365 migration overview
• Microsoft – Exchange mailbox migration
• Microsoft – File share to SharePoint and OneDrive migration

Tenant-to-tenant

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Migration Orchestrator
• Microsoft – Cross-tenant mailbox migration
• Microsoft – Cross-tenant OneDrive migration
• Microsoft – Cross-tenant SharePoint migration

Azure Cloud Adoption Framework

• Microsoft – Cloud Adoption Framework
• Microsoft – Select cloud migration strategies
• Microsoft – Execute a cloud migration

Azure Landing Zones

• Microsoft – Azure Landing Zone
• Microsoft – Azure Landing Zone design areas

Azure Migrate

• Microsoft – Azure Migrate documentation
• Microsoft – Azure Migrate assessments
• Microsoft – Azure Migrate discovery

FinOps y costes Azure

• Microsoft – What is FinOps?
• Microsoft – FinOps Framework
• Microsoft – Azure Cost Management
• Microsoft – Savings Plans vs Reservations

Microsoft 365 Copilot y gobierno de datos

• Microsoft – Security for Microsoft 365 Copilot
• Microsoft – Prepare SharePoint for Copilot and agents
• Microsoft – Microsoft 365 Copilot data protection architecture
• Microsoft – Purview for Microsoft 365 Copilot

Endpoint y seguridad

• Microsoft – Microsoft Intune
• Microsoft – Conditional Access
• Microsoft – Defender for Office 365