Migrar a Microsoft Fabric conviene hacerlo por cargas, no en un solo corte. Primero se inventaría lo que existe, se decide qué se conserva, se rediseña o se elimina, y recién entonces se mueve un piloto acotado que convive con lo anterior hasta que la validación permite retirar lo viejo. El error costoso es copiar informes sin cuestionar sus definiciones, su modelo y su seguridad.
Una migración grande falla cuando se trata como un traslado técnico. La plataforma nueva se llena de objetos, pero los problemas de gestión que motivaron el cambio siguen intactos. El cambio a Fabric es, sobre todo, una oportunidad para simplificar y profesionalizar. Este artículo propone una secuencia de decisión, no una receta universal, porque el orden real depende de tus dependencias y de tu tolerancia al riesgo.
Antes de mover nada, inventaría lo que ya tienes
No se puede priorizar lo que no está listado. El primer paso es un inventario de informes, fuentes, usuarios, métricas y dependencias. Para cada informe conviene saber a qué modelo apunta, quién lo usa y qué decisión sostiene. Para cada fuente, dónde vive el dato, qué calidad tiene, qué histórico existe y quién autoriza el acceso.
La guía de migración de Microsoft propone descubrir, evaluar y ejecutar por cargas en lugar de mover todo de golpe. Ese descubrimiento es el mismo trabajo que hace un diagnóstico de datos antes de un proyecto: separa un proyecto de datos de una colección de pedidos sueltos. Sin inventario, la migración avanza a ciegas.
El inventario también expone lo que sobra. Muchos informes duplican una métrica con fórmulas distintas, o dependen de un modelo por defecto que nadie gobierna. Detectarlo ahora es más barato que arrastrarlo.
Decide qué se conserva, qué se rediseña y qué se elimina
No todo lo que existe merece migrar. Con el inventario en mano, cada activo cae en una de tres categorías: se conserva porque su diseño sirve y su definición es correcta, se rediseña porque el diseño vale pero el modelo o la métrica no, o se elimina porque ya nadie lo usa o duplica algo mejor.
Esta clasificación es una decisión de negocio, no técnica. La toma quien es responsable de la métrica, no quien mueve el archivo. Conservar por inercia es la forma más común de trasladar deuda a la plataforma nueva. Reducir el alcance en esta etapa acelera todo lo que viene después.
Construye la base común antes de reconstruir informes
Fabric organiza el ciclo de vida del dato sobre OneLake como base compartida, con capas y contratos. La visión general de Microsoft Fabric describe cómo se centralizan integración, ingeniería, analítica e IA sobre ese lago único. La migración es el momento para ordenar esas capas siguiendo la arquitectura medallion: Bronze con el dato como llega y trazable, Silver limpio y unido, Gold listo para decisiones.
Sobre esa base se construye la capa semántica: modelos explícitos, con métricas gobernadas, relaciones correctas y seguridad probada. Aquí hay un cambio reciente que condiciona el plan. Desde el 5 de septiembre de 2025 ya no se generan de forma automática los modelos semánticos predeterminados, según lo documentado por Microsoft; y a partir del 30 de noviembre de 2025 los que seguían activos pasaron a existir como modelos independientes. Por eso conviene trabajar con modelos semánticos explícitos y no depender de los que se creaban por defecto. El modelo semántico es el contrato común de las métricas del negocio, y la migración es el mejor momento para hacerlo explícito.
Migra un piloto acotado, no la organización entera
El primer movimiento real es un piloto, no una carga completa. Se elige un conjunto pequeño de informes cuyo modelo oficial ya exista en la base común, y se migran como informes ligeros cuando el diseño sirve. La lista de verificación del informe ligero ayuda a no duplicar la capa de negocio: primero se verifica si el informe ya existe en Power BI Service y si su datasetId apunta al modelo oficial. Si no es así, el PBIX se publica solo como paso temporal.
Después se identifica el informe y el modelo creado, se reconecta el informe al modelo oficial, se verifica el datasetId, se elimina el modelo temporal y se exporta la definición del informe si el cliente necesita versionado. Ese reenlace es lo que sostiene la consolidación sin duplicar la capa de negocio. El piloto también es donde se prueba el dimensionamiento: la planificación de capacidad suma usuarios, concurrencia, crecimiento y operación al plan, y esas cifras se estiman mejor con un caso real que con supuestos.
Deja convivir lo viejo y lo nuevo mientras validas
Una migración por cargas implica un período de convivencia. Durante ese tiempo, el sistema anterior y el nuevo funcionan en paralelo, y la regla es no retirar nada hasta que la validación lo permita. Validar significa dos cosas concretas: reconciliar los números de cada informe migrado contra la fuente aceptada, y confirmar con los usuarios finales que el resultado responde a la misma pregunta de negocio.
Los números se prueban con DAX, los permisos se prueban con usuarios reales y las experiencias se prueban en el navegador, en Teams o en Excel según corresponda. La convivencia tiene un costo, porque mantener dos sistemas a la vez consume esfuerzo, así que conviene que cada carga tenga un criterio de salida claro en lugar de dejar el paralelo abierto por tiempo indefinido.
Define qué significa terminado antes de retirar lo anterior
Un informe que abre no es un informe terminado. Una carga migrada está lista cuando la organización puede confiar en ella y actuar. Eso implica que las decisiones clave tienen indicadores, responsables y cadencia; que las fuentes tienen entrada, transformación, responsable y validación; que el modelo semántico tiene métricas gobernadas y seguridad probada; y que existen rutinas para actualización, calidad, capacidad y cambios.
La retirada de lo viejo es el último paso, no el primero, y solo procede cuando la carga nueva cumple esa definición de terminado. Una evolución controlada entre entornos, con deployment pipelines para el ALM en Fabric, evita que la retirada se haga a mano y sin trazabilidad. Terminado significa que el sistema ya no depende de una demostración, sino de una forma clara de trabajar.
Dónde encaja una evaluación previa
La secuencia de arriba supone que ya sabes qué decisiones sostienen tus datos y qué fuentes las alimentan. Cuando ese mapa no existe, el inventario se convierte en adivinanza y la priorización pierde base. Ahí es donde una evaluación estructurada de fuentes, sistemas, procesos, calidad, acceso y responsables ordena el punto de partida antes de mover la primera carga.
Si vas a migrar por partes, empieza por listar tus informes actuales y marcar, para cada uno, a qué modelo semántico apunta hoy. Esa sola columna revela cuántos dependen de modelos por defecto que ya no se crean automáticamente, y esa lista es el primer insumo concreto de tu plan de migración. Si quieres ver cómo abordamos este tipo de evaluación y planificación en la práctica, mira la demo gratuita.
Preguntas relacionadas
¿Se puede migrar a Microsoft Fabric sin detener la operación actual?
Sí, ese es el propósito de migrar por cargas. El sistema anterior y el nuevo conviven en paralelo durante la validación, y cada carga solo se retira cuando sus números reconcilian contra la fuente aceptada y los usuarios confirman el resultado.
¿Por qué importa que los modelos semánticos predeterminados ya no se creen solos?
Microsoft dejó de crearlos automáticamente el 5 de septiembre de 2025 y separó los existentes como modelos independientes desde el 30 de noviembre de 2025. Al migrar conviene revisar qué informes dependían de esos modelos por defecto y reconectarlos a modelos explícitos y gobernados.
¿Qué es un informe ligero y cuándo conviene usarlo?
Es un informe que reutiliza el diseño existente pero se conecta al modelo semántico oficial en lugar de traer su propio modelo. Conviene cuando el diseño ya sirve y el modelo oficial existe, porque evita duplicar la capa de negocio al reenlazar el informe y eliminar el modelo temporal.
¿Cómo se decide qué informes migrar primero?
Se prioriza a partir del inventario, eligiendo un piloto acotado cuyo modelo oficial ya exista en la base común. Ese piloto valida el reenlace, la seguridad y el dimensionamiento de capacidad con un caso real antes de escalar a cargas mayores.
¿Cuándo se considera terminada una carga migrada?
Cuando la organización puede confiar y actuar: decisiones con responsables y cadencia, fuentes con validación, modelo con métricas gobernadas y seguridad probada, y rutinas de actualización, calidad y capacidad. Recién ahí procede retirar el sistema anterior.