Power BI estrategias y patrones de migración de inquilinos

Las organizaciones se enfrentan a varios escenarios de migración de inquilinos en Power BI, controlados por fusiones y adquisiciones, desinversiones de empresa, requisitos de residencia de datos o necesidades de cumplimiento regionales. Las migraciones de inquilinos son empresas complejas que requieren una planificación cuidadosa, estrategias integrales de copia de seguridad y ejecución sistemática. En este artículo se proporcionan instrucciones para migraciones de inquilinos a escala empresarial Power BI, incluidos marcos de decisión para ayudar a determinar si es necesaria la migración y metodologías de implementación detalladas para diferentes patrones de migración.

Importante

Las migraciones de inquilinos conllevan un riesgo significativo y requieren un esfuerzo manual extenso. Microsoft no proporciona compatibilidad directa para migrar contenido entre inquilinos o dentro del mismo inquilino durante las reubicaciones regionales. Antes de continuar con cualquier migración, evalúe cuidadosamente alternativas como capacidades multi-geográficas que pueden abordar muchos escenarios sin la complejidad y el riesgo de la migración completa del inquilino.

Escenarios de migración de inquilinos

Power BI migración de inquilinos abarca tres escenarios. Identifique cuál se aplica a su situación antes de planear la migración.

Escenario Descripción Desencadenador típico
Migración en paralelo (entre inquilinos) Dos inquilinos de Microsoft 365 independientes funcionan en paralelo. Los artefactos se mueven del inquilino de origen al inquilino de destino individualmente. Fusiones y adquisiciones que consolidan dos organizaciones en un solo inquilino.
División de inquilinos Un único inquilinato de Power BI se divide en dos inquilinatos independientes. Los artefactos, los espacios de trabajo y los usuarios pertenecientes a la entidad empresarial saliente se separan selectivamente. Desinversiones y spin-offs.
Reasignación de inquilinos (reubicación de inquilinos) El inquilino de Power BI se elimina y se vuelve a crear en una nueva región principal dentro del mismo inquilino de Microsoft 365. Se conservan el identificador del inquilino de Microsoft 365, el dominio y las identidades de usuario. Para obtener más información, consulte Move Power BI entre regiones geográficas. Requisitos de residencia de datos que obligan a que la región de origen del inquilino esté en un país o una región específicos.

Las migraciones en paralelo y las divisiones de inquilino son operaciones entre inquilinos . La reasignación del inquilino es una reubicación regional dentro del mismo inquilino de Microsoft 365.

Nota:

Para consultar las consideraciones y limitaciones sobre la reasignación del inquilino (reubicación regional) con el Soporte técnico de Microsoft, consulte Trasladar el inquilino de Power BI a otra región. La asistencia de Soporte técnico de Microsoft se limita a eliminar el inquilino anterior y volver a asignar un nuevo inquilino a la región especificada; no se ofrece asistencia para la migración. Debe tener un plan de rehidratación para los datos y los metadatos, ya sea mediante copias de seguridad y restauración con scripts, acciones manuales o un proceso de recreación y recarga. Este procedimiento conlleva un riesgo considerable, incluida la posible pérdida de datos o artefactos si las copias de seguridad están incompletas o se omiten artefactos. El tiempo de inactividad durante la reasignación de inquilinos puede oscilar entre tres y 24 horas, con más tiempo de inactividad necesario para la restauración de artefactos.

Evaluación de alternativas antes de migrar

La migración de inquilinos implica un riesgo y un esfuerzo considerables. Explore las opciones alternativas antes de continuar. Las estrategias siguientes pueden ayudarle a evitar una migración o reubicación de inquilinos.

Implementación multigeográfica

Una implementación multigeográfica le permite implementar Power BI y capacidad de Fabric en una región de su elección sin cambiar la región de origen del inquilino. Los datos almacenados en esas capacidades permanecen cerca de sus usuarios finales, y puede tener varias capacidades en distintas regiones bajo el mismo inquilino.

La migración de artefactos a una capacidad en una región diferente es más sencilla que la migración del propio inquilino. Para mover un área de trabajo a otra región, vuelva a asignar el área de trabajo de una capacidad a otra. La reasignación es fluida para los elementos de Power BI.

Importante

Los elementos de Fabric no se conservan tras la reasignación de un área de trabajo entre capacidades de distintas regiones. Elimine Fabric elementos antes de reasignar el área de trabajo y vuelva a crearlos después, o use la integración de Git para realizar copias de seguridad y restaurar elementos Fabric.

Tenga en cuenta la implementación multigeográfica para los siguientes requisitos:

  • Latencia de datos. Acerque los datos y la capacidad de computación a los usuarios finales implementando capacidad en sus regiones.
  • Residencia de datos. Los datos y el proceso están vinculados a la región de capacidad , no a la región del inquilino. Una implementación multigeográfica mantiene los datos dentro de los límites de residencia de datos para la mayoría de las cargas de trabajo.

Tenga en cuenta la reasignación de un tenant solo cuando los requisitos de residencia de datos sean tan estrictos que incluso los metadatos del tenant (definiciones del área de trabajo, metadatos del modelo semántico, metadatos de los elementos visuales, configuración y directivas) y la información de usuario de Microsoft 365 deban permanecer dentro de los límites de residencia de datos.

Traiga su propia cuenta de almacenamiento para Dataflow Gen1

Dataflow Gen1 escribe su salida en una cuenta de Azure Data Lake Storage (ADLS) Gen2 que, de forma predeterminada, se encuentra en la región principal del inquilino de Power BI. Si la ubicación de almacenamiento de Dataflow Gen1 es la única preocupación de residencia, configure una cuenta de ADLS Gen2 propia en la región deseada en lugar de reubicar el inquilino.

La región del gateway no coincide con la del Azure Relay personalizado

Si la capacidad se implementa en una región distinta de la región de origen del tenant, el punto de conexión predeterminado de la puerta de enlace de datos de entorno local enruta el tráfico de vuelta a la región de origen. Para mantener el tráfico de puerta de enlace en su región de capacidad, configure un retransmisor de Azure personalizado. Una discrepancia de región de puerta de enlace por sí sola no debería desencadenar una migración de arrendatario.

Revisión del caso empresarial

Si una migración de inquilinos se basa en una necesidad empresarial (por ejemplo, consolidación de facturación), pesa el esfuerzo y el riesgo con respecto al resultado. Un inquilino pequeño puede ser fácil de migrar; un inquilino grande con una cantidad considerable de contenido de Fabric podría justificar volver a evaluar la necesidad empresarial antes de seguir adelante.

¿Qué se admite para la migración?

La mayoría de los elementos Power BI admiten la exportación de definiciones a través de la API de administración de Power BI o Workspace Scanner API y se pueden crear scripts. La mayoría de Fabric elementos no admiten la exportación de definiciones y se deben volver a crear manualmente.

En la tabla siguiente se resume la ruta de migración de cada tipo de artefacto.

Pedido Artefacto Ruta de migración
1 Gateways Sin ruta de migración. Un administrador de Power BI debe volver a configurarlo en el inquilino de destino.
2 Áreas de trabajo Sin ruta de migración. Debe volver a crearse en el inquilino de destino. La creación masiva es posible mediante la API de administración de Power BI.
3 Elementos de tejido Los elementos que admiten la integración con Git pueden respaldarse realizando un commit en Git, desvinculándolos del área de trabajo de origen y volviéndolos a vincular a un área de trabajo nueva en el tenant de destino. Solo se realiza una copia de seguridad de la definición; no se incluyen los datos. Los elementos que no admiten la integración de Git se deben volver a crear manualmente. Para Lakehouse, solo se conservan los metadatos; Las tablas y esquemas delta no se transfieren.
4 Dataflows Descargue el archivo JSON de definición y vuelva a importarlo en el tenant de destino. El scripting es posible mediante la API de administración.
5 Modelos semánticos o conjuntos de datos Use la copia de seguridad y la restauración en una cuenta de almacenamiento de ADLS Gen2 o descargue la definición y vuelva a importarla. El scripting es posible mediante la API de administración.
6 Informes Los propietarios o administradores descargan el archivo .pbix y lo vuelven a publicar en el tenant de destino. Como alternativa, exporte la definición json. El scripting es posible mediante la API de administración.
7 Cuadros de mando Sin ruta de migración. Debe volver a crearse manualmente.
8 Aplicaciones de Power BI Sin ruta de migración. Debe volver a crearse manualmente.
9 Informes paginados Los propietarios o administradores descargan el archivo RDL y publican en el inquilino de destino.

Importante

Recree siempre los artefactos en este orden. Los artefactos posteriores dependen de los artefactos previos, y omitir ese orden puede provocar referencias rotas durante la ejecución. Al realizar una sincronización de Git, se borran todos los elementos del área de trabajo que no existen en el repositorio.

Metodología de migración

Tenga en cuenta las siguientes actividades de referencia. La mayoría de los pasos se aplican a los tres escenarios. Los pasos específicos de un escenario se indican en sus encabezados.

Paso 1: Detección e evaluación del inventario

Cree un inventario completo de artefactos y dependencias e identifique lo que puede, no puede o no debe migrar.

Actividades

  • Ejecute la detección en todo el inquilino mediante una combinación de:
    • API de administración de Power BI
    • API de administración de Fabric
    • Registros de actividad (áreas de trabajo, informes, conjuntos de datos, actualizaciones)
    • Documentación manual de los elementos no expuestos por las API
  • Captura:
    • Áreas de trabajo (tipo, capacidad, región)
    • Informes, modelos semánticos (especialmente formato de almacenamiento grande), flujos de datos
    • Elementos de Fabric (Lakehouse, Warehouse, Eventhouse, cuadernos)
    • Puertas de enlace, orígenes de datos, credenciales
    • Roles de seguridad de nivel de fila (RLS), permisos del área de trabajo, vínculos para compartir
  • Clasifique cada área de trabajo por complejidad de migración (baja, media y alta) en función de los artefactos que contiene y las dependencias.

Salidas

  • Una hoja de cálculo de inventario principal.
  • Una clasificación de complejidad de la migración para cada área de trabajo.

Paso 2: Detección de usuarios y seguridad

Capture la identidad de usuario, las licencias y los permisos y asígnelos entre inquilinos cuando sea necesario.

En un mapa de inquilinos, se conservan los identificadores de objeto de usuario. Para una migración en paralelo o una división de inquilinos, los usuarios tienen identificadores de objeto diferentes en el inquilino de destino. Asigne cada identidad de inquilino de origen a su identidad de inquilino de destino. Reasignar las asignaciones de licencias de Power BI (Gratuita, Pro, PPU). Reflejar los grupos de seguridad en el nuevo tenant de Microsoft 365.

Actividades

Identificación y registro:

  • asignaciones de licencias de Power BI (procedentes de Microsoft Graph)
  • Identificadores de objeto del usuario en el tenant de origen
  • Identificadores de objeto de usuario en el inquilino de destino (solo en paralelo o divididos)
  • Permisos de usuario y niveles de acceso al área de trabajo
  • Configuración actual a nivel de inquilino (recopilar manualmente a través del portal de administración)
  • Configuraciones de gobernanza actuales (etiquetas de confidencialidad, directivas de aprobación)

Puede extraer permisos de área de trabajo y artefactos mediante las API de administración de Power BI y la API Workspace Scanner API.

Paso 3: Comunicación de partes interesadas y administración de cambios

Comunique el plan de migración al principio para reducir la resistencia y la carga de soporte técnico.

Grupos clave de partes interesadas

  • Patrocinadores ejecutivos
  • Propietarios del área de trabajo y autores de informes
  • Usuarios finales
  • Equipos de TI, seguridad e identidad

Actividades

  • Desarrollar un plan de comunicación que abarque:
    • Información general y justificación de la migración.
    • Qué se migra y qué no (por ejemplo, áreas de trabajo personales, áreas de trabajo inactivas).
    • Qué cambios (direcciones URL, acceso, tiempo de actualización). Los vínculos posteriores de Power Apps y SharePoint que hacen referencia a URL de Power BI también se ven afectados.
    • Lo que no cambia (semántica de datos, objetos visuales, lógica de negocios).
  • Comunicar fechas clave:
    • Ventanas de congelación (normalmente, alrededor de una semana sin cambios en el inquilino de origen durante la copia de seguridad final).
    • Tiempo de inactividad esperado (para escenarios de reasignación de inquilinos).
    • Períodos de validación para que las partes interesadas comprueben sus propios informes en el inquilino de destino.
    • Hitos de transición y fechas de retirada para el inquilino de origen (escenarios en paralelo).

Salidas

  • Una presentación para las partes interesadas.
  • Preguntas más frecuentes sobre los usuarios finales.

Paso 4: Enviar una solicitud de reasignación de inquilino (solo reasignación de inquilino)

Cuando la fecha de migración queda fijada, envíe un ticket de soporte y seleccione expresamente la opción de reasignación del tenant. Un ingeniero de soporte técnico de Microsoft toma la solicitud.

Actividades

  • Envíe el ticket de soporte.
  • Complete la lista de comprobación de preparación proporcionada por Microsoft.
  • Acordad una fecha y una franja horaria para la migración, incluida una franja horaria de reserva.
  • Elimine la capacidad existente antes de que se lleve a cabo la reasignación del inquilino.

Resultados esperados

  • Una reasignación típica tarda unas tres horas, pero puede haber retrasos de hasta 24 horas si se producen complicaciones.
  • Una vez completado el mapa, el nuevo inquilino tiene el mismo identificador de inquilino y se encuentra en la región solicitada.

Paso 5: Preparación del inquilino de destino

Un inquilino recién creado o recién reasignado no está listo inmediatamente para recibir contenido. Configúrelo primero.

Actividades

  • Configurar la configuración del inquilino de Power BI:
    • Controles de creación del área de trabajo
    • Uso compartido y directivas de acceso externo
    • Gobernanza de objetos visuales personalizados
    • Etiquetas de confidencialidad y protección de la información
    • Habilitación de registro de auditoría y supervisión
  • Compre capacidades de Fabric con un SKU igual o superior que la capacidad de origen.
  • Configure y valide las puertas de enlace, los clústeres de puertas de enlace y la conectividad de datos.
  • Para escenarios de división en paralelo o de inquilino:
    • Cree un usuario en el inquilino de destino para cada usuario del inquilino de origen y registre la asignación de usuarios.
    • Vuelva a crear los grupos de usuarios del tenant de origen.
    • Asigne licencias Power BI en el inquilino de destino.
  • Alinear la gobernanza: etiquetas de confidencialidad, integración con Microsoft Purview y políticas de aprobación.

Paso 6: Piloto de migración

Ejecute una migración de prueba en un área de trabajo de ejemplo representativa antes de la migración de producción.

En el caso de las migraciones en paralelo, el entorno de origen permanece disponible como alternativa de respaldo para los reintentos. En el caso de la reasignación de inquilino, el contenido del que no se hizo una copia de seguridad correctamente antes de la reasignación es irrecuperable. Una prueba piloto exitosa es la principal manera de mitigar los riesgos del proceso de remapeo.

Criterios de selección del área de trabajo piloto

  • Contiene una combinación de artefactos: informes, modelos semánticos, flujos de datos y elementos de Fabric.
  • Usa orígenes de datos realistas y programaciones de actualización.
  • Tiene permisos a nivel de espacio de trabajo e idealmente también RLS.
  • Se usa activamente, pero no es crítico.

Paso 7: Ejecución de la migración

Ejecute la migración. Los elementos admitidos se scriptan primero; Los elementos no admitidos se vuelven a crear manualmente.

En el caso de los inquilinos grandes, escriba scripts que encapsulan la API de administración de Power BI para exportar de forma masiva y volver a crear artefactos de forma masiva.

Vuelva a crear artefactos en el orden definido en ¿Qué se admite para la migración? Saltarse el orden rompe las dependencias.

Paso 8: Validación y pruebas

Valide que el contenido se migre correctamente y se comporte correctamente.

Las definiciones de modelo semántico exportados no incluyen los datos subyacentes. Cada modelo semántico importado necesita al menos una actualización manual en el inquilino de destino.

Sugerencia

Considere la posibilidad de escalar temporalmente a una SKU de mayor capacidad durante la validación. Un gran número de actualizaciones simultáneas puede saturar la capacidad de destino.

Actividades

  • Validar datos: recuentos de filas, agregaciones clave, actualización completada correctamente.
  • Validar la seguridad: reglas de RLS, acceso al área de trabajo, ámbitos de uso compartido.
  • Validar el rendimiento: tiempos de carga de informes, capacidad de respuesta de las consultas, espacio de capacidad.

Paso 9: Transición y adopción de los usuarios

Mueva los usuarios al tenant de destino y actualice las aplicaciones posteriores.

Actividades

  • Conceda a los usuarios acceso a áreas de trabajo y artefactos en el inquilino de destino.
  • Actualice las direcciones URL de informe insertadas, los vínculos de SharePoint, las conexiones de Power Apps y los flujos de Power Automate que hacen referencia a contenido Power BI.
  • Desactive la edición en el tenant de origen (fase de solo lectura) antes del desmantelamiento final.
  • Ejecute sesiones de habilitación breves que abarquen lo que ha cambiado y dónde encontrar contenido.

Contenido relacionado

  • Last updated on