Migrar de Power BI a Microsoft Fabric: guía por fases
La pregunta que nos llega no suele ser si conviene migrar de Power BI a Microsoft Fabric, sino por dónde empezar sin romper los informes que la dirección abre cada lunes. Y ahí es donde casi todas las migraciones se tuercen: se ataca por el lado equivocado, se mueve todo a la vez y se descubre a mitad de camino que la capacidad contratada no da, que los modelos semánticos venían con vicios de origen o que Direct Lake no aplica al caso.
Esta es la guía que nos habría gustado tener la primera vez. Cinco fases, en orden, con los errores concretos que hemos visto costar semanas.
Fase 1. Inventario: qué tienes de verdad
Nadie sabe cuántos informes tiene. Lo que la gente cree que tiene y lo que hay publicado en el tenant se parecen poco. Antes de tocar nada, hay que levantar el mapa real:
- Workspaces y su uso real. Cuántos hay, cuáles tienen tráfico en los últimos 90 días y cuáles llevan dos años sin que nadie los abra. Es habitual que entre un tercio y la mitad del inventario se pueda archivar en lugar de migrar.
- Modelos semánticos y su origen. Import, DirectQuery o composite, y contra qué fuente. Los modelos que apuntan directos a la base de datos operacional son los que más duelen después.
- Dependencias entre informes y modelos. Un modelo compartido por seis informes no se mueve igual que uno dedicado.
- Pasarelas de datos on-premises. Cuáles siguen vivas y quién las mantiene. Suelen estar en el portátil de alguien que ya no está en la empresa.
- Flujos de actualización. Horarios, duraciones y fallos recurrentes del último trimestre.
Este inventario no es burocracia: es lo que determina el tamaño de capacidad que vas a necesitar y el orden en que conviene mover las cosas.
Error habitual en esta fase
Migrar el inventario completo por defecto. Cada informe que mueves es un informe que hay que validar, y la validación es el 60% del esfuerzo real del proyecto. Archivar antes de migrar es la palanca de ahorro más grande que existe en estos proyectos, y la que menos se usa.
Fase 2. Dimensionar la capacidad sin pagar de más
Fabric se factura por capacidad reservada, no por usuario. Eso cambia la aritmética por completo respecto a Power BI Pro, y es donde más dinero se deja o se ahorra.
Dos decisiones importan más que el resto:
- El SKU de partida. La tentación es dimensionar para el pico. Casi siempre sale mejor arrancar por debajo y escalar, porque la capacidad se redimensiona en caliente y el pico real rara vez coincide con el pico estimado.
- El calendario de encendido. Una capacidad encendida las 24 horas cuando el negocio consume datos en horario de oficina es dinero quemado. Programar el apagado nocturno y de fin de semana recorta la factura de forma sustancial, y se automatiza con una canalización. Lo desarrollamos en detalle en ¿conviene apagar la capacidad en Microsoft Fabric?
La contrapartida honesta del apagado: mientras la capacidad está apagada, los informes no responden y las actualizaciones programadas no se disparan. Hay que decidir la ventana con el negocio, no por detrás.
Fase 3. El orden correcto para migrar de Power BI a Microsoft Fabric
El orden importa porque cada capa depende de la anterior. Saltárselo es la causa número uno de migraciones que se alargan.
- Infraestructura y gobierno primero. Workspaces, nomenclatura, roles y separación de entornos. Si defines esto después, acabas renombrando y reasignando permisos con los informes ya en producción.
- La capa de datos. Lakehouse con separación por capas: ingesta cruda, datos limpios y datos listos para consumo. Aquí es donde se paga la deuda técnica acumulada, y donde conviene invertir tiempo.
- Modelos semánticos. Reapuntar a la capa de consumo, no a la cruda. Es el momento de arreglar los modelos que arrastraban tablas de hechos filtrándose a sí mismas o dimensiones duplicadas.
- Informes. Últimos, y con conexión en vivo al modelo. Separar modelo e informe en artefactos distintos es lo que permite que un cambio de medida no obligue a republicar diez informes.
- Observabilidad. Registro de ejecuciones, alertas de fallo y conciliación entre origen y destino. Sin esto, el primer fallo silencioso lo descubre el cliente.
Un detalle que ahorra discusiones: la distribución a usuarios finales se hace mediante aplicaciones, no dando acceso al área de trabajo. Compartir el workspace es una práctica heredada que expone el desarrollo y complica la gestión de permisos.
Si el destino es publicar analítica para clientes y no solo para uso interno, el camino cambia: ahí entra Power BI Embedded y su evolución con Fabric, y conviene decidirlo antes de diseñar la capa de datos.
Fase 4. Direct Lake: cuándo sí y cuándo no
Direct Lake es el argumento estrella de Fabric y también el más malinterpretado. Lee directamente los ficheros Delta del lago sin copiar los datos en memoria ni consultar la fuente en cada interacción. Sobre el papel, lo mejor de Import y de DirectQuery a la vez, y así lo describe la documentación oficial de Microsoft.
En la práctica conviene cuando se dan varias de estas condiciones: el volumen de datos hace inviable el modo Import, los datos ya viven en el lago en formato Delta, y el modelo no depende de transformaciones pesadas en la propia capa semántica.
Y conviene descartarlo, sin dramatismo, cuando el modelo tiene lógica compleja en la capa semántica, cuando hay orígenes que no están en el lago, o cuando el volumen es tan modesto que Import va perfecto y cuesta menos mantenerlo. Elegir Direct Lake porque es lo nuevo, y no porque el caso lo pida, es una forma cara de complicarse.
El detalle que pilla a todo el mundo: el repliegue a DirectQuery
Aquí conviene distinguir dos sabores, porque no se comportan igual. Direct Lake sobre el endpoint SQL tiene un mecanismo de repliegue: si una consulta no se puede resolver leyendo el lago, cae a DirectQuery contra el endpoint SQL. Funciona, pero el rendimiento cambia de golpe y el usuario solo percibe que «el informe va lento a veces». Direct Lake sobre OneLake, en cambio, no repliega: o resuelve en modo Direct Lake o la consulta falla, y es la opción recomendada para modelos nuevos.
Las causas típicas del repliegue son concretas y se pueden auditar: seguridad a nivel de fila definida en el endpoint SQL, tablas construidas sobre vistas no materializadas, o tablas que superan los límites de la capacidad. Para saber qué tabla está replegando y por qué, basta ejecutar la consulta DAX EVALUATE TABLETRAITS() y revisar la columna de motivo. Los detalles y la tabla completa de causas están en la guía de funcionamiento de Direct Lake. Conviene monitorizarlo desde el primer día en lugar de descubrirlo por una queja.
Fase 5. Validar antes de apagar lo viejo
La migración no termina cuando el informe carga en el entorno nuevo. Termina cuando alguien puede afirmar que los números son los mismos. Nuestra lista mínima:
- Conciliación de totales entre origen y destino, por periodo y por dimensión principal. No basta con el gran total: los descuadres se esconden en un año o en una sociedad concreta.
- Comparativa de medidas clave ejecutadas en paralelo en ambos entornos durante al menos un ciclo de cierre completo.
- Pruebas de rendimiento con el volumen real, no con una muestra.
- Verificación de la seguridad a nivel de fila con usuarios reales de cada perfil. Es el punto que más veces se da por bueno sin probar, y el que peores consecuencias tiene.
- Convivencia de entornos durante un periodo acordado antes de apagar el anterior.
Los cinco errores que más caros salen
- Migrar sin archivar. Mover informes que nadie abre multiplica el coste de validación sin aportar nada.
- Dejar el gobierno para el final. Renombrar workspaces y reasignar permisos con producción viva es rehacer trabajo.
- Elegir Direct Lake por defecto. Es una decisión de arquitectura, no un interruptor de modernidad.
- No presupuestar la capacidad apagada. El coste de Fabric se estima con el calendario de encendido en la mano, no con la etiqueta del SKU.
- Validar solo el gran total. Los descuadres viven en el detalle, y aparecen justo cuando ya has apagado el sistema anterior.
Cuánto tarda esto de verdad
Para un inventario mediano, con una decena de modelos y unas decenas de informes, un proyecto bien acotado se mueve en el entorno de las diez semanas: dos de inventario y diseño, cuatro de construcción de la capa de datos y modelos, dos de informes y dos de validación y convivencia. Los proyectos que se van a seis meses casi nunca es por dificultad técnica: es porque nadie decidió qué se archivaba.
Puedes ver cómo abordamos estos proyectos en nuestro servicio de implantación de Microsoft Fabric. Y si estás valorando la migración y quieres una segunda opinión sobre el inventario y el dimensionado, cuéntanos tu caso. Media hora suele bastar para saber si el proyecto es de diez semanas o de seis meses, y por qué.