Introducción a la migración de Power BI Premium a Microsoft Fabric

Microsoft está retirando Power BI SKU Premium por capacidad (SKU P). Cada suscripción de SKU de P finaliza al final de su período de contrato actual y Microsoft ya no vende nuevas SKU de P. Para mantener las cargas de trabajo de Power BI en ejecución, migre a SKU de capacidad de Microsoft Fabric (SKU F). En este artículo se proporciona una vista de un extremo a otro de la migración: por qué Fabric SKU F son la ruta de avance, qué cambios y qué permanece igual para los usuarios finales y administradores, las fases de una migración típica y los escenarios que determinan la complejidad de la migración.

Este artículo es para administradores de Fabric, administradores de Power BI, arquitectos de TI y propietarios de capacidad que planean y ejecutan la migración.

Importante

Planee completar la migración antes de que finalice la suscripción de SKU P. Una vez finalizada la suscripción, la capacidad entra en un período de gracia de 30 días. A partir del día 31, el acceso se limita (las operaciones interactivas se retrasan). A partir del día 91, se rechazan todas las operaciones; los datos se conservan, pero quedan inaccesibles hasta migrar las áreas de trabajo a una capacidad Fabric F SKU o eliminar la capacidad. Para evitar interrupciones, reasigne sus espacios de trabajo a una capacidad Fabric F SKU antes de que finalice su suscripción P SKU. Para obtener el procedimiento, consulte Migración de áreas de trabajo de Power BI Premium a Microsoft Fabric.

Note

Clientes del Contrato Enterprise. Si su Enterprise Agreement sigue activo, puede seguir usando la capacidad existente de SKU P y renovarla anualmente a través de este acuerdo hasta que finalice la vigencia del EA. Los clientes con contratos Enterprise que expiran o los contratos de Microsoft Cloud no pueden agregar ni comprar nueva capacidad de SKU P a través de su contrato. Confirme los términos de contrato específicos con su representante de cuenta Microsoft antes de decidir cuándo migrar.

Note

Esta retirada tiene dos límites de ámbito importantes:

Las licencias por usuario no se ven afectadas.Power BI Pro y Power BI Premium por usuario (PPU) continúan as-is. Para obtener más información, consulte ¿Se va a retirar también Power BI Premium por usuario (PPU)?
Las licencias incrustadas (EM, A) no se ven afectadas. Estas SKU no forman parte de esta retirada.
Las nubes soberanas aún no se ven afectadas. Microsoft Fabric no está disponible en nubes soberanas, por lo que las SKU P siguen siendo compatibles allí. Microsoft proporciona orientaciones específicas cuando Fabric esté disponible en esos entornos.

¿Por qué migrar a Microsoft Fabric

La retirada de las SKU P es el motivo inmediato, pero las SKU F de Fabric también ofrecen capacidades que las SKU P no pueden ofrecer:

Solo se paga lo que se usa. Las SKU F usan de forma predeterminada la facturación de Azure de pago por uso, con reservas anuales o multianuales opcionales para cargas de trabajo predecibles. También puede pausar una capacidad cuando está inactiva para detener la facturación durante las horas fuera del horario laboral y, posteriormente, reanudarla a petición.
Aumente o reduzca la escala en cualquier momento. Cambie el tamaño de las capacidades a través del portal de Azure a medida que cambien las cargas de trabajo, en lugar de confirmar un tamaño fijo para el término de una suscripción.
Use el modelo operativo nativo Azure. Aprovisione y administre la capacidad a través del portal de Azure, aplique etiquetas de Azure para la imputación de costes y haga que el gasto de Fabric cuente para su Compromiso de Consumo de Microsoft Azure (MACC). Muchas cargas de trabajo de Fabric (como Lakehouses, almacenes de datos, notebooks y canalizaciones de Data Factory) se ejecutan en capacidades P o F, pero el modelo operativo de Azure es exclusivamente F.
Use Power BI Embedded sin SKU por separado. Todas las SKU F cubren escenarios integrados, por lo que no necesitas SKU EM o A independientes.
Use la seguridad y las operaciones nativas de Azure. Los puntos de conexión privados administrados, el acceso de confianza al espacio de trabajo, Azure Monitor y Microsoft Cost Management están disponibles con las SKU F.

Para obtener la comparación completa de características por característica, consulte Diferencias clave entre las SKU P premium de Power BI y las SKU de Fabric F.

Qué cambios y lo que sigue siendo el mismo

La migración implica principalmente un cambio de infraestructura y licencias. Las experiencias del usuario final y la mayoría de los comportamientos administrativos permanecen iguales. Algunas áreas operativas cambian.

Area	¿Cambio?	Después de migrar a la SKU F
Informes, modelos semánticos, paneles	Iguales	Sigue funcionando sin cambios con capacidades F64 o superiores.
Licencias de usuario (Pro, PPU, Gratis)	Iguales	Inalterado. En F64 y superiores, los usuarios con una licencia Fabric Free y el rol de Visor pueden ver contenido, al igual que en las SKU P. De F2 a F32, todos los usuarios necesitan una licencia Pro o PPU.
Áreas de trabajo y aplicaciones	Iguales	Las áreas de trabajo se reasignan a la nueva capacidad. Las aplicaciones del área de trabajo, las canalizaciones de implementación y la integración de Git siguen funcionando.
Programaciones de actualización y canalizaciones	Iguales	Continuar funcionando con la nueva capacidad. Es posible que se interrumpan las actualizaciones activas durante la reasignación.
Servidor de informes de Power BI	Igual, con el cambio de licencia	Sigue estando disponible con una reserva de capacidad de Fabric o con SQL Server Enterprise Edition con Software Assurance.
Power BI Embedded	Igual, más sencillo	Se incluye con cada SKU F. No se requieren SKU independientes para EM y A.
Compra y facturación	Changes	Cambiar de la facturación por compromiso de Microsoft 365 a la facturación de Azure. Las SKU F admiten pago por uso y reservas anuales o plurianuales.
Administración de la capacidad	Changes	Se administra principalmente a través del portal de Fabric (asignaciones de área de trabajo y configuración de nivel de capacidad). Las operaciones de pausa, reanudación, escalado y reducción de escala se realizan desde el portal de Azure.
Autoscale	Changes	La escalabilidad automática de SKU P no existe en las SKU F. En su lugar, las SKU F usan el redimensionamiento bajo demanda: se amplían o reducen manualmente desde el portal de Azure.
Gobernanza de capacidad	Nuevas funcionalidades	Las nuevas funciones de gobierno de costes están disponibles en las SKU F, como la protección frente a picos a nivel de espacio de trabajo y la protección contra excesos de capacidad. Úselos para controlar el consumo y evitar que los costes se disparen.
Compatibilidad de elementos entre regiones	Nueva consideración	Los elementos Power BI estándar sobreviven a una reasignación entre regiones. Los modelos semánticos de formato de almacenamiento grande requieren una copia de seguridad y una restauración, o bien el borrado y la conversión al formato de almacenamiento pequeño, antes de volver a asignarlos. Todos los elementos de Fabric (Lakehouses, Warehouses, Notebooks, canalizaciones de Data Factory) provocan un error en la reasignación.

Recorrido de migración de un vistazo

En su forma más pura, la migración de P a F es un movimiento de 1:1 a la SKU F equivalente en la misma región de Azure. Los clientes suelen usar la migración como una oportunidad para consolidar capacidades, moverse entre regiones o cambiar el tamaño. Cada uno de estos cambios agrega complejidad y riesgo. Trate estos cambios como secuencias de trabajo independientes que se ejecutan después de que se complete la migración de licencias.

La migración sigue las mismas cinco fases, independientemente del tamaño o la complejidad.

Decidir. Elija cuándo migrar, con qué SKU de F empezará y si desea permanecer en la misma región de Azure. Consulte la guía de decisiones sobre la migración a Power BI Premium P SKU.
Plan. Inventariar los espacios de trabajo, establecer el consumo de CU de referencia mediante la aplicación Microsoft Fabric Capacity Metrics y estimar el consumo futuro con Fabric SKU Estimator. Registre el Microsoft.Fabric proveedor de recursos en Azure y elija un área de trabajo piloto. Para la validación práctica antes de la compra, aprovisione una capacidad de prueba Fabric para probar las cargas de trabajo.
Aprovisionamiento. Comprar la SKU F antes de reasignar nada. Elija entre pago por uso o una reserva y compruebe las licencias de Power BI Report Server si lo usa.
Migración y validación. Vuelva a asignar áreas de trabajo en el portal de administración de Fabric o mediante el cuaderno de migración de capacidad. Para los traslados entre regiones, vuelva a crear los modelos semánticos con formato de almacenamiento grande y los elementos de Fabric en la nueva región. Valide las actualizaciones, los informes y las puertas de enlace. Consulte Migración de áreas de trabajo de Power BI Premium a Microsoft Fabric.
Desmantelar y operar. La cancelación de SKU P es manual: Fabric no retira automáticamente la SKU P al aprovisionar una SKU de F. Después de validar la migración, cancele explícitamente la suscripción de SKU P en el Centro de administración de Microsoft 365. A continuación, configure la supervisión de costos mediante Microsoft Cost Management y aproveche la flexibilidad de pausa, reanudación y escalado en Fabric.

Escenarios de migración

La mayoría de los clientes se dividen en uno de los cuatro escenarios siguientes. Los tres primeros escenarios siguen los pasos de migración estándar en Migración de áreas de trabajo de Power BI Premium a Microsoft Fabric.

Escenario	Complexity	Notas
Mismo inquilino, misma región	Bajo	El valor predeterminado recomendado. Reasigne cada espacio de trabajo a la nueva SKU F. Se esperaba un tiempo de inactividad cero aparte de las actualizaciones activas.
Mismo inquilino, entre regiones	Moderado a alto	Sigue los pasos de migración estándar, pero los modelos semánticos de formato de almacenamiento grande y los elementos de Fabric deben realizar copias de seguridad o capturarse en Git, eliminarlos y volver a crearse en la nueva región. Consulte Migraciones entre regiones: Control especial.
Multigeo (varias SKU F en distintas regiones, mismo tenant)	Moderado	Sigue los pasos estándar de migración, pero compra SKUs F en cada región de destino y planifica la gobernanza del contenido específico de cada región. Consulte Migraciones multigeo.
Entre inquilinos	Alto; no se admite como migración con un solo clic	No sigue los pasos de migración estándar. Requiere la recreación manual de puertas de enlace, modelos semánticos, áreas de trabajo, informes, aplicaciones y paneles. Considere primero multigeo. Consulte Migraciones entre inquilinos.

Caution

Las migraciones entre regiones implican mucho más esfuerzo que las migraciones de la misma región. Más allá de los tipos de elementos que no sobreviven a la reasignación entre regiones, planee:

Los elementos de Fabric no sobreviven a los movimientos entre regiones. Las canalizaciones de Lakehouses, Warehouses, Notebooks y Data Factory provocan un error en la reasignación. Capture sus definiciones en Git (o expórtelas) antes de reasignarlas y vuelva a crearlas en la región de destino.
Revinculación de informes. Al realizar copias de seguridad y restaurar (o eliminar y volver a implementar) un modelo semántico de formato de almacenamiento grande, el modelo recreado obtiene un nuevo GUID. Los informes a los que se hace referencia al modelo original deben volver a enlazarse al modelo recreado.
Sobrecarga del gateway. Los destinos entre regiones suelen requerir configuración y validación adicionales de las puertas de enlace de datos locales, especialmente si las puertas de enlace usan Azure Relay con Bring Your Own Relay (BYOR), ya que los puntos de conexión de retransmisión están vinculados a una región.

Elija la migración entre regiones solo cuando la residencia de datos u otra restricción dura lo requiera. La migración en la misma región es la opción predeterminada recomendada.

Después de migrar

Después de reasignar las áreas de trabajo y validar que los informes y las actualizaciones funcionan en la nueva SKU F, tómese un periodo de estabilización antes de cancelar la SKU P y de emprender cualquier modernización opcional. Las siguientes actividades le ayudan a confirmar que la migración se completó correctamente y a decidir qué hacer a continuación.

Estabilización del costo

El gasto de la SKU F es predecible si se mantienen las capacidades en ejecución las 24 horas del día. El costo mensual permanece estable, aunque las tarifas de pago por uso suelen ser más altas que la SKU P equivalente. Use reservas para garantizar el ahorro en cargas de trabajo estables y use las funciones de pausa y reanudación para las capacidades que realmente permanecen inactivas durante parte del día. Para estabilizar el costo:

Realice un seguimiento del gasto diario durante los primeros 30 días mediante Microsoft Cost Management.
Configure presupuestos y alertas de Azure en el grupo de recursos de la capacidad para que se le notifique antes de que el gasto supere lo previsto.
Evalúe una reserva de capacidad anual Fabric una vez que el consumo diario sea estable. Normalmente, las reservas descuentan las cargas de trabajo predecibles.
Pon en pausa las capacidades inactivas fuera del horario laboral para detener la facturación en esas franjas horarias.

Estabilización del rendimiento

Para una migración 1:1 dentro de la misma región a la SKU F equivalente, el consumo de CU debería aproximarse mucho al valor de referencia de su SKU P una vez estabilizado. Espere una variación de rendimiento cuando la migración incluya un cambio de configuración (una región diferente, otro tamaño de SKU o consolidación de cargas de trabajo) y valide antes de retirar la SKU P. Las sobrecargas notificadas después de la migración suelen deberse a cambios de carga de trabajo (una ráfaga de actualizaciones, contenido agregado, programaciones de actualización modificadas) en lugar de la propia migración. Compruebe los patrones de uso antes de suponer que la SKU de F es la causa. Para estabilizar el rendimiento:

Supervise la nueva capacidad con la aplicación Métricas de capacidad de Microsoft Fabric durante una o dos semanas después del cambio.
Compárelo con la línea de base que capturó en el SKU P. Investigue diferencias grandes en la frecuencia de actualización, el tamaño del conjunto de datos o la carga interactiva antes de cambiar el tamaño.
Aumente la escala según sea necesario desde el portal de Azure si observa una limitación de velocidad continuada. Consulte Aumente su capacidad.
Valide durante todo un ciclo de negocio completo —incluya el cierre de mes y el cierre trimestral— antes de considerar definitiva la línea base.
Vuelva a comprobar la línea base siempre que agregue contenido nuevo significativo o cambie las programaciones de actualización.
Vuelva a validar después de cualquier cambio de configuración al final (tamaño de SKU, región, asignación de carga de trabajo).
Para obtener instrucciones más amplias sobre el planeamiento del crecimiento de la capacidad y la gobernanza, consulte Microsoft Fabric guía de planeamiento de la capacidad.

Revisión de operaciones y gobernanza

Algunas configuraciones operativas no se conservan automáticamente cuando las áreas de trabajo se migran a una SKU F. Revise lo siguiente:

Confirme las asignaciones de RBAC de Azure en el recurso de capacidad para que los administradores correctos puedan administrarlo.
Vuelva a aplicar la configuración de carga de trabajo a nivel de capacidad (por ejemplo, los límites de memoria del modelo semántico) en el portal de administración de Fabric si se habían personalizado en la SKU P.
Vuelva a revisar la configuración de inquilino Los usuarios pueden crear elementos de Fabric y cualquier delegación de ámbito de capacidad.
Aplique etiquetas de Azure al recurso de capacidad para que los informes de contracargo y showback atribuyan el gasto al centro de costes adecuado.
Evalúe las nuevas características de gobernanza de uso de capacidad disponibles en las SKU F (como la protección de sobrecarga de nivel de área de trabajo y la protección contra el uso por encima del límite) para establecer límites de protección antes de abrir la capacidad para un consumo más amplio.

Exploración de las oportunidades de modernización

Muchos escenarios de modernización de Fabric también son técnicamente posibles en las SKU P. Lo que cambia en las SKU F es el modelo operativo: la administración de costos nativa de Azure, las funciones de gobernanza de capacidad (como la protección frente a picos y excesos de capacidad) y el Azure RBAC unificado facilitan abordar estos escenarios con límites de costes más claros y una mayor confianza operativa. Estas opciones son seguimientos opcionales, no requisitos de migración:

Incorpore los datos existentes en OneLake mediante Reflejo y Accesos directos.
Convierta los modelos semánticos de DirectQuery a Direct Lake cuando resulte beneficioso para las cargas de trabajo.
Adopta la seguridad de OneLake para unificar los controles de acceso a los datos en las cargas de trabajo de Fabric.

Trate estas opciones como secuencias de trabajo independientes que se ejecutan una vez completada la migración de licencias. No bloquean la migración y no deben ampliar su escala de tiempo.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-07-22