Migrar tus reportes a Microsoft Fabric no es copiar lo viejo en una plataforma nueva. Es un proceso por fases: inventariar informes, fuentes y métricas; decidir qué se conserva, se rediseña o se elimina; construir una base común en OneLake con capas y contratos; y reconectar cada informe a un modelo semántico explícito y gobernado. La migración se valida contra la fuente aceptada, no se da por buena porque los gráficos abren.
Por qué migrar no es copiar y pegar
Muchos proyectos de migración fallan por la misma razón: mueven los informes tal cual, sin cuestionar definiciones, modelo de datos, seguridad ni hábitos de trabajo. El resultado es una plataforma nueva con los problemas viejos, ahora más caros de mantener.
El cambio a Fabric es, en realidad, una oportunidad para simplificar y profesionalizar. Es el momento de preguntar cosas que nadie preguntó cuando los reportes crecieron solos: ¿esta métrica sigue significando lo mismo para todas las áreas?, ¿este informe lo usa alguien?, ¿de dónde sale realmente este número? Migrar bien empieza por ordenar el negocio, no por mover archivos.
El objetivo de fondo es unificar cifras dispersas en un solo lugar confiable, de modo que dirección y equipo vean los mismos números en Excel, Power BI o cualquier IA.
Fase 1: inventariar antes de tocar nada
Antes de migrar un solo informe, necesitas un mapa completo de lo que tienes. Sin inventario, la migración se convierte en adivinanza.
Inventaría al menos esto:
- Informes: cuáles existen, quién los abre y con qué frecuencia.
- Fuentes de datos: de dónde vienen los datos de cada informe.
- Usuarios y permisos: quién ve qué y con qué nivel de seguridad.
- Métricas: cómo se define cada cálculo y si hay definiciones que se contradicen entre áreas.
- Dependencias: qué informes se alimentan de qué modelos y qué se rompe si mueves una pieza.
Este inventario es también tu primera oportunidad de detectar duplicación: la misma métrica calculada de tres formas distintas, o cinco informes que en el fondo responden la misma pregunta.
Fase 2: decidir qué se conserva, se rediseña o se elimina
Con el inventario en la mano, cada informe entra en una de tres categorías. Este triaje es lo que evita arrastrar el caos a la plataforma nueva.
| Decisión | Cuándo aplica | Qué se hace |
|---|---|---|
| Conservar | El diseño sirve y el modelo oficial ya existe | Se migra como informe ligero, sin rehacer la capa de negocio |
| Rediseñar | El informe se usa, pero el modelo o las definiciones están sucios | Se reconstruye sobre el modelo semántico gobernado |
| Eliminar | Nadie lo usa o duplica algo mejor | No se migra |
La tentación es migrar todo por si acaso. Resistir esa tentación es medio proyecto ganado: menos informes, mejor gobernados, valen más que un catálogo enorme donde nadie confía en las cifras. Este triaje es una de las buenas prácticas para la migración a Microsoft Fabric que más ahorran retrabajo después.
Fase 3: construir la base común en OneLake
Antes de reconectar informes, necesitas una base de datos ordenada debajo. En Fabric esa base vive en OneLake, organizada por capas.
Aquí es donde conviene organizar tus datos en capas confiables con arquitectura medallion, que separa los datos en tres niveles: Bronze (datos crudos tal como llegan), Silver (datos limpios y validados) y Gold (datos listos para el negocio, agregados y modelados). Cada capa tiene un contrato claro de qué entra y qué sale, de modo que los informes siempre consumen de la capa correcta y no de una consulta improvisada.
Esta base común es la que sostiene la única verdad: todos los productos de datos, informes y agentes de IA leen del mismo lugar gobernado, no de copias sueltas.
Fase 4: modelos semánticos explícitos, no por defecto
El modelo semántico es el acuerdo formal sobre las métricas del negocio: define qué significa cada cifra, cómo se calcula y cómo se relacionan las tablas. Es la pieza que garantiza que "ventas netas" signifique lo mismo en todos los informes.
Aquí hay un cambio reciente importante. Según la documentación de Microsoft, desde el 5 de septiembre de 2025 la plataforma ya no genera de forma automática los modelos semánticos predeterminados, y los que ya existían pasaron a operar como modelos independientes a partir del 30 de noviembre de 2025. Por eso hoy conviene trabajar con modelos semánticos explícitos y gobernados, no depender de los que la plataforma armaba sola.
Un modelo explícito te da control sobre las definiciones, la seguridad y el versionado. Un modelo por defecto te deja a merced de lo que la herramienta asuma, que rara vez coincide con las reglas reales del negocio.
Fase 5: migrar como informe ligero y reconectar al modelo oficial
Cuando el diseño de un informe sirve y ya existe un modelo semántico oficial, no hace falta duplicar la capa de negocio. Se migra el informe como informe ligero, apuntándolo al modelo correcto. Esta es la práctica que Microsoft sostiene con la operación de reconexión (Rebind Report).
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 (rebind).
- Verifica de nuevo que el
datasetIdapunte al modelo correcto. - Elimina el modelo temporal que quedó huérfano.
- Exporta la definición del informe si el cliente necesita versionado.
Así consolidas sin duplicar: muchos informes, un solo modelo de negocio detrás.
Fase 6: validar con usuarios y reconciliar contra la fuente
Una migración no termina cuando el informe abre. Termina cuando el negocio confía en las cifras.
Valida los resultados con los usuarios reales de cada informe y reconcilia los números contra la fuente aceptada: si el nuevo informe dice algo distinto al reporte que dirección venía usando, hay que explicar por qué antes de dar el paso por cerrado. A veces la diferencia es un error viejo que la migración corrigió; a veces es un error nuevo. Solo la reconciliación lo distingue.
Microsoft describe la migración a Fabric como un proceso de descubrir, evaluar y ejecutar por cargas de trabajo, no como un big bang. Ir por cargas te deja validar cada bloque antes de seguir.
El siguiente paso
Migrar a Fabric es tanto un proyecto técnico como una decisión de negocio: qué métricas importan, quién las define y cómo se gobiernan. Hay caminos distintos según el punto de partida, desde formación para que el equipo gane autonomía hasta consultoría para ordenar la base antes de mover nada. Si quieres ver cómo se aterriza este proceso en una empresa como la tuya, mira la demo gratuita y evalúa por dónde conviene empezar.
Preguntas relacionadas
¿Migrar a Microsoft Fabric significa copiar mis reportes actuales tal cual?
No. Copiar los informes sin cuestionar definiciones, modelo, seguridad ni hábitos es la causa más común de fracaso. La migración es la oportunidad de inventariar, decidir qué se conserva, rediseña o elimina, y reconstruir sobre una base común y modelos gobernados.
¿Por qué debo usar modelos semánticos explícitos y no los predeterminados?
Porque, según la documentación de Microsoft, la creación automática de modelos predeterminados quedó desactivada el 5 de septiembre de 2025, y los modelos ya existentes quedaron separados como independientes desde el 30 de noviembre de 2025. Un modelo explícito te da control sobre definiciones, seguridad y versionado, y fija una definición compartida de cada métrica.
¿Qué es un informe ligero al migrar a Fabric?
Es un informe que reutiliza el diseño existente pero se reconecta al modelo semántico oficial en lugar de duplicar la capa de negocio. Se usa cuando el diseño sirve y ya existe un modelo gobernado, lo que permite consolidar muchos informes sobre un solo modelo.
¿Cómo sé si la migración quedó bien hecha?
La migración no termina cuando el informe abre, sino cuando validas los resultados con los usuarios reales y reconcilias las cifras contra la fuente aceptada. Cualquier diferencia con el reporte anterior debe explicarse antes de dar el trabajo por cerrado.
¿Conviene migrar todo de una vez o por partes?
Por partes. Microsoft describe la migración a Fabric como descubrir, evaluar y ejecutar por cargas de trabajo, no como un cambio total de un solo golpe. Ir por cargas te permite validar cada bloque antes de continuar y reducir el riesgo.