Si tienes Power BI Premium por capacidad, el destino es Fabric F. Pero el tamaño correcto hay que demostrarlo.
Microsoft ya no vende nuevas capacidades Power BI Premium P y está retirando estas SKU al final del periodo contractual de cada cliente. Para mantener una capacidad organizativa compatible, la ruta es pasar a Microsoft Fabric F.
La migración no se ejecuta sola durante la renovación. La organización debe adquirir una capacidad F, configurar el entorno, reasignar los workspaces, validar funcionamiento y retirar la capacidad P cuando el nuevo escenario esté estabilizado.
Lo que no haría es comprar automáticamente una F64 porque hoy tienes una P1 sin mirar telemetría. La equivalencia sirve como punto de partida técnico, no como sustituto del dimensionamiento.
Power BI Premium por capacidad se retira. Power BI Premium por usuario no.
P1–P5 son capacidades organizativas dedicadas. PPU es una licencia por usuario. El proceso de retirada afecta a las P-SKU por capacidad, no a Power BI Pro ni a Premium Per User.
PPU sigue siendo una opción válida cuando un colectivo reducido necesita funcionalidades Premium de Power BI sin adquirir capacidad organizativa.
Pero PPU no aprovisiona una capacidad Fabric para ejecutar lakehouses, warehouses, notebooks u otras cargas de Fabric no Power BI.
No desaparece Power BI Premium. Cambia la forma de comprar la capacidad y se amplía la plataforma que hay debajo.
Este matiz evita bastante confusión. Microsoft no está eliminando las capacidades avanzadas de Power BI. Está consolidando la compra de capacidad alrededor de Microsoft Fabric y sus F-SKU. Para una organización que hoy solo utiliza Power BI, eso puede parecer un cambio comercial. Para una empresa que quiere integrar ingeniería de datos, warehouse, lakehouse, tiempo real o IA, el cambio puede ser mucho más estratégico.
Power BI Premium P-SKU
Capacidad organizativa comprada bajo el modelo de Power BI Premium. Permitía ejecutar workloads de Power BI en capacidad dedicada y distribuir contenido a usuarios gratuitos bajo las condiciones aplicables.
En clientes existentes podía además habilitarse Fabric sobre la capacidad P, pero el modelo de compra P está siendo retirado.
Capacidad Microsoft Fabric F-SKU
La capacidad F se adquiere a través de Azure y se mide mediante Capacity Units. Sirve para Power BI y para el resto de experiencias de Fabric compatibles con la SKU y configuración.
Puede utilizarse con pago por uso y, cuando existe consumo estable y el modelo comercial lo permite, con reserva para optimizar coste.
P1 no “se convierte” mágicamente en F64. F64 es su equivalencia de capacidad de referencia.
Microsoft publica una correspondencia basada en potencia de capacidad. Cada v-core de una P-SKU equivale a ocho Capacity Units. Esta tabla es útil para establecer un punto de partida, pero no sustituye una evaluación de utilización, concurrencia, picos, modelos semánticos, refresh, direct lake, pipelines u otras cargas que vayan a entrar en Fabric.
| Power BI Premium | Fabric de referencia | Capacity Units | Qué haría antes de comprar |
|---|---|---|---|
| P1 | F64 | 64 CU | Confirmar que el patrón de consumo y el modelo de viewers justifican F64 frente a una F menor + licencias Pro. |
| P2 | F128 | 128 CU | Analizar promedio, picos, throttling, workloads y posibles oportunidades de right-sizing. |
| P3 | F256 | 256 CU | Separar consumos por workspace y evaluar si conviene una única capacidad o varias capacidades por criticidad y dominio. |
| P4 | F512 | 512 CU | Revisar arquitectura, aislamiento, ventanas de proceso y coste antes de replicar automáticamente la huella actual. |
| P5 | F1024 | 1024 CU | Tratarlo como programa de plataforma: consumo, dominios, gobierno, operación, FinOps y crecimiento futuro. |
Una equivalencia de potencia no es una recomendación económica.
Una P1 infrautilizada puede no necesitar una F64 por capacidad pura. Pero bajar de F64 cambia una regla muy importante de Power BI: los usuarios Free ya no pueden consumir contenido Power BI alojado en esa capacidad y necesitarán Pro, PPU o una licencia individual válida. Por eso capacidad y licencias deben modelarse juntas.
F64 puede ser una decisión de licenciamiento antes que una decisión de rendimiento
Este es uno de los puntos que más se mezclan en las conversaciones sobre Fabric. F64 no es “la SKU buena” y las anteriores no son versiones incompletas. F2, F4, F8, F16 y F32 pueden ejecutar workloads de Fabric. La diferencia crítica para Power BI aparece en el modelo de consumo por usuarios gratuitos.
Fabric sí. Viewers Free de Power BI, no.
Las capacidades inferiores a F64 permiten utilizar experiencias de Microsoft Fabric, pero un usuario que consuma contenido Power BI en esos workspaces necesita Pro, PPU o una licencia individual aplicable.
Para una organización con pocos consumidores, esto puede ser perfectamente razonable y económicamente más eficiente.
Los viewers pueden consumir con licencia Free
Con una F64 o superior, usuarios con licencia Fabric Free y rol Viewer pueden visualizar contenido Power BI alojado completamente en esa capacidad, bajo las reglas documentadas por Microsoft.
En organizaciones con cientos o miles de consumidores, esta diferencia puede tener más impacto económico que el propio dimensionamiento técnico.
Ejemplo sencillo
Si tienes 40 autores y 1.500 consumidores de informes, comparar F32 con F64 solo por CUs sería incompleto. Una F32 puede bastar en compute, pero obligaría a revisar licencias de consumo de Power BI. Una F64 puede estar sobredimensionada en cómputo y, aun así, tener sentido por distribución masiva. El business case debe incluir ambas variables.
El periodo de gracia existe para recuperarte de un problema, no para planificar la migración
Microsoft indica que, cuando termina la suscripción P, existe un periodo de gracia de 30 días. Después, entre los días 31 y 90, el acceso se limita mediante throttling y las operaciones interactivas pueden retrasarse. A partir del día 91, las operaciones son rechazadas hasta que los workspaces se migren a una capacidad F o se elimine la capacidad.
El dato se conserva, pero “el dato sigue ahí” no es una estrategia de continuidad. Si Power BI soporta reporting financiero, ventas, supply chain, operaciones o cuadros de mando ejecutivos, esperar a la expiración contractual introduce un riesgo totalmente evitable.
La secuencia recomendable es mucho más simple: comprar la F mientras la P sigue activa, preparar la nueva capacidad, reasignar workspaces, validar, observar consumo y solo después retirar el escenario anterior.
Si algo falla, todavía tienes margen para corregir sin convertir una decisión de licencias en una incidencia de negocio.
Ocho pasos para pasar de Power BI Premium P a Fabric F sin convertir la renovación en un salto al vacío
El procedimiento técnico de reasignar workspaces es solo una parte. Una migración bien preparada necesita baseline, licencias, capacidad, configuración, validación y operación.
Saber qué depende realmente de la capacidad P
Capacidades, workspaces, modelos semánticos, dataflows, refresh, gateways, informes, usuarios, apps, dependencias, conexiones, administradores y criticidad de cada servicio.
Medir antes de decidir la F-SKU
Utilización, picos, throttling, refresh, consultas, horarios críticos, tamaño de modelos, memoria y comportamiento por workspace. Sin baseline, el dimensionamiento es una opinión.
Separar autores, colaboradores y viewers
Contar usuarios Pro, PPU, Free y necesidades de distribución. El número de consumidores puede cambiar por completo la comparación F32 versus F64.
Crear la capacidad F antes de retirar P
Región, administradores, networking cuando aplique, configuración tenant, acceso, monitorización, presupuesto y ownership deben quedar definidos antes de mover cargas críticas.
No mover todo el viernes a las 18:00
Empieza con workspaces representativos y de riesgo controlado. Valida comportamiento, licencias, rendimiento y operación antes de trasladar reporting crítico.
Comparar antes y después
Refresh, consultas, apps, gateways, RLS, permisos, suscripciones, alertas, distribución, rendimiento y experiencia de usuarios. No basta con que el informe abra.
Confirmar el dimensionamiento con uso real
Traslada suficientes cargas para observar patrones representativos y revisa Capacity Metrics antes de concluir que el tamaño inicial es definitivo.
Cerrar P cuando F ya está estable
Solo cuando todos los workspaces estén reasignados, validados y operados correctamente tiene sentido cerrar la capacidad anterior y consolidar el nuevo modelo.
Una migración P → F es el momento perfecto para dejar de pagar por una capacidad heredada que nadie cuestiona
Muchas capacidades Premium se dimensionaron hace años, cuando el parque de informes, la arquitectura y los patrones de consumo eran diferentes. Algunas crecieron añadiendo capacidad cada vez que aparecía un problema de rendimiento. Otras se compraron con margen “por si acaso” y nunca se revisaron.
Copiar P1 → F64, P2 → F128 o P3 → F256 reproduce esas decisiones sin comprobar si siguen siendo válidas.
Microsoft Fabric permite observar consumo mediante la Capacity Metrics app y analizar operaciones, smoothing, picos y comportamiento de workloads. Ese dato debería formar parte de la decisión.
El objetivo no es bajar de SKU a cualquier precio. Es pagar la capacidad que necesitas y entender por qué.
Qué revisaría antes de mantener la equivalencia 1:1
No compares “precio P” contra “precio F”. Compara la arquitectura y el modelo de consumo completos.
La P-SKU y la F-SKU pertenecen a modelos de compra distintos. Fabric se adquiere sobre Azure y puede combinar pago por uso y reserva. Pero la capacidad es solo una línea del coste.
Capacidad F
SKU, región, horas activas, consumo y modelo de compra.
Licencias Power BI
Pro, PPU o Free según rol, workspace y tamaño de la capacidad.
OneLake y almacenamiento
Especialmente relevante cuando la plataforma empieza a utilizar workloads más allá de Power BI.
Migración
Assessment, pruebas, workspaces, validación, administración y soporte durante la transición.
Operación y FinOps
Monitorización, ownership, presupuestos, alertas, optimización y revisiones periódicas.
Valor adicional
Ingeniería, lakehouse, warehouse, ciencia de datos, tiempo real y preparación para IA que antes podían requerir otras plataformas.
Para el usuario de Power BI, la migración bien ejecutada debería ser bastante menos dramática de lo que parece
El objetivo no es reconstruir informes ni convertir automáticamente todo en un proyecto de data platform. La mayor parte del valor está precisamente en poder mover la capacidad que soporta los workspaces y seguir operando Power BI mientras se decide qué nuevas capacidades Fabric merece la pena adoptar.
Los informes no tienen por qué rediseñarse
La migración de capacidad no implica rehacer visualizaciones simplemente porque el workspace pasa a una F-SKU.
Power BI sigue siendo Power BI
Fabric no sustituye la experiencia Power BI. La integra dentro de una plataforma de datos más amplia.
Los workspaces siguen siendo la unidad operativa clave
La reasignación de workspaces a la nueva capacidad es uno de los pasos centrales del cambio.
Lo que sí cambia es la plataforma disponible debajo
La organización puede decidir posteriormente incorporar lakehouse, warehouse, Data Factory, notebooks, real-time intelligence u otras experiencias de Fabric.
Migrar de P a F no obliga a transformar toda tu arquitectura de datos el mismo día
Existe una tentación comprensible: aprovechar la transición para rediseñar modelos, mover datos a OneLake, implantar lakehouse, sustituir dataflows, introducir notebooks, cambiar gateways, revisar seguridad y reconstruir toda la plataforma.
Puede ser correcto en organizaciones que ya tenían un programa de modernización definido. Pero hacerlo únicamente porque expira una P-SKU mezcla un cambio necesario con una transformación mucho mayor.
Una estrategia más prudente suele separar dos decisiones. Primero, garantizar continuidad y optimizar capacidad y licencias. Después, evaluar qué workloads Fabric aportan valor y en qué orden.
No conviertas una renovación que debe ser controlada en un big bang tecnológico si el negocio no lo necesita.
La migración más simple es la que no introduce una mudanza regional que nadie necesitaba
La región de la capacidad condiciona residencia, latencia, disponibilidad de características y el diseño de la migración. Cuando P y F pueden mantenerse en la misma región, el camino suele ser mucho más directo.
Si la organización quiere aprovechar el cambio para trasladarse de región, consolidar tenants o cambiar arquitectura, el proyecto deja de ser una simple reasignación de capacidad y necesita un análisis específico.
También conviene revisar escenarios con requisitos regulatorios, residencia de datos, conectividad híbrida, gateways, Private Link u otras restricciones corporativas.
La regla práctica es sencilla: no añadas complejidad arquitectónica a la migración P → F salvo que exista un motivo claro y aprobado para hacerlo.
Cinco preguntas de arquitectura
El mayor cambio no es P → F. Es pasar de una capacidad “de Power BI” a una capacidad compartida por una plataforma de datos
Cuando Fabric empieza a utilizarse más allá de Power BI, nuevos equipos pueden crear pipelines, notebooks, warehouses, lakehouses o cargas en tiempo real sobre el mismo pool de cómputo. Eso modifica el modelo operativo.
Quién responde por la capacidad
No puede ser “el equipo de Power BI” si ingeniería, datos, IA y negocio empiezan a consumir el mismo recurso.
Cómo se organizan workspaces y cargas
Separación por dominio, criticidad, entorno o producto para evitar que una carga experimental afecte al reporting financiero.
Cómo se asigna el coste
Presupuestos, responsables, alertas, imputación y conversaciones periódicas entre plataforma, datos, finanzas y negocio.
Qué cargas no pueden competir entre sí
El reporting crítico, procesos batch, ciencia de datos y pruebas necesitan reglas de convivencia y, cuando corresponda, capacidades separadas.
La comparación económica que debería hacerse antes de comprar F64 por inercia
Hay organizaciones para las que F64 es claramente la opción más coherente. Hay otras en las que una capacidad menor puede cubrir perfectamente el cómputo y el coste total depende sobre todo de cuántos usuarios necesitan consumir Power BI. La única forma seria de decidirlo es modelar ambas arquitecturas.
Capacidad menor + licencias por usuario
Imagina que una F32 cubre de sobra el consumo real de tus workloads. Si tienes 80 consumidores y todos pueden disponer de Pro por razones de colaboración o por licencias ya existentes, pagar F64 solo para habilitar viewers Free puede no tener sentido.
En ese caso, la decisión debe sumar capacidad F32, licencias de los usuarios que crean y consumen contenido, crecimiento previsto y cualquier carga adicional de Fabric.
Es un escenario especialmente interesante cuando el número de usuarios es limitado, la capacidad actual está infrautilizada o buena parte de los consumidores ya tiene Power BI Pro por otro motivo.
F64 + usuarios Free para consumo
Ahora imagina 2.000 consumidores que únicamente consultan informes y apps. En ese escenario, la capacidad puede parecer más grande de lo necesario desde la perspectiva técnica, pero el ahorro en licencias individuales puede cambiar completamente el business case.
Además, F64 abre margen para incorporar nuevas cargas Fabric. Ese valor solo debe contabilizarse si existe un roadmap real, no como una promesa genérica de futuro.
La decisión correcta combina número de viewers, licencias existentes, potencia necesaria, crecimiento, uso de Fabric y coste total durante el periodo que quiera modelarse.
No existe un umbral universal de usuarios
No usaría reglas como “a partir de X usuarios compensa F64” sin calcular precios, acuerdos comerciales, licencias ya incluidas, región, reserva y crecimiento. Dos empresas con el mismo número de usuarios pueden llegar a conclusiones distintas porque una ya tiene Pro para todos y otra solo necesita viewers. La calculadora debe utilizar tus datos, no una cifra sacada de una comparativa genérica.
Qué debería estar resuelto antes de mover un workspace crítico a la capacidad F
El objetivo de este checklist no es crear burocracia. Es evitar que la migración dependa de conocimiento implícito de dos administradores y de que “normalmente esto funciona”.
La F-SKU existe, está en la región prevista y tiene responsables claros.
Sabemos quién crea, comparte y consume contenido y qué licencia necesita después del cambio.
Tenemos tiempos de refresh, consultas y métricas anteriores con las que comparar.
Gateways, fuentes, credenciales, apps, suscripciones y automatizaciones están identificadas.
Alguien del negocio puede confirmar que el contenido funciona como debe, no solo que carga.
Existe una franja de cambio, responsables y procedimiento de escalado si aparece una incidencia.
El equipo puede observar consumo inmediatamente después del movimiento.
Rendimiento, refresh, acceso, distribución y coste tienen una definición clara de “funciona correctamente”.
Ocho formas de convertir una migración relativamente controlable en un problema innecesario
El periodo de gracia es un salvavidas, no un calendario de proyecto.
Puede conservar sobrecapacidad histórica o ignorar nuevas cargas Fabric.
F64 puede ser necesaria por el modelo de viewers aunque F32 cubra el cómputo.
Premium Per User no forma parte de la retirada de capacidades P.
Una oleada piloto reduce mucho el riesgo y mejora el aprendizaje.
Puede mezclar continuidad con una transformación de datos que merece su propio business case.
Una capacidad Fabric compartida por más workloads necesita ownership y revisión continua.
La migración termina cuando rendimiento, licencias, distribución, coste y operación están validados.
Qué decisión evaluaría según la situación actual de Power BI
P1 con cientos de viewers gratuitos
F64 es la primera referencia lógica porque mantiene el modelo de visualización Free en capacidad. Después comprobaría si el cómputo está sobrado y cuánto valor económico tiene conservar ese patrón de distribución.
P1 con pocos usuarios y capacidad muy infrautilizada
Evaluaría una F menor junto con el coste de licencias Pro/PPU. Puede ser más eficiente si el número de consumers es reducido y no se necesita F64 por distribución.
P2/P3 con throttling recurrente
No asumiría que hace falta escalar. Primero separaría ineficiencia, picos previsibles y falta real de compute. La migración permite corregir arquitectura antes de perpetuar el problema.
Power BI estable y roadmap de Fabric
Mantendría continuidad de Power BI y reservaría capacidad para nuevas cargas de datos de forma controlada, midiendo cómo comparten CUs antes de ampliar alcance.
PPU para un equipo pequeño
No existe obligación de migrar por la retirada P porque PPU no está afectado. Solo evaluaría una F si la organización necesita capacidad Fabric o cambia su modelo de distribución.
Gran organización con múltiples capacidades P
Trataría la migración como un programa de plataforma: consolidar o separar capacidades, revisar dominios, SLAs, ownership, costes y estrategia Fabric en lugar de hacer una conversión capacidad por capacidad.
Dudas habituales al migrar Power BI Premium a Microsoft Fabric
¿Power BI Premium desaparece?
Microsoft está retirando Power BI Premium por capacidad, las P-SKU P1–P5. Las funcionalidades Premium de Power BI continúan disponibles dentro del modelo de capacidad Fabric. Power BI Pro y Premium Per User no están afectados por esta retirada.
¿P1 equivale a F64?
Sí como referencia de potencia: P1 se corresponde con F64 y 64 Capacity Units. Pero Microsoft recomienda right-sizing, porque el consumo real y el modelo de usuarios pueden justificar otra decisión.
¿P2 equivale a F128 y P3 a F256?
Sí como correspondencia de capacidad publicada por Microsoft: P2 → F128, P3 → F256, P4 → F512 y P5 → F1024. No debe interpretarse como una recomendación automática de compra.
¿La migración de P a F es automática?
No. La organización debe adquirir una capacidad F y reasignar los workspaces. Es recomendable hacerlo antes de finalizar la suscripción P y validar el nuevo entorno antes de retirar el anterior.
¿Necesito F64 para usar Microsoft Fabric?
No. Fabric dispone de capacidades menores como F2, F4, F8, F16 y F32. F64 adquiere especial relevancia en Power BI porque permite que usuarios Free con rol Viewer consuman contenido alojado completamente en esa capacidad.
¿Qué ocurre si termina mi P-SKU antes de migrar?
Microsoft establece 30 días de gracia. Entre los días 31 y 90 el acceso se limita y las operaciones interactivas pueden sufrir retrasos. Desde el día 91 las operaciones son rechazadas hasta migrar o eliminar la capacidad. No conviene utilizar este periodo como calendario planificado.
¿Premium Per User también se retira?
No. PPU es una licencia por usuario distinta de las capacidades P y continúa activa. Tampoco aprovisiona por sí sola capacidad para workloads Fabric no Power BI.
¿Tengo que rehacer mis informes?
No por el hecho de migrar la capacidad. La finalidad de la transición P → F es mantener los workloads funcionando sobre la nueva capacidad. Cualquier modernización adicional debería responder a un caso de negocio propio.
¿Cómo sé qué F-SKU necesito?
Combina la equivalencia inicial con Capacity Metrics, patrones de consumo, picos, usuarios, modelo de licencias, nuevos workloads y crecimiento. El tamaño correcto no se decide únicamente por el número de informes o usuarios.
¿Puedo migrar primero y adoptar Fabric después?
Sí. De hecho, muchas organizaciones pueden reducir riesgo separando la continuidad de Power BI de la adopción posterior de lakehouse, warehouse, ingeniería de datos, tiempo real o IA.
Migrar capacidad es fácil. Decidir capacidad, licencias y arquitectura sin pagar de más es la parte que merece análisis.
Ayesa trabaja Microsoft Fabric, Power BI, Azure, integración, gobierno de datos e inteligencia artificial desde una visión de plataforma. Esto permite analizar la migración P → F sin convertirla automáticamente en un proyecto de transformación más grande de lo necesario.
El trabajo puede empezar por algo muy concreto: inventario, consumo actual, usuarios, fecha contractual, equivalencia de capacidad y escenarios de coste. A partir de ahí se decide si la ruta correcta es mantener una equivalencia, reducir, escalar o separar cargas.
Si además existe un roadmap de Microsoft Fabric, la nueva capacidad puede diseñarse para incorporar lakehouse, warehouse, ingeniería, analítica avanzada o IA con un modelo de gobierno que evite que Power BI termine compitiendo por recursos con todo lo demás.
Qué debería salir de un assessment P → F
La transición tiene reglas concretas: compruébalas antes de cerrar el plan
Microsoft mantiene documentación específica sobre retirada de P-SKU, equivalencias, right-sizing, licencias y procedimiento de migración. Conviene revisar siempre la versión vigente y las condiciones contractuales concretas de cada organización.
No esperes a la renovación para descubrir que P1 → F64 era solo el principio de la conversación
La transición de Power BI Premium a Microsoft Fabric tiene una parte obligatoria y una parte estratégica. La obligatoria es abandonar la capacidad P cuando termine su vigencia. La estratégica es decidir cómo utilizar ese momento para corregir dimensionamiento, ordenar licencias y preparar la plataforma que realmente necesita la organización.
La mejor migración no es la que mueve más rápido todos los workspaces. Es la que mantiene continuidad, reduce incertidumbre de coste y deja una capacidad que pueda crecer con Power BI y Fabric sin obligarte a rehacer la decisión seis meses después.
¿Tenéis una P1, P2 o P3 y todavía no está claro qué capacidad Fabric necesitáis?
Podemos revisar fecha contractual, workspaces, métricas de capacidad, usuarios, modelo de distribución y roadmap Fabric para definir una transición P → F con continuidad y un dimensionamiento defendible.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)