En el último tiempo son muchas las compañias cambiando de capacidad para aprovechar al máximo la nueva tecnología que Microsoft nos brinda. Este cambio se vuelve cada vez más necesario puesto que está anunciado que Premium no podrá renovarse y es tiempo de dar el salto hasta Fabric.

En este artículo describiremos estrategias y alternativas para migraciones de este tipo dentro de un mismo tenant y que podemos hacer frente a tenants distintos.

Si aún no estas al tanto de que es Fabric. Te invito a dar una vuelta por este artículo. Para organizarnos mejor vamos a separar este artículo cuando es en mismo tenant o separados.

Migrar en un mismo tenant

La palabra migrar es la usada en el mercado pero sinceramente no creo que esté alineada con la necesidad real. Porque digo esto, porque en realidad no migramos, sino que ajustamos las áreas de trabajo a otra capacidad. Sería como cambiar el almacenamiento de un código. Entendiendo que cambiarnos de Premium a Fabric es en realiad reasignar la capacidad del área de trabajo es que vamos a proceder.

Algunos detalles importantes a tener en cuenta. La región de nuestra capacidad tiene importancia. Si bien existe una opción en el portal de administración para manipular capacidades multiregión, recomiendo crear el Fabric dentro de la misma región que Premium para evitar otras configuraciones adicionales. Así mismo, el formato de almacenamiento de los modelos semánticos puede generar errores. El formato large puede ocacionar errores dependiendo de la complejidad del modelo, a diferencia del small que está más limitado e igual en ambos casos. Adicionalmente a las recomendaciones duras, agrego una más organizativa que refiere a aprovechar este tiempo de proceso para validar que las áreas de trabajo en la capacidad "deban" estarlo y aprovechar de remover de la capacidad las que no se usan, nunca debieron estar o podrían estar en pro (puesto que su adiencia son todos usuarios con licencia).

Comencemos con las alternativas:

1) Manual uno por uno

Permisos requeridos, basta con ser administrador de las áreas de trabajo premium y administrador de capacidad Fabric.

Tal vez la forma más engorrosa, pero no nos dejemos engañar. Si tenemos pocas areas de trabajo, puede ser muy eficiente para aprovechar de visualizar el contenido del área antes de cambiar su capacidad. Para realizar este proceso, abrimos un área de trabajo dirigiendonos a su configuración. Allí encontramos una pestaña referida a licencias para cambiarlo.

2) Manual en lote

Permisos requeridos, cuenta de usuario con rol Fabric Administrator y Administrador de capacidad Fabric. En caso que la migración sea directa, es decir que todas y cada una de las áreas de trabajo y sus ítems de Premium van a pasar a Fabric; ésta es una gran opción.

Esto nos permitirá migrar la totalidad de áreas en pocos clicks. Para ello, nos dirigimos a Workspaces dentro del portal de administración y filtramos las áreas por su tipo de capacidad:

Una vez que la lista de workspace está filtrada correctamente, vamos a seleccionar todos con el cuadradito junto al nombre y aparecerá el botón para reasignar capacidad:

Tengamos presente que eso cambiará las áreas que vemos en la lista. Si estamos viendo 10 resultados, solo serán esos 10 seleccionados. Si tenemos 1000 áreas de trabajo, podemos poner que muestre 100 resultados esta vista y ejecutar esta acción 10 veces para mover lotes de 100 áreas de trabajo.

3) Script API

Permisos requeridos, cuenta de usuario con rol Fabric Administrator y una App Registrada en Azure. En caso de utilizar service principal, hay que adicionar que dicha app tenga los permisos para que utilice la Fabric API en el admin portal. Esos detalles pueden leerlos aqui. Experiencia en desarrollo con PowerShell, Python (Librería SimplePBI) u otro lenguaje de programación y manejo de API. Dependiendo el login efectuado necesitaremos administrador de capacidad Fabric para la App o el usuario.

Esta metodología aplica particularmente para cuando las áreas que vamos a migrar tiene condiciones más complejas. Con esto nos referimos a que hicimos un análisis de las áreas que pertenecen al premium y no todas serán migradas. Ya sea porque el contenido no era apropiado, nunca debió estar en premium, no se utiliza o queremos optimizar el contenido en la nueva capacidad, con esta opción podríamos concretarlo. El primer paso sería relevar éstas áreas de trabajo y armar una lista de IDs y nombres de áreas. A partir de esto la idea es escribir un script que itere las áreas de trabajo reasignado su capacidad. Dependiendo si vamos a autenticar la App Registrada en Azure como Service Principal o con Master User (usuario y contraseña con permiso Fabric Administrator).

• Master User: en este caso podremos ejecutar la reasignación desde la categoría de la API de administración: https://learn.microsoft.com/en-us/rest/api/power-bi/admin/capacities-assign-workspaces-to-capacity
• Service Principal: como no pueden ejecutar acciones de administración, como pre requisito, debemos asignar la App como Admin de las áreas de trabajo a migrar. Por ello, podemos hacerlo manualmente o con un script que haga el login Master User y una acción Group AddUserAsAdmin. Recien entonces, podremos ejecutar la reasignación desde la categoría de la API de capacidad: https://learn.microsoft.com/en-us/rest/api/power-bi/capacities/groups-assign-to-capacity

Lo más recomendado sería utilizar la autenticación Master User dado que mientras no podamos ejecutar acciones de administración con Service Principal, se vuelve largo el proceso y si ya iteramos para asignar un service principal al área de trabajo a migrar, podríamos estar usando el mismo script para ejecutar la reasignación.

NOTA: Tengamos en cuenta que la autenticación de la API por master user no funciona con MFA. Si tenemos MFA estaremos obligados a utilizar los PowerBi cmdlets de Powershell.

Migrar entre dos tenant distintos

Aquí el proyecto se complica. Hoy no hay herramientas que provean esta solución de manera ágil y dependiendo la cantidad y tipo de ítems de nuestro premium, resultará en cuanto porcentaje de migración realmente se puede efectuar.

El primer detalle a tener en cuenta en este caso es referido a tipo de ítems. ¿Utilizamos solo reportes de PowerBi? ¿Tenemos más contenido como Dataflows gen1, paneles, etc? ¿Se están usando ítems de fabric como notebooks, pipelines o warehouses?

Dependerá de las respuestas a estas preguntas sobre cuan posible es migrar y cuanta manualidad tendríamos. Antes de comenzar recalco que no existe una metodología que soporte esta operación. Es por esto que no podremos migrar el 100% de los casos y tampoco podremos librarnos de trabajos manuales.

Veamos alternativas:

1) Migración manual:

Permisos requeridos, licencia de PowerBi pro en ambos tenants y administrador de capacidad Fabric del nuevo. Rol de miembro o administrador de área de trabajo origen. Permiso de creación de área de trabajo destino.

No se puede dejar de mencionar que el trabajo manual es una opción. Considero crítico para operar de este modo, validar que aquello que deba migrarse sea realmente necesario y se use. No migrar aquello de lo que podemos presindir considerando que es muy laborioso. Crear una área en el nuevo tenant, asignar su capacidad. Descargar los archivos .pbix, exportar json de dataflows, copiar códigos de notebooks en tenant origen y publicar, importar o pegar en tenant destino. Ésta forma es muy lenta pero garantiza mantener exactamente cada componente. Consideremos que algunos componentes como los Paneles, no puede exportarse y solo queda recrearlos.

2) Script API

Permisos requeridos, cuenta de usuario con Power Bi PRO y una App Registrada en Azure. En caso de utilizar service principal, hay que adicionar que dicha app tenga los permisos para que utilice la Fabric API en el admin portal. Esos detalles pueden leerlos aqui. Experiencia en desarrollo con PowerShell, Python (Librería SimplePBI) u otro lenguaje de programación y manejo de API. Ya sea el usuario o el Service Principal deben formar parte del área de trabajo origen. Permiso de creación de áreas de trabajo y administrador de capacidad Fabric en nuevo tenant.

Aunque ésta pueda resultar la forma más atractiva, cabe mencionar que no todo los ítems de las áreas de trabajo se pueden exportar. Puede ser una muy atractiva opción para migraciones basadas en reporte de PowerBi, dado que exportar reportes e importarlos en otro tenant son operaciones factibles en la Rest API. Al iterar las áreas de trabajo en el primer tenant podríamos tomar el nombre, crearlas en el nuevo con la app/usuario como administrador, asignarles capacidad y comenzar a poblarlo. Todo con API. En caso de contar con ítems de Fabric, poco a poco va siendo posible obtenerlos y recrearlos con la API.

3) Manual/Script con repositorio git.

Permisos requeridos dependen si será manual o con script. Cuenta de usuario con Power Bi PRO y una App Registrada en Azure. Experiencia en desarrollo con PowerShell, Python (Librería SimplePBI) u otro lenguaje de programación y manejo de API. El usuario debe formar parte del área de trabajo destino. Permiso de creación de áreas de trabajo y administrador de capacidad Fabric en nuevo tenant. Acceso al repositorio con AD o Personal Access Token.

Dependiendo si nuestros desarrollos ya estaban ordenados dentro de un repositorio o no, delimitará cuan complejo será el proceso. Si no tenemos nuestro premium integrado a repositorios, lo primero será crear un repositorio, organizarlo por carpetas según las áreas de trabajo y sincronizarlo. Realizado el prerequisito de un origen integrado a un repositorio, podremos proceder.

Por un lado, la migración manual. Ingresar al nuevo tenant. Crear una área de trabajo. Asignarle capacidad Fabric e integrarlo a su correspondiente carpeta del repositorio. De esta forma todos los ítems del repositorio serán parte del área de trabajo.

Por otro lado, el proceso podría utilizar un script para automatizar acciones. La iteración de la migración sería por carpetas de workspace en el repositorio. La idea es crear un área de trabajo con el mismo nombre, asignarse como administrador y asignar la capacidad. Hasta ahi como siempre. Lo nuevo sería conectar el repositorio y hacer un update (pull) con la API de Fabric logueando con Master User (no tiene permitido service principal la categoría git de la API). De esa forma, aprovechando el repositorio, se irían creando y poblando las áreas con sus ítems siempre y cuando sean versionables. Aqui tenemos limitación obligada a master user que podríamos tener MFA y nos impediría seguir. La alternativa sería realizar un deploy desde el repositorio al área de trabajo, sin embargo la dificultad para construir ese request para cada ítem de PowerBi es muy alta. Lo que generaría controversia de si demoraremos más en hacer el proceso automatico que manual.

NOTA: recuerden que los repositorios permitidos son Azure DevOps o GitHub. Pueden leer más sobre la integración en los hipervínculos.

Conclusión

Así llegamos al final del artículo con muchas opciones de migración premium o pro a fabric. Recordemos que la forma más viable es hacerlo dentro del mismo tenant y que si es a separados hay mucha más complejidad. Seguramente, no son las únicas formas. Así como podemos usar la API hoy son cada vez más las operaciones que podemos ejecutar con Semantic links y sempy en Fabric notebooks. Repaso también que no todo componente es migrable, configuraciones de CI/CD o deployment pipelines podrían causar un verdadero dolor de cabeza entre distintos tenants. Espero que esto los ayude a no sufrir tanto las migraciones.