Migración de Power BI: guía completa para mover workspaces, informes y modelos sin perder control (ni parar el negocio)

Resumen rápido: migración de Power BI en 12 puntos (sin tecnicismos innecesarios)

1. Define el “por qué”: cambiar de tenant, ordenar workspaces, pasar a capacidad (o cambiarla), reducir riesgo o preparar un gobierno serio.
2. No es solo contenido: lo difícil no son los informes, sino permisos, refrescos, credenciales, gateways y propietarios.
3. Decide estrategia: “mover y ajustar” (rápido) vs “reconstruir con orden” (más limpio, menos deuda).
4. Inventario real: lista de workspaces + quién los usa + qué refrescos fallan + qué es crítico para negocio.
5. Diseña el destino: nomenclatura, estructura por dominios/áreas, roles basados en grupos y reglas de compartición.
6. Licencias/capacidad: valida qué necesitan creadores y consumidores (Pro/PPU/capacidad) antes de mover nada.
7. Plan por oleadas: piloto representativo → oleadas por área → corte final.
8. Refrescos y gateways: prepara el “puente” a datos (gateway, credenciales, permisos en origen de datos) antes de publicar en masa.
9. Seguridad: etiquetas de confidencialidad, reglas de exportación/compartición y auditoría activadas desde el día 1.
10. Pruebas con negocio: UAT con casos reales (“lo que hago cada lunes”), no solo “abre el informe”.
11. Comunicación: explica qué cambia (links, apps, accesos) y pon un canal de soporte los primeros días.
12. Estabilización: mide incidencias, rendimiento y refrescos; corrige antes de apagar el entorno antiguo.

¿Cuándo se necesita una migración de Power BI?

No todas las organizaciones “necesitan” migrar Power BI. Muchas veces lo que hace falta es orden y un poco de gobierno. Pero hay escenarios en los que una migración de Power BI (total o parcial) se vuelve el camino más razonable.

Escenarios habituales (los que más se repiten en la vida real)

• Cambio de tenant (tenant-to-tenant): fusiones, escisiones, cambio de marca o reorganizaciones donde identidades y permisos se redefinen.
• “Power BI se nos fue de las manos”: demasiados workspaces, reportes duplicados, owners que ya no están y nadie sabe qué es crítico.
• Cambio de capacidad/licenciamiento: mover workspaces a capacidad dedicada o cambiar el modelo para escalar consumo y rendimiento.
• Gobierno y seguridad: auditoría, etiquetas de confidencialidad, control de exportaciones y compartición externa porque el dato lo exige.
• Modernización de la plataforma de datos: cambias el origen (por ejemplo, un DWH nuevo) y aprovechas para “limpiar” modelos e informes.
• Optimización de costes: recortar redundancias y dejar solo lo que aporta valor, con una estructura que se pueda operar.

Introducción a la migración de Power BI

Esta guía está pensada para equipos de IT, analítica y responsables de negocio que quieren ejecutar una migración de Power BI con cabeza: con continuidad, con seguridad y sin convertir el primer mes en una avalancha de tickets.

Aquí hablamos de migración en sentido amplio: desde mover workspaces a otra estructura, hasta un tenant nuevo, pasando por una transición de licencias/capacidad o por ordenar todo el ciclo de vida de contenido (desarrollo → pruebas → producción).

Verás términos como workspace (área de trabajo), modelo semántico (lo que antes muchos llamaban “dataset”), gateway (el puente hacia datos on-prem o restringidos) o deployment pipelines (la forma “bonita” de mover contenido entre entornos). Los usamos cuando aportan claridad, y siempre con explicación sencilla.

Nota: algunas capacidades y pantallas cambian con el tiempo, especialmente con la evolución de Microsoft Fabric. Por eso, al final dejamos recursos oficiales para validar el estado actual.

1. Qué se migra (y qué conviene rediseñar)

En la práctica: lo que se “mueve” suele ser fácil; lo que se “reconstruye bien” es lo que evita dolores durante años.

1.1 Activos típicos en una migración de Power BI

1.2 Lo que suele romperse si no se planifica

• Refrescos: el informe abre, pero los datos se quedan congelados porque faltan credenciales o gateway.
• Permisos: usuarios que “antes lo veían” y ahora no, o al revés (riesgo).
• Propietarios: contenidos críticos con owners inexistentes o cuentas personales.
• Compartición externa: se corta o queda demasiado abierta si no se gobierna.
• Exportaciones: de pronto cualquiera exporta a Excel/PDF (o nadie puede), generando conflicto.

1.3 Qué conviene aprovechar para rediseñar

Migrar es un buen momento para tomar decisiones que, en el día a día, siempre se posponen:

• Reducir duplicidades: “este informe existe 5 veces” suele ser más común de lo que parece.
• Separar entornos: desarrollo y producción no deberían ser la misma sala.
• Ordenar por dominios de negocio: finanzas, ventas, operaciones… con owners claros.
• Definir estándares: naming, descripción mínima, quién publica y quién solo consume.

2. Estrategias de migración: rápido vs limpio (y cómo elegir)

En la práctica: elegir estrategia no es ideología, es equilibrio entre tiempo, riesgo y deuda futura.

2.1 Estrategia A — “Mover y ajustar” (cuando hay prisa)

Sirve cuando el objetivo principal es cambiar de sitio (nuevo tenant, nueva capacidad o nueva estructura) en un tiempo acotado. Se migra contenido clave, se restablecen refrescos y permisos, y se corrigen cosas a medida que aparecen.

• Pros: más rápida, menos discusión inicial, útil en proyectos con fecha “sí o sí”.
• Contras: si el entorno estaba desordenado, puedes “mover el desorden” y arrastrarlo.

2.2 Estrategia B — “Rehacer con orden” (cuando quieres un antes y un después)

Aquí no solo se migra: se rediseña. Se crea una estructura destino limpia y se llevan solo los activos que aportan valor, ajustando modelos, permisos y distribución. Suele ser la mejor opción cuando hay deuda acumulada.

• Pros: queda un entorno mantenible, más seguro y más fácil de escalar.
• Contras: requiere más trabajo con negocio (decisiones), y un poco más de tiempo inicial.

2.3 Estrategia mixta (la más común)

Lo habitual es mezclar: mover rápido lo crítico para continuidad y, en paralelo, ir “limpiando” y profesionalizando. Por ejemplo: los 20 informes clave se migran primero, y el resto pasa por un filtro (archivar, rediseñar o retirar).

3. Licencias y capacidad: lo que conviene cerrar antes del proyecto

En la práctica: si no aclaras licencias/capacidad al inicio, acabarás discutiéndolo cuando el negocio ya esté esperando resultados.

La migración de Power BI suele destapar una realidad incómoda: el modelo actual “funciona” porque hay excepciones, licencias dispersas y reglas no escritas. Antes de migrar conviene dejar claro cómo se va a publicar, cómo se va a consumir y quién necesita qué.

3.1 Preguntas que hay que resolver (sí o sí)

• ¿Quién crea y publica contenido? (creadores) → normalmente requieren Power BI Pro (o PPU según caso).
• ¿Quién solo consume? (consumidores) → dependerá de si el contenido está en capacidad o no.
• ¿Qué workspaces van a capacidad? y qué implica a nivel de rendimiento y costes.
• ¿Hay necesidades “premium”? (por ejemplo, distribución amplia, control, rendimiento, características avanzadas).

3.2 Orientación práctica (sin marearte)

Como punto de partida, estas ideas ayudan a conversar con dirección:

• Si todos son “autores” (muchos publican) → suele tener sentido un enfoque por usuario (Pro/PPU) bien controlado.
• Si hay muchos “lectores” (cientos o miles consumen) → suele interesar usar capacidad para permitir consumo amplio sin licencias por usuario para cada lector (según tamaño y requisitos).
• Si tu organización está moviéndose hacia Fabric → conviene alinear el plan con ese rumbo para no rehacer dos veces.

3.3 Lo que suele salir caro

• Migrar sin capacidad definida: publicas, funciona “a ratos”, y el negocio concluye que “Power BI va lento”.
• Licencias sin gobernanza: “dame una Pro” se vuelve un reflejo, sin control de quién publica de verdad.
• Workspaces sin owners: nadie se responsabiliza del contenido y la operación se vuelve reactiva.

4. Metodología por oleadas y gobierno del proyecto

En la práctica: una migración de Power BI tranquila se parece a una mudanza por habitaciones, no a vaciar la casa en una noche.

La forma más segura de ejecutar una migración de Power BI es por oleadas: empiezas con un piloto representativo (no “el más fácil”), aprendes, ajustas y luego escalas.

4.1 Fases típicas

1. Descubrimiento: inventario + uso real + criticidad.
2. Diseño del destino: estructura, roles, settings, seguridad, distribución.
3. Piloto: una o dos áreas con “casos reales” y usuarios que den feedback.
4. Oleadas: migras por área/proceso, con ventanas y soporte.
5. Estabilización: rendimiento, refrescos, permisos, limpieza final y cierre.

Cuando hay un partner (como MSAdvance), el equipo interno no “pierde el control”: al contrario, gana método, plantillas y un ritmo predecible, mientras se protege el día a día de la operación.

5. Assessment: inventario, uso real y dependencias

En la práctica: el assessment responde a “qué tenemos”, “qué se usa” y “qué se cae si tocamos esto”.

5.1 Inventario mínimo viable (lo que conviene saber antes de migrar)

• Workspaces: quién administra, quién publica, quién consume.
• Activos: informes, dashboards, modelos semánticos, dataflows.
• Refrescos: frecuencia, duración, fallos recurrentes, dependencias.
• Fuentes de datos: cloud vs on-prem, necesidad de gateway, credenciales.
• Seguridad: RLS, compartición externa, exportaciones, etiquetas.

5.2 Cómo hacerlo con herramientas oficiales (sin inventar la rueda)

Para inventariar a escala, Power BI/Fabric ofrece APIs y registros que ayudan a ver “la foto real”, especialmente en tenants grandes:

• Metadata scanning (Admin APIs): para obtener metadatos de workspaces y activos.
• Activity log: para entender uso (quién ve qué, qué se comparte, qué se exporta) y priorizar lo que importa.

5.3 Priorización por criticidad (para no migrar “a ciegas”)

Un truco que funciona: clasificar activos en 3 niveles con negocio:

• Nivel 1 (crítico): si se cae, impacta operación o reporting a dirección.
• Nivel 2 (importante): aporta valor semanal, pero hay alternativa temporal.
• Nivel 3 (largo plazo): poco usado, duplicado o candidato a retirarse.

Esta simple clasificación convierte la migración en algo gobernable: primero aseguras continuidad, después ordenas.

6. Diseño del destino: workspaces, roles, compartición y settings

En la práctica: un buen destino reduce soporte, evita riesgos y hace que el contenido se encuentre sin pedir “pásame el link”.

6.1 Estructura de workspaces (modelo sencillo que suele funcionar)

Una estructura típica y práctica:

• Workspaces por dominio de negocio (Finanzas, Ventas, Operaciones…): dueños claros y contenido estable.
• Workspaces de desarrollo/pruebas: para iterar sin romper producción.
• Workspaces “sandbox”: para exploración, con reglas claras y limpieza periódica.

6.2 Roles y permisos (menos drama, más claridad)

El objetivo es evitar permisos persona-a-persona. Lo más mantenible es:

• Permisos asignados a grupos (idealmente en Entra ID) y no a usuarios sueltos.
• Separar quién publica de quién consume.
• Definir quién puede compartir o exportar, según el tipo de dato.

6.3 Tenant settings: exportar, compartir, publicar… sin bloquear a todo el mundo

Este punto suele ser delicado: seguridad quiere cerrar, negocio quiere agilidad. La solución no es “todo abierto” o “todo cerrado”, sino reglas por grupos y casos de uso.

Analyze in Excel (oficial): Crear libros de Excel con datos de Power BI.

7. Migrar contenido: informes, dashboards y modelos semánticos

En la práctica: migrar contenido es relativamente directo; lo importante es que quede publicable, refrescable y gobernable.

7.1 Tres formas habituales de mover contenido

7.2 Checklist “contenido listo para migrar”

• PBIX ordenado: parámetros claros, nombres consistentes, fuentes de datos documentadas.
• Modelo semántico: medidas y relaciones entendibles; evita dependencias “mágicas”.
• RLS revisado: roles y pruebas con usuarios reales.
• Etiquetas (si aplican): clasificación lista antes de publicar masivamente.

7.3 Un detalle que ahorra disgustos: “quién mantiene qué”

Antes de migrar, define owners reales por dominio. Un informe sin dueño no es un informe: es una futura incidencia. Si no hay owner, se decide: se retira, se archiva o se reasigna.

8. Refrescos, credenciales y gateways: el “punto crítico”

En la práctica: si los refrescos fallan, para el negocio el informe “no funciona”, aunque se vea bonito.

8.1 Refresco: lo que conviene revisar antes del corte

• Frecuencia y ventanas: cuándo refresca cada cosa y si compite con otras cargas.
• Duración: refrescos que tardan demasiado suelen ser señal de modelo/origen a optimizar.
• Errores recurrentes: timeouts, credenciales caducadas, gateway saturado.

8.2 Gateways: el puente a datos que no están “abiertos”

Si tienes datos on-prem o en redes restringidas, el gateway no es un detalle: es la autopista. Por eso, en migraciones serias se trata como un componente crítico con alta disponibilidad, monitorización y owners claros.

8.3 Cómo evitar el clásico “se publicó, pero no refresca”

1. Preparar cuentas/credenciales de servicio (evitar cuentas personales).
2. Crear y probar las fuentes de datos en gateway antes de migrar en masa.
3. Validar permisos en origen (SQL, archivos, APIs) desde el punto de vista de esa cuenta.
4. Probar un set pequeño (piloto) y medir tiempos de refresco.

9. Dataflows y otros activos: qué suele doler y cómo hacerlo bien

En la práctica: los dataflows suelen tener dependencias escondidas; si no los documentas, te perseguirán.

Si tu organización usa dataflows, conviene tratarlos como “producto de datos”: tienen lógica, conexiones, propietarios y consumidores indirectos (modelos que dependen de ellos).

9.1 Qué revisar en dataflows

• Conexiones: origen, credenciales, gateway (si aplica).
• Dependencias: qué modelos/informes se alimentan de ese dataflow.
• Rendimiento: duración de refresh y picos de carga.
• Propietarios: quién responde si falla a las 7:00.

9.2 Recomendación práctica

En vez de intentar “migrar todo a la vez”, suele ser más seguro:

1. Migrar primero el dataflow “padre” (el que alimenta a varios).
2. Validar que refresca correctamente y que los datos son coherentes.
3. Migrar después modelos/informes dependientes.

Nota: la forma exacta de mover dataflows puede variar según el tipo (y según si estás usando capacidades de Fabric). En cualquier caso, el principio es el mismo: dependencias claras, owners claros, pruebas reales.

10. Apps, audiencias y experiencia de usuario: que la gente encuentre “lo suyo”

En la práctica: el éxito se nota cuando el lunes por la mañana nadie pregunta “¿dónde está el informe?”

10.1 Apps: la forma más ordenada de distribuir

Una app bien construida reduce el caos de enlaces, pone estructura y permite segmentar por audiencias. Para migración, además, ayuda a “reubicar” a usuarios sin que tengan que aprenderse una nueva ruta.

10.2 Qué suele cambiar para el usuario (y hay que avisar)

• Enlaces: los links antiguos pueden dejar de apuntar al contenido nuevo.
• Accesos: si se ordenan permisos, algunas personas perderán acceso a cosas que “tenían por costumbre”.
• Exportaciones: puede haber nuevas reglas (para bien).

10.3 Plan de comunicación simple (y eficaz)

1. Antes: qué se migra, cuándo y qué tienen que hacer (si algo).
2. Durante: estado del corte/oleada y cómo pedir ayuda.
3. Después: dónde está la app nueva, qué cambió y mini-guía de 5 minutos.

11. Seguridad y cumplimiento: etiquetas, exportaciones y auditoría

En la práctica: seguridad no debería ser “el freno”; debería ser el cinturón de seguridad que te permite escalar.

11.1 Etiquetas de confidencialidad (sensibilidad)

Si manejas datos sensibles, las etiquetas ayudan a clasificar y proteger contenido (informes, modelos, dashboards y dataflows), y además pueden acompañar al dato cuando se exporta.

11.2 RLS (seguridad por filas): lo que hay que entender para no confiarse

RLS es potente, pero tiene matices. En el servicio, quienes tienen roles elevados en un workspace (admin, member, contributor) no están limitados por RLS como un “viewer”. Por eso conviene separar quién administra de quién consume.

Oficial: Row-level security (RLS) con Power BI.

11.3 Auditoría: visibilidad para mejorar (y para dormir mejor)

Una migración bien hecha deja auditoría activada para poder responder preguntas como: “¿quién exporta?”, “¿quién comparte?”, “¿qué se consulta de verdad?”, “¿qué contenido nadie usa y podemos retirar?”

12. KPIs, UAT y validación con negocio

En la práctica: “abre el informe” no es una prueba. La prueba es “yo hago mi trabajo con esto”.

12.1 KPIs útiles (para medir sin complicarte)

12.2 UAT con casos reales

Pide a negocio 5–10 “historias reales”: cierres mensuales, seguimiento de ventas, control de stock, productividad… Si esas historias funcionan en el nuevo entorno, estás cerca del éxito.

13. Checklists operativos (pre, durante y post)

En la práctica: un checklist simple evita los típicos “¿y esto quién lo miraba?”

13.1 Antes de migrar

• Inventario cerrado (workspaces, owners, criticidad, dependencias).
• Estructura destino creada (workspaces, grupos, roles).
• Decisiones de licencias/capacidad acordadas.
• Gateways listos (si aplica) y fuentes de datos probadas.
• Reglas de exportación/compartición revisadas y aprobadas.
• Plan de comunicación y soporte por oleadas.

13.2 Durante la migración

• Migrar por lote/oleada con lista cerrada.
• Validar accesos (usuarios clave) y refrescos (contenido crítico).
• Registrar incidencias y corregir patrón (no apagar fuegos sueltos).
• Comunicación corta y clara: qué ya está y dónde está.

13.3 Después

• Medir uso y rendimiento (primera semana y primer mes).
• Recertificar accesos en workspaces sensibles.
• Retirar o archivar contenido duplicado/obsoleto.
• Decidir fecha de “apagado” del entorno antiguo (si aplica), con plan de contingencia.

14. Errores frecuentes y mitigaciones

En la práctica: la mayoría de problemas son evitables si los miras antes (y no el día del corte).

15. Scripts y snippets útiles (PowerShell / APIs) sin complicarte

En la práctica: automatizar lo repetible ahorra tiempo y reduce errores humanos.

Si tu tenant es grande, tiene sentido usar herramientas de inventario y automatización. No necesitas convertirte en “desarrollador de APIs”, pero sí es útil conocer lo básico para listar workspaces o revisar actividad.

# Requiere Power BI Management module
# Ejemplo conceptual: extraer eventos del activity log
Get-PowerBIActivityEvent -StartDateTime "2026-01-01T00:00:00" -EndDateTime "2026-01-07T00:00:00" | Export-Csv .\activity.csv -NoTypeInformation

Oficial: Access the Power BI activity log.

POST https://api.powerbi.com/v1.0/myorg/groups/{groupId}/imports?datasetDisplayName={datasetDisplayName}

Oficial: Post Import In Group.

16. Preguntas frecuentes (FAQ ampliadas) sobre migración de Power BI

17. Recursos oficiales y enlaces útiles para migración de Power BI

• Deployment pipelines (Microsoft Fabric)
• Power BI REST API — Imports
• Admin APIs — Workspace metadata scanning
• Power BI activity log (guía)
• Auditing (Power BI)
• Sensitivity labels (Power BI)
• Export & sharing tenant settings
• On-premises data gateway
• Licencias: características por tipo
• Pricing oficial de Power BI

Recursos internos de MSAdvance (relacionados y útiles)

• Blog de MSAdvance
• Migración Microsoft 365 entre tenants (guía)
• Migración Entra ID (guía y checklist)
• MFA en Entra ID (guía completa)
• Arquitectura Azure (servicio)
• Seguridad & Cumplimiento (servicio)
• Suministro y venta de licencias (servicio)
• Todos los servicios

18. Conclusión y siguientes pasos

Una migración de Power BI bien ejecutada se nota por tres cosas: (1) el negocio encuentra sus informes sin perseguir enlaces, (2) los refrescos funcionan de forma predecible, y (3) la seguridad sube sin convertir la herramienta en un obstáculo.

Si tu siguiente paso es empezar, lo más útil suele ser:

• Hacer un inventario real (con uso y criticidad, no solo lista).
• Diseñar un destino simple y mantenible (workspaces, roles, distribución).
• Ejecutar un piloto representativo y ajustar antes de escalar.