La mayoría de las migraciones a Microsoft 365 no fracasan por una mala planificación. Fracasan en los tres días que rodean el cutover, cuando el entorno de producción cambia de manos y cualquier error se convierte en un problema visible para toda la organización. El flujo de correo se interrumpe, las licencias quedan mal asignadas, Teams Voice deja de funcionar y los permisos de SharePoint se rompen sin que nadie haya definido un plan de vuelta atrás. Para una PYME, ese escenario no es solo un inconveniente técnico; es una paralización operativa con coste real.
Este artículo analiza los cinco errores de ejecución que más afectan a las pequeñas y medianas empresas durante la semana crítica del cutover. Aprenderás qué ocurre exactamente en cada fallo, cómo identificarlo antes de que escale y qué palancas puedes activar para negociar un contrato de microsoft 365 setup más seguro con cualquier proveedor de servicios. Al final encontrarás una checklist práctica de las 72 horas críticas para que tu equipo entre a esa ventana con visibilidad total y sin margen para la improvisación.
Qué es el cutover y por qué concentra los fallos de una migración a Microsoft 365
En la metodología oficial de Microsoft para Exchange Online, una cutover migration es exactamente lo que su nombre indica: todos los buzones de correo se mueven al mismo tiempo desde el servidor origen hacia Exchange Online, y una vez completada la migración, el entorno anterior queda desactivado. No hay fases, no hay coexistencia prolongada. Es una operación de corte limpio.
Cutover, staged e hybrid: tres caminos con riesgos distintos
Microsoft documenta tres enfoques principales para migrar correo a Microsoft 365. La staged migration traslada los buzones en lotes durante semanas, manteniendo ambos entornos activos en paralelo. El hybrid deployment establece una coexistencia permanente o prolongada entre Exchange on-premises y Exchange Online, adecuada para organizaciones con requisitos de cumplimiento complejos. El cutover es el más simple en concepto y el más brutal en ejecución.
Las PYMEs con menos de 150 buzones eligen cutover casi siempre por la misma razón: es más rápido y más barato sobre el papel. El problema es que “más simple” no significa “más seguro”. Significa que todos los riesgos que en una staged migration se distribuyen en semanas se comprimen aquí en horas.
Por qué las 72 horas del cutover son la tormenta perfecta
Durante la ventana de cutover coexisten temporalmente dos entornos activos, los registros DNS propagan el cambio de MX a velocidades distintas según el proveedor del remitente, y decenas o cientos de usuarios intentan autenticarse en el nuevo tenant de forma simultánea. Cada una de estas variables genera dependencias; cuando se combinan, los fallos en cadena son casi inevitables si no existe un protocolo de respuesta específico.
Fallos de planificación vs. fallos de ejecución
Un fallo de planificación es detectable semanas antes del cutover: licencias no adquiridas, dominios no verificados, conectores no configurados. Un fallo de ejecución solo se manifiesta en producción, bajo carga real, con usuarios conectados. Requiere un plan de respuesta activo, no una lista de verificación previa.
Esta distinción importa porque la mayoría de los recursos disponibles, incluida la documentación oficial, abordan la planificación. Los hilos activos en la comunidad de Microsoft Q&A en 2026 muestran organizaciones cuyas migraciones “siguen fallando” en intentos repetidos. El problema no es falta de documentación; es la ausencia de una taxonomía clara de errores de ejecución, que es exactamente lo que cubre este artículo.
Antes de contratar cualquier servicio de migración, vale la pena entender cuándo subcontratar el soporte informático externo y qué exigirle al proveedor, porque las garantías que no se negocian antes del cutover no existen durante él.
Error 1: el flujo de correo se rompe tras el cambio de registro MX
El fallo más frecuente del cutover no ocurre por un error de configuración complejo: ocurre porque nadie redujo el TTL del registro MX a tiempo.
La causa raíz: el TTL que nadie toca
Cuando el registro MX tiene un TTL de 3.600 o 86.400 segundos, los servidores DNS almacenan ese valor en caché durante horas. Si cambias el registro MX en el momento del cutover sin haberlo reducido previamente, los servidores de correo de tus remitentes siguen enviando mensajes al servidor origen durante todo ese tiempo. La recomendación técnica es reducir el TTL a 300 segundos al menos 48 horas antes del cutover. Así, cuando el registro apunta a los servidores de Microsoft 365 (*.mail.protection.outlook.com), la propagación ocurre en minutos, no en horas.
La coexistencia no planificada
El problema real es el intervalo donde dos entornos reciben correo simultáneamente. Mientras la propagación DNS está en curso, el servidor DNS del remitente determina a dónde llega el mensaje. Los usuarios, que ya operan en el nuevo entorno, no ven los mensajes que siguen llegando al servidor antiguo. El resultado son tres síntomas que muchos proveedores diagnostican mal:
- NDR intermitentes sin causa aparente, porque el servidor origen ya no está configurado para aceptar correo de ciertos dominios
- Usuarios que reportan no recibir respuestas, cuando en realidad la respuesta llegó al buzón antiguo
- Correos que aparecen y desaparecen, síntoma de sincronizaciones parciales entre ambos entornos
Estos síntomas son característicos de las primeras 6 a 12 horas post-cutover y no indican un fallo de Exchange Online, sino una coexistencia no gestionada.
Checklist de validación post-cutover (primeras 2 horas)
- En el Exchange Admin Center, revisar que los conectores de entrada y salida están activos y apuntan al tenant correcto
- Confirmar en el proveedor DNS que el registro MX apunta exclusivamente a
*.mail.protection.outlook.com, sin registros MX residuales del servidor anterior - Ejecutar el Analizador de Conectividad Remota (ExRCA) en
testconnectivity.microsoft.compara validar el flujo SMTP entrante - Revisar Message Trace en el Exchange Admin Center filtrando por los últimos 30 minutos, buscando mensajes en estado “Failed” o “Pending”
Remediación urgente si el flujo falla
Si Message Trace muestra fallos persistentes tras 30 minutos del cambio de MX, el primer paso no es el rollback completo: es reactivar el conector hacia el servidor origen como relay de emergencia. Esto permite que los correos que aún llegan al servidor antiguo sean reenviados a Exchange Online sin pérdida mientras se resuelve la causa raíz.
Comunica a los usuarios que no eliminen ni reenvíen correos manualmente. La regla práctica para activar un rollback completo en lugar de sostener la coexistencia de emergencia es esta: si tras 4 horas el flujo sigue sin estabilizarse y más del 20% de los usuarios no recibe mensajes de forma fiable, la coexistencia de emergencia ha dejado de ser una solución temporal y se convierte en un riesgo operativo activo.
Error 2: licencias de Microsoft 365 asignadas de forma incompleta o incorrecta
El flujo de correo puede funcionar correctamente y aun así la jornada post-cutover convertirse en un caos si los usuarios no tienen licencias operativas. Comprar las licencias y asignarlas son dos acciones distintas, y el gap entre ambas es uno de los fallos más frecuentes en cualquier microsoft 365 setup de PYME.
Licencias compradas no equivalen a licencias activas. Una organización puede haber adquirido el plan correcto semanas antes del cutover y llegar al día D con un porcentaje significativo de usuarios sin acceso. La causa habitual: la asignación en Entra ID no se completó, se hizo sobre cuentas deshabilitadas, o se aplicó el plan equivocado al grupo incorrecto. Microsoft 365 no activa servicios por el simple hecho de que las licencias existan en el tenant; cada licencia debe asignarse explícitamente a una cuenta de usuario activa.
Errores de asignación más frecuentes
- Plan incorrecto para el perfil de usuario: asignar Microsoft 365 Business Basic a usuarios que trabajan con Word, Excel o Outlook de escritorio. Business Basic incluye únicamente las versiones web; sin Business Standard o superior, esos usuarios no pueden instalar las apps locales.
- Planes de servicio internos desactivados: una licencia como Microsoft 365 Business Premium incluye Exchange Online, Teams y SharePoint como planes individuales. Si alguno está en estado “Suspendido”, el usuario ve la app pero no puede acceder. Ocurre cuando se personalizan asignaciones sin revisar el estado de cada componente.
- Asignación a cuentas deshabilitadas: si las cuentas se crearon como deshabilitadas y la licencia se asignó en ese estado, la activación posterior del usuario no activa automáticamente todos los servicios.
Buzones compartidos y cuentas de sala
Los buzones compartidos no requieren licencia completa para funcionar como destino de correo, pero los permisos de “Acceso completo” y “Enviar en nombre de” deben reasignarse manualmente en Exchange Online; no se heredan del entorno origen. Las cuentas de sala y recurso siguen la misma lógica: sin configuración específica del calendario y las políticas de reserva, aparecen en el directorio pero no funcionan. Muchos runbooks omiten estos objetos y el impacto se nota el primer día laboral.
Secuencia de verificación antes de cerrar el cutover
En el Microsoft 365 Admin Center:
- Ir a Usuarios activos y revisar la columna “Licencias”. Cualquier usuario sin licencia aparece marcado de forma visible.
- Usar el filtro “Sin licencia asignada” para aislar cuentas problemáticas en un solo paso.
- Para cada licencia asignada, confirmar que los planes de servicio individuales (Exchange Online, Microsoft Teams, SharePoint Online) están en estado “Activado”, no “Suspendido” ni “Pendiente”.
Este proceso toma menos de diez minutos en un entorno de 50 usuarios.
Impacto operativo real
El error de licencias no genera un fallo técnico visible durante la migración; se manifiesta cuando los empleados intentan trabajar. Los síntomas concretos: el correo muestra un error de autenticación, Teams bloquea el inicio de sesión, o el usuario recibe “Su cuenta no tiene una licencia válida de Office”. Resolver estos casos bajo presión operativa, usuario por usuario, es exactamente el tipo de intervención reactiva que un socio externo de IT con experiencia en gestión de Microsoft 365 para PYMEs puede ejecutar con rapidez, siempre que el problema esté identificado y el acceso al Admin Center esté garantizado desde el inicio de la ventana de cutover.
Error 3: Teams Voice y Direct Routing sin validar en producción
Si el error anterior deja usuarios sin correo, este los deja sin teléfono, y nadie lo nota de inmediato.
Por qué Teams Voice falla en silencio
Un buzón roto genera rebotes visibles en minutos. Una configuración incorrecta de Direct Routing o Calling Plans en Teams Phone produce un escenario más engañoso: las llamadas salientes funcionan con normalidad, dando falsa sensación de éxito, mientras las entrantes rebotan sin que el administrador reciba ninguna alerta. Los números internos pueden resolver de forma intermitente según el usuario, sin generar un error consistente que dispare una revisión.
Los tres puntos de fallo más frecuentes
Durante una microsoft 365 migration que incluye telefonía, los fallos se concentran en tres configuraciones:
- Voice Routing Policies no asignadas. Las políticas de enrutamiento no se heredan automáticamente al crear usuarios en el tenant nuevo. Un usuario sin política asignada puede iniciar sesión sin aviso y descubrir que no recibe llamadas externas solo cuando un cliente se queja.
- Session Border Controllers con certificados no validados. Un SBC con certificado caducado o no validado contra el tenant nuevo deja el trunk de Direct Routing inactivo. La configuración parece correcta en el portal, pero las llamadas no se cursan.
- Números en estado “Sin asignar”. Un número puede aparecer importado en el Portal de administración de Teams pero sin asignar a ningún usuario o cola. Las llamadas entrantes no llegan a ningún destino.
El problema específico de las PYMEs con centralitas previas
Las organizaciones que migran desde centralita física o VoIP enfrentan un problema adicional: los patrones de marcado, los Dial Plans y las colas de llamadas no se transfieren a Teams Phone y deben reconfigurarse manualmente. Para PYMEs que gestionan números suizos a través de Teams, esto incluye los planes de marcado nacionales; más detalles en telefonía con número suizo en Microsoft Teams.
Tests de validación obligatorios antes de cerrar el cutover
- Llamada saliente a número externo desde cinco usuarios de distintos departamentos
- Llamada entrante desde un número externo a la línea principal
- Transferencia interna entre dos extensiones
- Verificación del buzón de voz desde Teams, confirmando que el mensaje queda grabado y se entrega
La consecuencia de saltarse esta validación
Una PYME sin monitorización activa puede operar días sin recibir llamadas entrantes. No hay NDR, no hay alerta, no hay ticket automático. El problema emerge solo cuando un cliente informa de que lleva días sin poder contactar, o cuando alguien revisa manualmente el estado del SBC en el portal.
Error 4: permisos rotos en SharePoint y OneDrive tras la migración de datos
Si el flujo de correo y la telefonía tienen síntomas visibles casi de inmediato, los permisos rotos en SharePoint y OneDrive son más traicioneros: la mayoría de los usuarios no reporta el problema hasta horas o días después del cutover, cuando necesita un documento concreto y descubre que ya no puede acceder a él.
Por qué los permisos no se migran 1:1
Las herencias de permisos en estructuras de carpetas complejas, especialmente cuando se migra desde servidores de archivos on-premises o desde plataformas de terceros, no se replican con fidelidad en SharePoint Online. La razón es estructural: los servidores de archivos tradicionales gestionan permisos mediante ACLs (Access Control Lists) a nivel de sistema operativo, mientras que SharePoint opera con un modelo de herencia de sitio/biblioteca/elemento que tiene sus propias restricciones. El resultado son carpetas que el usuario podía ver antes del cutover y que ahora devuelven un error de acceso denegado sin explicación adicional.
Buzones compartidos y grupos de Microsoft 365
Los permisos de Enviar en nombre de y Acceso total sobre buzones compartidos no se migran automáticamente; deben reconfigurar de forma explícita en Exchange Online tras el cutover. La característica más problemática es que el usuario afectado no recibe un mensaje de error claro: simplemente el buzón compartido no aparece en su Outlook o las acciones de envío fallan silenciosamente. En entornos de PYME donde varios empleados gestionan una misma dirección de contacto o de facturación, este bloqueo tiene impacto operativo inmediato.
El error del propietario único en SharePoint
Durante una migración de Microsoft 365 mal ejecutada, es habitual que los sitios de SharePoint queden con el administrador del tenant como único propietario. Ningún responsable de negocio tiene control sobre su propio contenido. El efecto: una avalancha de solicitudes de acceso en los primeros días post-cutover que colapsa al administrador y genera fricciones innecesarias con los usuarios.
Verificación con PnP.PowerShell
Antes de dar el cutover por cerrado, ejecutar el módulo PnP.PowerShell permite listar todos los permisos únicos de una biblioteca de documentos, identificar elementos con herencia rota y exportar un informe comparativo antes/después. El comando Get-PnPListItem combinado con Get-PnPListItemPermission genera esa evidencia en minutos.
Protocolo de corrección urgente
Si se detectan permisos rotos en producción, la regla es no restaurarlos manualmente carpeta a carpeta bajo presión de tiempo. Ese enfoque genera inconsistencias imposibles de auditar. El protocolo correcto: aplicar las plantillas de permisos predefinidas que deben estar documentadas en el runbook de migración antes del cutover, y escalar al proveedor IT adjuntando el informe de PowerShell como evidencia del estado actual. Sin ese informe, cualquier corrección es a ciegas.
Error 5: no tener un plan de rollback definido ni probado antes del cutover
Los permisos rotos se detectan y se corrigen. Un cutover sin plan de rollback, en cambio, convierte cualquier fallo en una crisis sin salida.
Por qué muchos proveedores no documentan el rollback
Comprometerse con un rollback explícito obliga a responder preguntas incómodas: ¿está el servidor origen todavía activo? ¿Quién revierte los registros MX? ¿Cómo se comunica el incidente a los usuarios? Un rollback completo equivale, contractualmente, a reconocer que la migración falló. Muchos proveedores no documentan este proceso porque nunca han tenido que ejecutarlo, y confunden esa ausencia de experiencia con innecesaridad del procedimiento.
Qué debe incluir un plan de rollback viable
Un plan operativo mínimo para una migración a Microsoft 365 contiene cuatro elementos no negociables:
- Punto de no retorno definido: normalmente entre 4 y 6 horas después del cambio de registro MX. Antes de ese umbral, revertir es técnicamente factible; después, el coste operativo escala de forma exponencial.
- Criterios objetivos de activación: por ejemplo, más del 20% de usuarios sin acceso tras 2 horas, o más de 15 NDR en 30 minutos. Sin números concretos, la decisión de revertir queda atrapada en debates subjetivos bajo presión.
- Procedimiento de reactivación del servidor origen: los pasos para volver a enrutar el MX, reactivar conectores y confirmar el flujo deben estar escritos y asignados a una persona responsable, no reconstruidos de memoria a las 3 de la madrugada.
- Checklist de comunicación interna: quién notifica a los usuarios, con qué mensaje y en qué plazo.
La coexistencia de emergencia como alternativa al rollback completo
Antes del rollback total existe una opción intermedia: mantener el servidor de correo origen activo como relay de backup durante las primeras 24-48 horas post-cutover. Esta “coexistencia de emergencia” permite absorber fallos parciales, enrutar correo afectado al entorno anterior y ganar tiempo para resolver problemas en Exchange Online sin interrumpir el servicio. No es una solución permanente, pero elimina la presión binaria de “todo funciona o revertimos todo”.
Las preguntas que toda PYME debe hacer antes de firmar
Exige respuestas escritas a estas cuatro preguntas antes de aprobar cualquier contrato de migración:
- ¿Cuál es el procedimiento documentado de rollback y dónde está por escrito?
- ¿Quién toma la decisión de activarlo y en qué plazo máximo desde la detección del fallo?
- ¿Cuánto tiempo lleva técnicamente revertir el entorno completo?
- ¿El rollback está incluido en el precio del proyecto o genera costes adicionales?
Un proveedor que no puede responder estas preguntas con precisión no ha ejecutado un rollback real.
Cómo documentar el punto de no retorno
Identifica las acciones irreversibles del proceso: desactivación del tenant origen, cancelación de licencias del proveedor anterior, eliminación de datos del servidor on-premises. Ninguna debe ejecutarse hasta que el cutover haya sido validado como exitoso con criterios medibles. Documenta cada acción irreversible en el runbook con una casilla de validación explícita y un responsable asignado. Si el runbook de tu proveedor no las lista, el punto de no retorno no está controlado, está improvisado.
Cómo negociar un contrato de migración a Microsoft 365 más seguro como PYME
Saber que necesitas un plan de rollback es una cosa; conseguir que tu proveedor lo firme es otra. El contrato es el único instrumento que convierte los cinco errores descritos en este artículo en obligaciones exigibles, y la mayoría de las PYMEs llegan a la negociación sin saber qué cláusulas pedir.
SLA específicos para la ventana de cutover
El SLA estándar de soporte (respuesta en 4-8 horas hábiles) es irrelevante durante las 72 horas críticas del cutover. Exige un SLA diferenciado para esa ventana: respuesta máxima de 30 minutos ante fallos de flujo de correo o acceso de usuarios, disponibilidad confirmada del equipo técnico durante toda la ventana, y una cláusula de compensación o extensión gratuita si el cutover requiere más de una ventana para completarse. Si el proveedor se niega a separar estos dos SLA en el contrato, es una señal de advertencia.
Criterios de éxito medibles, por escrito
“La migración ha ido bien” no es un criterio. Estos sí lo son:
- ≥ 90% de usuarios operativos con acceso a correo, Teams y SharePoint en las primeras 2 horas post-cutover.
- Cero errores críticos de flujo de correo (NDR masivos, rebotes de entrega) en las primeras 4 horas.
- Validación explícita de Teams Voice y permisos de SharePoint antes de que el proveedor declare el cierre formal del proyecto.
Sin estos números en el contrato, el proveedor define “éxito” de forma unilateral.
Experiencia real frente a conocimiento teórico
Solicita referencias de al menos dos migraciones de microsoft 365 migration ejecutadas en PYMEs de tamaño y sector comparables. Pide el runbook de cutover antes de firmar y verifica que incluye respuesta documentada para cada uno de los cinco fallos cubiertos en este artículo. Un proveedor con experiencia práctica entrega ese documento sin objeciones. La diferencia es visible: ¿incluye el runbook los valores de TTL recomendados? ¿Menciona las Voice Routing Policies? ¿Define el punto de no retorno? Puedes consultar más criterios en la guía para elegir un proveedor IT para tu PYME.
El valor de un socio externo especializado
Un departamento IT interno gestiona soporte, incidencias paralelas y comunicación con dirección el día del cutover. Un socio externo dedicado exclusivamente a la migración elimina esa dispersión. KMU Informatik Support acompaña a PYMEs en la región de Suiza central con atención exclusiva durante la ventana de migración, con capacidad de intervención remota y presencial. Puedes revisar el alcance en la página de consultoría cloud y servicios de migración de KMU Informatik.
Lista de verificación contractual mínima
Antes de firmar, confirma que el contrato incluye estos cuatro elementos:
- Plan de rollback documentado con responsable asignado y criterios objetivos de activación.
- Ventana de mantenimiento acordada con comunicación previa a todos los usuarios afectados.
- Acceso al tenant de Microsoft 365 garantizado para el cliente durante todo el proceso, sin dependencia del proveedor para operaciones básicas.
- Documentación post-migración con la configuración final del entorno, incluyendo conectores, políticas de voz, permisos y licencias asignadas.
Un contrato que no incluya estos cuatro puntos transfiere todo el riesgo operativo al cliente.
Checklist de las 72 horas críticas del cutover de Microsoft 365
Con el contrato firmado y los criterios de éxito acordados, la ejecución se convierte en la única variable que importa. Este checklist traduce los cinco errores analizados en acciones concretas, ordenadas por la ventana temporal en que deben ejecutarse.
24 horas previas al cutover
- Reducir el TTL de los registros MX y SPF a 300 segundos para acelerar la propagación DNS en el momento del cambio.
- Verificar en el Microsoft 365 Admin Center que el 100 % de los usuarios activos tienen licencia asignada y que los planes de servicio individuales (Exchange Online, Teams, SharePoint) no están en estado “Suspendido”.
- Ejecutar el ExRCA (Exchange Remote Connectivity Analyzer) para validar conectores de entrada y salida antes de cambiar el MX.
- Probar autenticación en el nuevo tenant para la totalidad de los buzones migrados.
- Enviar comunicación formal a usuarios finales con instrucciones de acceso post-cutover: URL de Outlook Web, credenciales y contacto de soporte de guardia.
Primeras 4 horas post-cutover (ventana crítica)
- Abrir Message Trace en Exchange Admin Center y confirmar flujo de correo entrante y saliente sin NDR.
- Validar acceso operativo de al menos 5 usuarios representativos de departamentos distintos (ventas, administración, dirección y operaciones).
- Ejecutar llamada de prueba entrante y saliente en Teams Voice desde dos números diferentes.
- Revisar el registro de errores en el Migration Dashboard del Admin Center y cerrar o escalar cada incidencia abierta.
Horas 4 a 24 (estabilización)
- Monitorizar continuamente el flujo de correo; cualquier NDR persistente se trata como incidencia crítica.
- Resolver permisos reportados por usuarios; no posponer ningún bloqueo de acceso a SharePoint o buzón compartido.
- Confirmar sincronización de OneDrive en clientes de escritorio y que los propietarios de contenido acceden a sus sitios de SharePoint sin errores.
Horas 24 a 72 (cierre y documentación)
- Desactivar el entorno origen únicamente tras confirmar que ningún usuario ni sistema integrado depende de él.
- Entregar al cliente el informe de migración con capturas del estado final del tenant.
- Configurar alertas de monitorización en Microsoft 365 Defender y fijar la revisión post-implementación a 30 días vista. El equipo de soporte Microsoft 365 de KMU Informatik incluye esta revisión como parte del acompañamiento post-cutover.
Criterios objetivos de rollback
Activar el rollback sin demora si se cumple cualquiera de estas condiciones:
- Más del 20 % de usuarios sin acceso operativo transcurridas 2 horas desde el cutover.
- Fallos de flujo de correo no resueltos en las primeras 4 horas post-cutover.
- Pérdida de datos confirmada en cualquier buzón o biblioteca de SharePoint, independientemente del momento en que se detecte.
Conclusión: la semana del cutover es donde se gana o se pierde una migración a Microsoft 365
Con el checklist de las 72 horas en mano, el cuadro completo queda claro: el éxito de una migración a Microsoft 365 no se decide en las semanas de planificación, sino en la ejecución.
Los cinco errores documentados en este artículo siguen un patrón consistente en entornos de PYME:
- Flujo de correo roto por TTL no reducido y gestión incorrecta del registro MX en las horas previas al cambio
- Licencias incompletas o mal asignadas en Entra ID, que bloquean a usuarios el primer día laboral post-cutover
- Teams Voice sin validar en producción, con llamadas entrantes que fallan silenciosamente sin alertar al administrador
- Permisos rotos en SharePoint y OneDrive por herencias no replicadas y buzones compartidos sin reconfigurar
- Ausencia de un plan de rollback documentado, con criterios de activación y responsables asignados
Ninguno de estos fallos es consecuencia de una planificación deficiente. Todos ocurren porque los protocolos de ejecución, validación y rollback no estaban definidos con precisión suficiente antes de iniciar la ventana de cutover. Una migración al microsoft 365 cloud bien planificada puede igualmente interrumpir el negocio durante 48 horas si el runbook de ejecución no contempla cada uno de estos escenarios.
La acción más importante antes de iniciar la migración
Antes de firmar cualquier contrato, exige a tu proveedor IT el runbook completo de cutover. Verifica que incluye una respuesta concreta para cada uno de los cinco fallos descritos. Si el documento no existe, o si las respuestas son genéricas, ese es el indicador más fiable de que el proveedor no ha ejecutado suficientes migraciones bajo presión real.
Cómo KMU Informatik Support trabaja con PYMEs en Suiza central
KMU Informatik Support acompaña a PYMEs durante todo el ciclo de vida de una migración a Microsoft 365, con atención específica a la ventana de ejecución. El equipo dispone de capacidad de intervención tanto remota como presencial en la región de Suiza central, lo que permite responder en tiempo real ante cualquier incidente durante las 72 horas críticas, sin depender de escalaciones a terceros.
Próximos pasos concretos
- Guarda el checklist de las 72 horas de este artículo como referencia operativa para el día del cutover.
- Revisa tu contrato de migración vigente y verifica si incluye las cláusulas de SLA, los criterios de éxito y el plan de rollback identificados en este artículo.
- Contacta con un proveedor IT especializado en PYMEs si alguno de los cinco errores no está cubierto en tu plan actual, antes de que la ventana de cutover lo ponga en evidencia.
