Para migrar tus reportes a Microsoft Fabric, no empieces por mover archivos. Empieza por inventariar reportes, fuentes, usuarios, métricas y dependencias, y decide qué conservar, qué rediseñar y qué eliminar. Después construye una base común en OneLake, crea modelos semánticos explícitos y migra los reportes que valgan la pena como informes ligeros conectados al modelo oficial. Al final valida los resultados con los usuarios y reconcilia contra la fuente aceptada.
Migrar no es copiar lo viejo en una plataforma nueva
Muchos proyectos de migración a Fabric fallan por la misma razón: mueven informes sin cuestionar sus definiciones, su modelo, su seguridad ni los hábitos que los rodean. El resultado es el mismo desorden de siempre, ahora sobre una plataforma más cara y más potente.
El cambio a Fabric es una oportunidad para simplificar y profesionalizar. Es el momento de ordenar las métricas antes de tocar las herramientas: primero se define qué mide el negocio y qué decisiones dependen de cada número, y la herramienta viene después. La IA no arregla un modelo pobre, lo amplifica.
El primer paso es un inventario honesto
Antes de mover nada, necesitas saber qué tienes. Un inventario honesto evita arrastrar reportes que nadie usa y duplicar métricas que ya no significan lo mismo.
Inventaría estos cinco elementos:
- Informes: cuáles existen, quién los abre y con qué frecuencia.
- Fuentes: de dónde salen los datos de cada informe.
- Usuarios: quién consume cada número y para qué decisión.
- Métricas: cómo se define cada indicador y si dos informes lo calculan distinto.
- Dependencias: qué informes dependen de qué modelos, flujos o archivos.
Con ese mapa sobre la mesa, la conversación deja de ser técnica y pasa a ser de negocio: cuáles son las métricas que de verdad importan y quién las gobierna.
Separa lo que conservas, lo que rediseñas y lo que eliminas
No todo merece viajar. Clasificar cada informe en una de tres categorías es lo que convierte una migración en una limpieza.
| Categoría | Qué significa | Qué haces |
|---|---|---|
| Conservar | El diseño sirve y el modelo oficial ya existe | Migrar como informe ligero conectado al modelo |
| Rediseñar | El informe importa pero su modelo o definiciones están mal | Reconstruir sobre el modelo semántico gobernado |
| Eliminar | Nadie lo usa o duplica otro | Retirarlo y documentar la decisión |
Esta clasificación es una de las buenas prácticas para la migración a Microsoft Fabric: reduce el volumen real de trabajo y protege un principio simple: cada métrica se define una sola vez, en un solo lugar.
Construye la base común en OneLake antes de migrar informes
Los informes son la punta del iceberg. Debajo necesitan una base de datos ordenada y confiable. En Fabric esa base vive en OneLake, organizada por capas.
La arquitectura medallion en OneLake separa los datos en tres capas: Bronze guarda los datos crudos tal como llegan, Silver los limpia e integra, y Gold expone los productos de datos listos para el negocio. Cada capa tiene un contrato claro de qué entra y qué sale, así los informes se apoyan en datos que ya fueron validados en lugar de repetir la misma limpieza en cada archivo. En esa capa Gold también conviene decidir si tu caso pide un lakehouse o un warehouse en Fabric, según cómo se consuman esos productos de datos.
Sobre esa base construyes los modelos semánticos, que fijan una definición compartida para todas las métricas. Un informe ligero que apunta al modelo oficial siempre mostrará el mismo número que cualquier otro que use ese modelo.
Crea modelos semánticos explícitos, no los que salen por defecto
Este punto cambió hace poco y conviene tenerlo claro. Microsoft indica que los modelos semánticos predeterminados dejaron de crearse automáticamente el 5 de septiembre de 2025, y que desde el 30 de noviembre de 2025 los existentes quedaron separados como modelos independientes.
La lección práctica es directa: no dependas de los modelos por defecto. Crea modelos semánticos explícitos, con nombres, definiciones y permisos gobernados. Un modelo explícito es el que puedes versionar, auditar y compartir con confianza. Un modelo que apareció solo es el que nadie controla y termina divergiendo.
Migra los informes que sirven como informes ligeros
Cuando el diseño de un informe funciona y el modelo oficial ya existe, no lo reconstruyas: reconéctalo. Un informe ligero es una capa de visualización que apunta al modelo semántico gobernado, sin arrastrar su propia copia de las métricas.
Esta es la lista de verificación del informe ligero:
- Verifica si el informe ya existe en Power BI Service y si su
datasetIdapunta al modelo oficial. - Si no es así, publica el PBIX solo como paso temporal.
- Identifica el informe y el modelo que se creó al publicar.
- Reconecta el informe al modelo oficial (operación de rebind).
- Verifica de nuevo el
datasetIdpara confirmar que apunta al modelo correcto. - Elimina el modelo temporal que quedó huérfano.
- Exporta la definición del informe si el cliente necesita versionado.
La guía de migración a Fabric plantea el trabajo en tres momentos: descubrir, evaluar y ejecutar por cargas. La operación de reconexión de informes (rebind report), junto con los modelos explícitos, sostiene esa consolidación sin duplicar la capa de negocio.
Valida con usuarios y reconcilia contra la fuente aceptada
Una migración no termina cuando el informe abre. Termina cuando el usuario confía en el número. Por eso el último paso es sentarse con quien usa cada informe y reconciliar contra la fuente que la organización ya acepta como buena.
Si el nuevo informe muestra una cifra distinta a la de referencia, esa diferencia se investiga y se explica antes de dar la migración por cerrada. Ese cierre es lo que convierte a Fabric en una plataforma confiable que la gente usa, no en una copia elegante del desorden anterior.
Cómo llevar este método a tu propia migración
Migrar por cargas, con inventario, modelo semántico explícito y validación, es un trabajo de criterio antes que de herramienta. Si quieres ver cómo se aplica este enfoque a los reportes y datos de tu empresa, y qué camino conviene en tu caso, mira la demo gratuita.
Preguntas relacionadas
¿Por dónde empiezo para migrar mis reportes a Microsoft Fabric?
Empieza por un inventario de informes, fuentes, usuarios, métricas y dependencias. Luego decide qué conservar, qué rediseñar y qué eliminar, construye la base en OneLake con capas y contratos, crea modelos semánticos explícitos y migra los reportes que sirven como informes ligeros. Cierra validando con usuarios y reconciliando contra la fuente aceptada.
¿Migrar a Fabric es simplemente copiar mis reportes actuales?
No. Copiar lo viejo tal cual arrastra el desorden a una plataforma más potente. Migrar bien significa cuestionar definiciones, modelo, seguridad y hábitos, y usar el cambio como oportunidad para simplificar y profesionalizar las métricas.
¿Qué es un informe ligero y cuándo conviene usarlo?
Un informe ligero es una capa de visualización que apunta al modelo semántico oficial sin arrastrar su propia copia de las métricas. Conviene cuando el diseño del informe ya sirve y el modelo oficial existe: se reconecta el informe al modelo correcto y se elimina cualquier modelo temporal.
¿Por qué debo crear modelos semánticos explícitos y no los que salen por defecto?
Microsoft dejó de crear modelos semánticos predeterminados automáticamente desde el 5 de septiembre de 2025, y desde el 30 de noviembre de 2025 los existentes quedaron separados como modelos independientes. Un modelo explícito y gobernado se puede versionar, auditar y compartir sin que las métricas diverjan.
¿Cómo sé que la migración quedó bien hecha?
La migración se considera cerrada cuando validas cada informe con sus usuarios y reconcilias las cifras contra la fuente que la organización ya acepta como buena. Si aparece una diferencia, se investiga y explica antes de dar el informe por migrado.