Migrar a Microsoft Fabric no es copiar lo viejo en una plataforma nueva. Los proyectos que fallan mueven informes sin cuestionar definiciones, modelo, seguridad ni hábitos. La buena práctica es inventariar todo, separar lo que se conserva de lo que se rediseña o elimina, construir la base común en OneLake con capas y contratos, y trabajar con modelos semánticos explícitos en vez de los predeterminados.
¿Por qué fallan tantas migraciones a Fabric?
La causa más frecuente no es técnica: es tratar la migración como una mudanza literal. Se copian los informes tal cual, con sus definiciones ambiguas, sus modelos improvisados y sus permisos heredados. El resultado es el mismo desorden de antes, ahora sobre una plataforma más cara y más potente. La IA y Fabric no arreglan un modelo pobre, lo amplifican.
El cambio a Fabric es, en realidad, una oportunidad para simplificar y profesionalizar. Es el momento de cuestionar cada métrica, cada fuente y cada hábito antes de moverlo. Migrar bien significa llegar con menos informes, definiciones más claras y cifras que todo el negocio interpreta igual.
¿Qué inventariar antes de mover nada?
Antes de tocar Fabric, hay que saber qué se tiene. El inventario es la base de toda decisión posterior y también la mejor forma de definir por dónde empezar a migrar los reportes actuales. Conviene documentar:
- Informes: cuáles existen, quién los usa y con qué frecuencia.
- Fuentes de datos: de dónde salen las cifras y qué tan confiables son.
- Usuarios y permisos: quién accede a qué y bajo qué reglas.
- Métricas: cómo se define cada indicador y si hay definiciones que compiten.
- Dependencias: qué informe alimenta a otro y qué se rompe si algo cambia.
Con ese mapa en la mano, la migración deja de ser un salto a ciegas y pasa a ser un proyecto con criterio.
¿Cómo decidir qué se conserva, qué se rediseña y qué se elimina?
No todo merece viajar a Fabric. Una vez inventariado el activo actual, cada informe entra en una de tres categorías. Esta separación es la que convierte la migración en una oportunidad de limpieza real.
| Categoría | Criterio | Acción en Fabric |
|---|---|---|
| Se conserva | El diseño sirve y el modelo oficial ya existe | Migrar como informe ligero reconectado al modelo oficial |
| Se rediseña | El informe se usa pero su modelo o definiciones son pobres | Reconstruir sobre modelo semántico explícito |
| Se elimina | Sin uso real o duplicado de otro informe | Descartar, documentar la baja |
Eliminar informes que nadie usa no es una pérdida: es reducir superficie de mantenimiento y ruido para el equipo.
¿Por qué trabajar con modelos semánticos explícitos?
El modelo semántico es el contrato común de las métricas del negocio. Si cada informe define sus cifras a su manera, dirección y equipo terminan discutiendo números en vez de decidir. Por eso conviene no depender de modelos por defecto y construir modelos semánticos explícitos y gobernados.
Hay además un cambio reciente que refuerza esta práctica. Microsoft indica que los modelos semánticos predeterminados dejaron de crearse automáticamente el 5 de septiembre de 2025. Desde el 30 de noviembre de 2025, los existentes quedaron separados como modelos independientes. En la práctica, esto significa que la capa de negocio ya no viene "regalada" por defecto: hay que diseñarla, nombrarla y gobernarla de forma consciente, que es justo lo recomendable.
¿Cómo migrar un informe como informe ligero?
Cuando el diseño de un informe sirve y el modelo oficial ya existe en Power BI Service, la mejor práctica es migrarlo como informe ligero, sin duplicar la capa de negocio. La lista de verificación es concreta:
- Verificar si el informe ya existe en Power BI Service y si su
datasetIdapunta al modelo oficial. - Si no es así, publicar el PBIX solo como paso temporal.
- Identificar el informe y el modelo que se crearon al publicar.
- Reconectar el informe al modelo oficial (operación conocida como Rebind Report).
- Verificar que el
datasetIdahora apunta al modelo correcto. - Eliminar el modelo temporal que quedó huérfano.
- Exportar la definición del informe si el cliente necesita versionado.
Este procedimiento evita el error más común: dejar en producción varios modelos que calculan lo mismo de forma ligeramente distinta.
¿Cómo se construye la base común en OneLake?
Por debajo de los informes está la base de datos común. La recomendación es construirla en OneLake con capas y contratos, siguiendo la arquitectura medallion (Bronze, Silver, Gold): datos crudos, datos limpios y productos de datos listos para consumo. Cada capa tiene un contrato claro sobre qué entrega y con qué calidad.
Microsoft describe la migración a Fabric como un proceso de descubrir, evaluar y ejecutar por cargas de trabajo, no todo de golpe. Migrar por cargas reduce el riesgo y permite validar cada bloque antes de avanzar al siguiente.
¿Cómo validar que la migración quedó bien?
Una migración no termina cuando el informe abre en Fabric. Termina cuando los usuarios confían en las cifras. Por eso el último paso es validar resultados con usuarios reales y reconciliar contra la fuente aceptada. Si el número de Fabric no coincide con el número que dirección ya validaba, hay que entender por qué antes de dar por cerrada la carga.
Este cierre con validación es lo que transforma una migración técnica en una base confiable de verdad: los mismos números en Excel, Power BI o cualquier IA.
Siguiente paso
Migrar a Fabric con criterio (inventariar, separar, gobernar el modelo, validar) es un método que se puede aprender y aplicar paso a paso, ya sea con formación para el equipo o con acompañamiento de consultoría. Si quieres ver cómo se traduce este enfoque a tu caso concreto antes de mover nada, mira la demo gratuita: ahí te mostramos cómo trabajamos y qué camino tiene más sentido para tu empresa.
Preguntas relacionadas
¿Migrar a Microsoft Fabric es solo copiar mis informes actuales?
No. Migrar a Fabric no es copiar lo viejo en una plataforma nueva. Los proyectos fallan cuando mueven informes sin cuestionar definiciones, modelo, seguridad ni hábitos. Es una oportunidad para inventariar, simplificar y profesionalizar antes de mover nada.
¿Por qué conviene usar modelos semánticos explícitos en Fabric?
El modelo semántico es donde el negocio acuerda cómo se calcula cada métrica. Microsoft dejó de crear modelos predeterminados automáticamente el 5 de septiembre de 2025 y separó los existentes como modelos independientes desde el 30 de noviembre de 2025. Por eso conviene diseñar modelos semánticos explícitos y gobernados en vez de depender de los de por defecto.
¿Qué es migrar un informe como informe ligero?
Es reconectar un informe cuyo diseño sirve al modelo semántico oficial que ya existe, sin duplicar la capa de negocio. Se verifica el datasetId, se reconecta el informe al modelo oficial (Rebind Report), se elimina el modelo temporal y, si hace falta, se exporta la definición para versionado.
¿Debo migrar todo a Fabric de una sola vez?
No. Microsoft propone descubrir, evaluar y ejecutar por cargas de trabajo. Migrar por bloques reduce el riesgo y permite validar cada carga antes de avanzar. La base común se construye en OneLake con capas y contratos siguiendo la arquitectura medallion.
¿Cómo sé que la migración quedó bien hecha?
La migración termina cuando los usuarios confían en las cifras. El paso final es validar resultados con usuarios reales y reconciliar contra la fuente aceptada. Si un número de Fabric no coincide con el que dirección ya validaba, hay que entender por qué antes de cerrar la carga.